// 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

ItemCheap quoteComplete quote
Legacy data migrationOften 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 documentationNone, 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 trainingOne 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 stagingDoesn'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 rightsOne 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-liveEnds 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 ownershipOften 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 boundaryUndefined, 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?

No, and calling it a scam would itself be dishonest. Rp 200.000 buys a few hours of somebody's work — enough for one input form that saves and displays, one simple report page, or reinstalling a ready-made template. For a need that small, that price is fair and you don't need a project at all. What that figure can't buy is everything that makes a system survive: discovery sessions to map the exceptions, a permission matrix across roles, legacy data migration with reconciliation, separate staging, an audit log, documentation, and a bug warranty after go-live. The example on this page weighs 20 work-weeks — set that against a few hours and the gap stops being a mystery. The right question isn't 'why so expensive', it's 'which lines am I buying'.

How can two vendors differ by a factor of three on the same brief?

Because what differs isn't their rate, it's what their silence contains. Cheap quotes almost always leave out the same five things, and almost always without saying so: legacy data migration is pushed onto your staff via an Excel template, staging is dropped so changes touch live data directly, documentation is replaced by a screen recording, training is compressed into one session for every role, and support stops on the day of final payment. There's a sixth that's subtler — the boundary between revision and change request is deliberately left vague, and the margin gap gets closed later through extra invoices raised when you no longer have a choice. The definition we use for that boundary is out in the open in the [terms and conditions](/syarat-ketentuan). The way to check is simple: ask both vendors to write down what isn't included. The one who refuses to write it has already answered your question.

What are the running costs per month once the system is live?

There are three recurring items and one optional. First, server and database: for dozens of active users that's generally Rp 300rb-1,5jt a month, and the figure climbs with transaction volume, not with headcount. Second, backup storage — small in the first year, then rising slowly because old data never shrinks. Third, third-party APIs if you use them: [official WhatsApp](/layanan/whatsapp-api) is billed per conversation, payment gateways per transaction, and both go up precisely when business is good. Fourth, optional, a monthly maintenance contract for security patches and small adjustments — if you have your own IT team, you can skip this one with no consequences. Everything in the first three goes to the respective providers, not to us.

How many hours will this cost our own team?

More than people usually estimate, and it's the cost item that never appears in anyone's quote. Discovery takes 1-2 hours per key person — cashier, warehouse admin, finance — times two or three sessions. UAT takes 1-2 weeks, and those are their working hours, not ours; realistically two to four people at half a day each, every day, through that period. The biggest one is the parallel period: one full accounting cycle where old and new are keyed side by side so the closing figures can be set against each other. For a 40-person team, that can add up to several dozen internal mandays. We can't make it disappear — forcing a cut here is exactly what turns go-live into a mess. All we can do is tell you up front so you schedule it, instead of discovering it mid-flight.

Can we get a firm number without discovery first?

We can state the range for free — Rp 15-30jt, Rp 30-60jt, or above — but not a firm project figure before discovery. The exact written quote comes from the module list and mapping your SOPs. If the number lands outside your budget after discovery, the scope document is still yours to keep.

If we ask for additions mid-project, does the price get recalculated?

It depends on whether the addition counts as a revision or a change request, and we write that boundary before the contract — not during a dispute. Changing a column layout, adding a filter to an existing report, or fixing wording on screen is a revision, and it's included. Adding a new module, adding a fourth role that isn't in the scope document, or changing an approval flow from one level to three is a change request — and that means a new work-week weight, which we write down first for you to approve. The full definition with examples is in the [terms and conditions](/syarat-ketentuan), open to read before you decide anything at all. You're always free to reject that additional estimate and take the work elsewhere. We don't hold anything that would make rejecting it expensive.

What does building an ERP cost, and is the math different?

The method is identical — what differs is the length of the module list. ERP usually means four to eight interlocking modules, so integration and testing weight rise together. In practice, an ERP rarely weighs under 20 work-weeks, so its realistic entry point is Rp 30-60jt and rises quickly with a second branch. If all you need is standard bookkeeping, an established off-the-shelf product is usually the better fit.

Why is data migration weighted at 2 work-weeks? Isn't it just copy-paste?

Copying rows is quick; deciding which value is authoritative requires an audit and decisions from the data owner. Once discrepancies are approved, import is followed by reconciliation of totals, row counts, and account values. The [composite cooperative narrative](/case-study/koperasi-jateng-tutup-buku-4-jam) uses this pattern as an illustration. No consent reference, supporting artifacts, raw data, or public URL is available for that narrative, so its figures cannot be independently verified and are not a guarantee.

If we do it in phases, does the total come out cheaper?

No, usually slightly more expensive — around one to two extra work-weeks, because each phase needs retesting of the modules already running. What improves is cashflow and risk control, not the total. The phased amounts are written into the exact project quote, and the split must follow module boundaries rather than arbitrary payment sizes.

// 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.

→ See examples of our workTerms & Conditions