What Actually Drives the Cost of a Custom System

The first question is almost always "how much". The honest answer is that it depends, which sounds evasive. So this piece explains what it depends on, so you can place your own needs somewhere on the range.

The four things that decide it#

1. How many screens#

Every screen is a view that must be designed, built, tested and fixed when something is wrong. A simple record-keeping system might have five screens. A system with records, multi-level approvals, reporting and settings might have thirty.

This is the factor you control most directly: start with what is genuinely used every day, and let the rest follow.

2. How many user types and permission levels#

A system with one kind of user is far simpler than one with four. Once roles differ — staff, supervisor, owner, customer — every screen needs a decision: who can see, who can change, who can delete.

Permission rules are rarely visible in the interface, but they consume real build time.

3. How many other systems must connect#

This is what most often pushes a budget past its estimate. Connecting to payments, to accounting software, to WhatsApp, to a warehouse system — each connection has its own rules, and some of them change without notice.

A single integration can take as long as several screens combined.

4. Who runs the servers#

A system you run yourself is cheaper up front. One we keep running has an ongoing cost, but you do not need someone on staff who understands servers.

Why we do not quote before mapping#

A figure given before we have seen how you work will almost certainly miss, because what drives it is not how large the system looks but how tangled the business rules behind it are.

Two businesses that both "need an order recording system" can differ enormously: one has a single price, the other has prices that vary by customer, by quantity and by season. The screens look similar; the work is not.

What you can do to keep it down#

• Start with one process, the one used most and got wrong most
• Defer integrations not genuinely needed in the first week
• Fix scope before starting, and hold changes for the next version
• Use off-the-shelf tools for common work like accounting; keep custom for what is specific to your business

After mapping#

We give a figure once we know what is needed, and it holds as long as scope does. If scope changes, the recalculation is discussed before the work happens — not presented as a bill at the end.