// systems · internal operations · custom
Software your team runs on, not a brochure your visitors read
If daily operations still run on spreadsheets that clash and a manual scramble every month-end, what you need isn't another website — it's a system that follows how you already work.
// what you can check, not what we can claim
Four terms we'll put in writing
- Written
- Project scope, milestones, price, and targets
- Per proposal
- Schedule starts after approved discovery
- 3 months
- Bug-fix support after go-live
- 100%
- Source code is the client's after final payment
Case studies on this site carry anonymized or composite labels according to their origin. No project count or outcome guarantee is presented as independent proof.
A custom information system is internal software built around your company's SOPs — recording transactions, setting access rights, running approvals, and generating reports. It replaces separate Excel files and ledgers with one operational data source. A composite narrative describes a 1,800-member cooperative and reports a six-day close becoming four hours plus a 78% rise in applications. No consent reference, supporting artifacts, raw data, or public URL is available; the figures are not independently verified, are not a published client result, and are not a guarantee. Custom systems always begin with discovery and a written scope and price.
// why an internal system
The point where general tools stop being enough
Picture the 3rd of the month and you're still waiting on recaps from three divisions. "The file's on Bu Rina's laptop, she's on leave." Meanwhile this week's stock decision has to be made that same day — and Excel isn't broken, it just was never designed for eleven people at once. From here there are three paths, and two of them are expensive in ways you don't see. First, monthly subscription tools: fast to switch on, but billed per user, and it's your SOPs that have to bend to the software. Second, a freelancer: cheap up front, then the number goes dead when a bug shows up right in the middle of closing season. Third, a system built around the workflow you've been running for years — tiered approvals, access rights per division, an audit trail you can open when someone comes to inspect. For cooperatives, it's even a legal requirement: financial reports must be presented at the RAT (the annual members' meeting), and Permenkop UKM No 8/2023 (the cooperatives ministry regulation) sets the reporting format. What you're buying isn't just features, it's ownership — source code, database, and the right to change both without asking anyone's permission, which is also what explains the numbers in the proposal. You only find out what ownership costs when you want to leave — and a subscription vendor doesn't have to shut down to make things hard for you, it just has to raise the rate at renewal or move a feature you already use up to the tier above. What moves is the data, not the responsibility. In the eyes of UU No 27/2022 tentang PDP (Indonesia's personal data protection law), you're still the controller of your employee and member data — the vendor is only a processor, and if a breach happens on their servers, the obligation to notify the data owners still lands on you. Your own system doesn't erase that obligation; what changes is that the server credentials are in your hands and the migration schedule is set in an internal meeting, not by a notification email dated 90 days out.
// what you get
What ships with every project
- ✓Core modules matching your actual process — transactions, stock, cash, members, or whatever has been living in Excel
- ✓Access rights per division and per position: warehouse staff never see a column that isn't theirs
- ✓Tiered approvals whose flow you can change yourself when someone gets rotated, without calling a developer
- ✓A permanent audit trail — who changed what, when, from which value to which
- ✓A management dashboard with numbers pulled straight from transactions, not retyped every Monday
- ✓Periodic reports with filters, Excel and PDF export, ready to take into a meeting or hand to an auditor
- ✓Migration of your old Excel data with balance reconciliation down to the last rupiah
- ✓Integration with the accounting or POS you already use — Accurate, Jurnal, HubSpot, Moka, Olsera, Pawoon
- ✓WhatsApp and email notifications for approvals left hanging past their deadline
- ✓A staging environment separate from production, so changes get tested before they touch real data
- ✓Daily database backups plus scheduled restore tests — not just backup files nobody ever opens
- ✓Source code, database schema, and repository access become 100% yours after final payment
- ✓Technical documentation and usage SOPs in Indonesian for your team going forward
- ✓Onboarding training per role, plus 3 months of bug fixes at no extra cost
// custom vs subscription vs freelancer
Three routes, three different consequences
| Aspect | Subscription app | Custom system |
|---|---|---|
| Source code ownership | Subscription tools: you're renting access, you never own anything. Freelancers: source code often gets held back until there's an extra payment — or never handed over at all. | Source code, database schema, and repository become yours after final payment. Want to continue with a different developer? Go ahead. Nobody needs our permission. |
| Cost at 5, 25, and 100 users | Billed per user per month. At 5 people it feels light, at 25 it becomes a fixed budget line, at 100 it turns into a number that climbs every year without you owning anything. | A one-time up-front cost. Adding users doesn't add licences — the only thing that goes up is server capacity, and that moves in hundreds of thousands per month, not per head. |
| Fit with the SOPs you already run | Your SOPs bend to the software. Three approval levels get forced down to two, internal terminology gets swapped for vendor terminology, and the team relearns a way of working they'd already mastered over years. | The software bends to the SOPs. The flow you already run gets mapped first — exceptions included — and only then does code get written. The words on screen are the words your team uses. |
| Data location and control | Operational data, employee data, and member data sit on the provider's servers, often outside Indonesian jurisdiction, under terms of service that can change unilaterally. | The server location is stated in writing in the contract, and the hosting account is in your company's name. You're the data controller — directly relevant to UU No 27/2022 tentang PDP (Indonesia's personal data protection law). |
| Maintenance and bug fixes | Freelancers: you're depending on one person who may already have a full-time job. Subscription tools: queueing for English-language support that has no idea what tutup buku means. | Three months of bug fixes included in the project price. After that, an optional monthly maintenance contract — and if you choose not to continue, the system keeps running. |
| Risk of being left by the vendor | If the service shuts down, changes direction, or raises its prices, you move on dragging your data out as raw CSV — without any of the business logic that was running behind it. | Technical documentation, database schema, and repository are in your hands from handover onward. We pick a common stack, so a replacement is easy to find. The vendor can be swapped; the system doesn't disappear with them. |
| Integration with what you already use | Limited to the official integrations list. If your POS or accounting software isn't on that list, the answer is 'not supported yet' — and your team goes back to typing the same numbers twice. | Integrations get built to fit: Accurate, Jurnal, HubSpot, Moka, Olsera, Pawoon, or anything with an API. If the API is closed, we tell you during discovery, not after the contract. |
// how it works
Five phases, milestones follow the proposal
01
Discovery & SOP mapping
1-2 weeks, usually 2-3 sessions. We sit down with the people who actually run the process — the cashier, the warehouse admin, the treasurer — not just the owner. What we're hunting for is the exceptions: when the normal rule gets broken, who's allowed to break it, and what happens afterwards. The output of this stage is a written scope document listing modules, roles, and approval flows. That document is where the final number comes from — before it exists, all we can quote is a range.
02
Role map, access rights, and wireframes
Every role gets mapped one by one: what they see the moment they log in, what they're allowed to change, and what shouldn't appear on their screen at all. You sign off on this access matrix in writing, because that's where most internal disputes tend to surface later. We test low-fidelity wireframes with the real future users before a single line of code is written. It's cheaper to move a grey box than to move a database.
03
Two-week build sprints
The build can be divided into sprints with a clickable module demo at agreed checkpoints. Sprint length, demo dates, and the go-live sequence are binding only when stated in the written plan. When the scope and UAT results allow it, the cash module can go into use before the stock module. Feedback enters the backlog and is prioritised together rather than decided unilaterally by us.
04
Data migration & UAT on staging
Old data gets imported into staging, then reconciled: total balances, row counts, and per-account figures have to match the old files exactly. A one-rupiah discrepancy means the migration gets redone. Once the numbers are clean, your team uses the system on staging with real scenarios for a few days — daily transactions, a trial close, the reports people usually ask for. Bugs, UX confusion, and requirements that only surface now get logged and resolved before go-live.
05
Phased go-live, training, handover
The switchover happens in stages, not overnight. Usually the new system and the old records run in parallel for one period, until you're confident the numbers agree. Training is built per role — the cashier doesn't need to sit through the board's session. Handover covers the repository, hosting credentials in your company's name, the database schema, and technical documentation. For three months afterwards bug fixes are included in the project price; a monthly maintenance contract is optional and you're free to turn it down.
Internal systems don't fall over because they're short on features, but because the data model was wrong from week one. That's where we start — entities, relationships, and the rules that must never be broken get enforced at the database level, not just in the interface. Access rights are designed per role and per division, so warehouse staff never see the salary column. Every change to a number leaves a trace: who, when, from which value to which — an audit trail that can't be deleted from the screen. Tiered approvals are built as a flow you can change yourself, not hard-coded logic we have to touch every time someone gets rotated. If Accurate, Jurnal, or Moka are already running, this system attaches to them through API integration, and approval notifications land in your team's WhatsApp — not an email nobody ever opens. For field staff, the interface can be wrapped as an app installed on the phone. Data sits on servers whose location is written into the contract, because UU No 27/2022 tentang PDP (Indonesia's personal data protection law) puts the responsibility on you as the controller. Daily backups, restores tested, not assumed. What decides whether this system can still be carried on three years from now isn't the programming language, it's what gets handed over alongside the code at handover: the database schema plus sequential migration files, so the structure can be rebuilt from scratch without guesswork. Business rules that aren't standard — caps per grade, service rounding, approval exceptions — are written as Indonesian-language notes right where the rule runs, not in a separate document that's always one revision behind. After go-live, every change request is quoted with a written hour estimate up front, and you're free to turn it down and take the same work to another developer. We don't hold anything that makes saying no expensive.
// system types
Example system types we discuss
Savings & Loan Cooperative App
Principal, mandatory and voluntary deposits, tiered loan approval, SHU calculation, and automatic book closing.
Custom ERP Development Service
Build an ERP whose modules follow your own process: sales, purchasing, warehouse, production, finance. One database, one item master.
Custom Warehouse Inventory App Development
A custom warehouse system: multi-location, inter-warehouse transfers, batch and expiry, stock counts with variance approval, unit conversion, POS sync.
Custom Business System Cost Guide
What a custom internal system actually costs: what drives the number, the costs people forget, and why vendor quotes differ so widely for one brief.
Web App for Your Customers
If what you're building is used by customers outside the company rather than your internal team, that's a different route.
// investment
Ranges, not packages
Compact system
Rp 15-30jt
3-5 core modules, 1-3 user roles, one location. A fit when what you're replacing is a handful of Excel files and one manual ledger. Light data migration, no third-party integrations yet.
Most commonly chosen
Rp 30-60jt
Multi-module with tiered approvals, many roles, integration with accounting or POS, and custom reports for board or director meetings. This is the range that most often fits organisations of 20-150 people.
Large scale
Rp 60jt+
Multi-branch or multi-tenant, high transaction volume, large data migration from several sources at once. Usually split into several release phases so the switchover risk stays under control.
These are ranges, not packages, and discovery is required before any range becomes one exact written figure. The number of modules, roles and approval levels, legacy-data migration, and integrations determine the quote. Full internal systems start at Rp 15jt; if discovery shows the need is smaller, we say so and direct you to a lighter service.
// a good fit when
The conditions that make this worth it
- →Businesses of 20-150 employees whose daily operations have pushed past what Excel can reasonably handle
- →Savings-and-loan cooperatives required to present financial reports at the RAT every year
- →Distributors or manufacturers with tiered approvals and more than one warehouse
- →Companies whose SOPs are already written up neatly but have no system running them
- →Multi-branch businesses whose daily reports still get sent over WhatsApp every afternoon
// not yet a fit when
When you shouldn't build a custom system
- ✕
Anyone who just needs standard bookkeeping — buy Accurate or Jurnal, far cheaper and matured over years
- ✕
Anyone who just needs a shop till and simple stock — Moka, Olsera, or Pawoon solve that this month, no project required
- ✕
Anyone whose SOPs aren't written down yet and still change monthly — fix the process first, a system will only lock the chaos in permanently
- ✕
Anyone who really just wants prospects to find them on Google — that's a company profile website's job, not an internal system
- ✕
Anyone whose budget is below Rp 15jt and cannot move — we decline rather than cut scope until the system is no longer useful
// questions
What people usually ask first.
How is this different from the custom web app service?
How long until the team can actually use the system?
Our data has been in Excel for years. Can it move over without losses?
Who owns the source code and the database?
If Webiti stops operating, does our system die with it?
We already use Accurate and Moka. Do we have to replace them?
What are the running costs per month once the system is live?
Who holds the server credentials, and how is access revoked when a staff member resigns?
What do we need to prepare so the project doesn't drag on?
// go next
Related pages
Savings & Loan Cooperative App
Principal, mandatory and voluntary deposits, tiered loan approval, SHU calculation, and automatic book closing.
Composite narrative: a six-day close, done in four hours
No consent reference or public artifacts are stored in the repository; figures are not independently verified and are not a guarantee of results.
Web App for Your Customers
If what you're building is used by customers outside the company rather than your internal team, that's a different route.
// ready to start?
Build Your Business a Website
Right Now!
Free consultation via WhatsApp. We review your needs, give you a time & price estimate, then start together — no drama.