// systems · cost · the maths, shown
What a custom system costs, with the arithmetic shown
Plenty of vendors publish a number. What almost nobody shows is where that number came from — so on this page we show the working, including the costs that usually surface later.
// three ranges
The numbers first, the argument after
Compact system
Rp 15-30jt
Roughly 8-13 work-weeks. Three to five core modules, 1-3 roles, one location, light data migration, no third-party integrations yet. This is what's left when the 20 work-week example above gets trimmed by those six decisions.
Most commonly chosen
Rp 30-60jt
Roughly 14-24 work-weeks. Multi-module with tiered approval, several roles, one or two integrations, and custom reports for the board. The two-warehouse distributor on this page — 20 work-weeks — sits in the upper half of this band.
Large scale
Rp 60jt+
25 work-weeks and up. Multi-branch or multi-tenant, high transaction volume, large migrations from several sources at once. Almost always split into two or three release phases, with the second phase's weight only locked once the first is running.
Custom information-system projects in Indonesia range from Rp 15jt to Rp 60jt+. The figure is not pulled from a package list: each module is weighted in work-weeks, then discovery, legacy-data migration, UAT, and handover are added. This page shows that arithmetic rather than hiding it behind a single headline price. What the system itself covers is handled on the information system hub page, while the pricing page shows the standard website tiers.
// what drives the number
The six things that actually set the price
Picture yourself sending the same brief to three vendors and receiving Rp 8jt, Rp 47jt, and a refusal to quote before a meeting. The difference is often what each vendor quietly leaves out of scope. A building-materials distributor with 40 staff, two warehouses, three years of Excel data, and an existing accounting setup weighs about 20 work-weeks and sits in the upper half of Rp 30-60jt. Remove one integration, one warehouse, two years of migration, three roles, two approval levels, and custom reports, and it drops to about 12-13 work-weeks in the Rp 15-30jt range. Those decisions are what turn a range into an exact written quote after discovery.
// cheap quote vs complete quote
What a cheap quote quietly leaves out
| Item | Cheap quote | Complete quote |
|---|---|---|
| Legacy data migration | Often not mentioned at all, or written as a single line saying 'data import'. In practice you get handed an Excel template to fill in yourself — and the work of cleaning three years of data lands on your staff, outside their working hours. | Counted as its own line with its own weight. It covers auditing the dirty data, mapping it to the new structure, and a balance reconciliation that has to match the old files exactly before it's called done. |
| Technical documentation | None, or a 20-minute screen recording. When the next developer arrives two years later, they read the code with no map — and you're the one paying for that reading time. | Database schema, ordered migration files, and business-rule notes in Indonesian. Written so the system can be picked up by someone else without ever having to contact us. |
| User training | One demo session for everybody at once, usually a one-hour video call. The cashier and the director sit in the same session, and both leave with half an understanding. | Separate sessions per role, because what a cashier needs and what a warehouse head needs aren't the same thing. Plus written guides a new hire can read again six months later. |
| Separate staging | Doesn't exist — changes get pushed straight into the system people are using. You find out something broke from the cashier's phone call at ten in the morning, when the queue is already long. | A staging environment running from week one, with a masked copy of the data. Every change is tested there first, and the server cost for both is already in the numbers. |
| Audit log & access rights | One login level for everyone, or two: admin and not-admin. Change history isn't stored, so when the cash doesn't balance there's nothing to trace. | Access rights per role down to the column and the amount, plus a permanent record of who changed what, from which value to which. This is the most expensive line to bolt on later. |
| Support after go-live | Ends the day the final payment clears. A bug that shows up in week two is already filed as 'new work' — and the rate gets set while you have no other option. | Three months of bug fixing is already in the project price, with the line between a bug and a new request written into the contract. A maintenance contract after that is optional and you're free to decline it. |
| Source code ownership | Often never discussed, and the silence works in the vendor's favour. What you receive is access to a running system — not the code, not the database, not the right to move it elsewhere. | Source code, database schema, and repository access become yours on final payment, stated in writing. No licence is held back as leverage to keep you coming back. |
| Revision vs change request boundary | Undefined, so every request turns into a fresh negotiation. This is exactly where a cheap vendor closes its margin gap — by billing for things you assumed were included. | The definition is written before the contract, with examples of what falls on each side. The reference sits on the terms and conditions page, open to read before you decide anything at all. |
// the forgotten costs
Line items that never reach the proposal but you still pay
Six things move the number, and the order is rarely what people expect. First, the number of user roles — each new role doesn't add a menu, it multiplies the testing matrix; six roles times twelve modules means 72 permission combinations that have to be tried one by one. Second, approval depth: one level is a button, three levels is a state machine with delegation when an approver is on leave, rejection mid-flow, and rules on who's allowed to pull a submission back. Third, the number of integrations — what's expensive isn't calling the API, it's handling the API when it fails: retries, idempotency so a journal entry doesn't post twice, and a daily reconciliation comparing both sides. Fourth, the condition of the legacy data; what decides this isn't the row count but the exception count — columns whose meaning shifted in a particular year, document numbers reused, balances with no matching entry. Fifth, multi-branch: separating data per location is easy, consolidating the books without double-counting is the hard part — you feel this clearly in a multi-location warehouse system. Sixth, custom reports, and this is actually the cheapest of the six — each report is one aggregation query that has to stay fast across three years of data. What people usually cut to save money is number five and number six. Yet the biggest savings sit in number one and number two.
// how the number is produced
From first conversation to a written estimate
01
A 20-30 minute first chat: filtering, not haggling
We ask six things — how many people will use it, how many different roles, how many locations, what systems are already running, where the old data lives, and when you need it in production. Those six answers produce a rough band, not a fixed figure. If a subscription app already solves the requirement, we can say so in the initial conversation and the discussion can end with nothing to pay. Some conversations may end at this stage, and that is an appropriate outcome. Any figure given before process mapping is only an estimate and may change when the scope is clarified.
02
Discovery: turning the story into a list of modules
One to two weeks, usually two or three sessions, and we ask to speak with the people who actually press the buttons. What we're hunting isn't the normal flow — the normal flow always sounds simple. We're hunting the exceptions: transactions that may be backdated, who's authorised to cancel, what happens when physical stock doesn't match the record. Every exception found at this stage costs far less than the same one found during UAT. The output is a single document with a module list, a role list, and an approval diagram — not a single rupiah in it yet.
03
Weighting: every module gets a work-week number
We weight that module list one item at a time, exactly like the 14 lines above. Weight comes from three things: how many new data entities are born, how many role combinations have to be tested, and how many failure conditions have to be handled. Modules that look big to a user are often light in code, and the reverse too — printing an invoice is half a day, while the rules around goods returns can eat a full week. We show you these weights as they are, not hidden behind one lump-sum figure. If there's a line you think is overpriced, that's the place to argue about it — not the total.
04
Written estimate: three scenarios and an exclusion list
You get a document containing three versions: core modules only, the full build, and a phased version split into two releases. All three use the same weight list, only the lines differ. On the last page there's a section other vendors rarely send — the list of what is NOT included, written out explicitly. That's also where we pin down the boundary between a revision and a change request, whose full definition lives in the [terms and conditions](/syarat-ketentuan). Reading the exclusions matters more than reading the total, because the gap between vendor quotes almost always hides in there.
05
Locking scope, payment terms, and the points where the number may move
Once you approve one scenario, scope is locked and the number becomes fixed — not indicative. Payment splits into terms tied to milestones you can see, not to the calendar. The number is allowed to move under two conditions only, and we write both into the contract: you add modules or roles beyond the scope document, or the legacy data turns out to be far more broken than the sample we audited at the start. We shrink the risk of that second one by auditing a data sample before the contract, not after. Outside those two, any overrun in build time is on us — that's what weighting up front is for.
// what's in our estimate
What every quote we send spells out
- ✓Technical foundation, authentication, and a permission matrix for 6 roles — 2 work-weeks, and it's the line people underestimate most often
- ✓Master data: products, suppliers, customers, two warehouses, unit conversions — 1 work-week
- ✓Purchasing module with three-level approval and a spending ceiling per level — 1.5 work-weeks
- ✓Goods receipt, stock cards across two warehouses, inter-location transfers, stock opname (physical count) — 2.5 work-weeks, the heaviest line on this list
- ✓Sales: quotations, delivery notes, invoices, returns, and pricing per customer tier — 2 work-weeks
- ✓Receivables, cash, and due-date collections with automatic aging — 1.5 work-weeks
- ✓Per-role dashboards plus periodic reports with filters and Excel/PDF export — 1.5 work-weeks
- ✓One-way integration to Accurate for sales and purchase journals — 1 work-week
- ✓Migration of three years of Excel data plus balance reconciliation down to the last rupiah — 2 work-weeks
- ✓Audit log, staging kept separate from production, daily backups, and scheduled restore tests — 0.5 work-weeks
- ✓WhatsApp notifications for approvals left hanging past their deadline — 0.5 work-weeks
- ✓Discovery, SOP mapping, and a written scope document that the number is built on — 1.5 work-weeks
- ✓UAT support plus clearing your team's findings before go-live — 1.5 work-weeks
- ✓Indonesian-language documentation, per-role training, and repository handover — 1 work-week. That's 20 work-weeks in total
These ranges cover the build, not the recurring cost of ownership. Server and database, backup storage, third-party APIs, the client's own UAT hours, and the parallel-run period are listed separately in the proposal. Full system work starts at Rp 15jt and receives an exact written quote after discovery; needs below that point are directed to a lighter service rather than having essential modules cut.
// this page is for you if
Who gets the most out of reading it
- →Owners or directors drafting next year's budget who need a number they can defend to the board
- →Operations managers holding two quotes that differ by a factor of three, with no idea which one to believe
- →Companies whose SOPs are already written down, so the module list can be built without guesswork
- →Teams who've already failed once with a cheap vendor and now want to read the exclusion list before signing anything
- →Organisations of 20-150 people with years of historical data whose migration weight needs to be calculated, not assumed
// too early if
When reading a cost guide is still premature
- ✕
Anyone whose processes still change every month — weighting modules whose definition isn't stable only produces a number that expires in six weeks
- ✕
Anyone who hasn't yet named one person with authority over scope; without that the estimate gets revised forever and never locks
- ✕
Anyone collecting comparison figures to squeeze another vendor — use the method by all means, but we don't take part in price auctions
- ✕
Anyone who needs the system live next month; 1-2 weeks of discovery, 6-12 weeks of build, 1-2 weeks of UAT, and 1 week of go-live can't be compressed without moving the risk onto you
- ✕
Anyone who needs a fixed project figure before discovery — an existing subscription app may be the more predictable choice
// questions
The cost questions that come up most.
There are marketplace listings offering Rp 200.000. Is that a scam?
How can two vendors differ by a factor of three on the same brief?
What are the running costs per month once the system is live?
How many hours will this cost our own team?
Can we get a firm number without discovery first?
If we ask for additions mid-project, does the price get recalculated?
What does building an ERP cost, and is the math different?
Why is data migration weighted at 2 work-weeks? Isn't it just copy-paste?
If we do it in phases, does the total come out cheaper?
// go next
Related pages
Custom Business System Development
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.
Custom ERP Development Service
Build an ERP whose modules follow your own process: sales, purchasing, warehouse, production, finance. One database, one item master.
Composite narrative: from 6 working days down to 4 hours
No consent reference or public artifacts are stored in the repository; figures are not independently verified and are not a guarantee of results.
// 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.