Custom Software Development

Roles drive cost, not screens

Clients estimate custom software by counting screens. We estimate it by counting roles, because every additional role multiplies permissions, views, reports and test cases across the whole system.

"It is just for our staff" reliably becomes admin, branch manager, accountant, storekeeper, sales agent, auditor and a read-only owner dashboard. Seven roles. Each one needs its own answer to: what can it see, what can it create, what can it edit, what can it approve, what can it delete, and what happens when it tries something it is not allowed to do. That matrix is the first artefact we produce, before a single screen is drawn, because it determines the database design — and schema mistakes are the expensive kind. You migrate around them for years.

Approval chains are where the real complexity hides

"Managers approve leave requests" is one sentence and roughly two weeks of work once you answer the questions it hides. Can approval be delegated while a manager is themselves on leave? Can a rejected request be resubmitted, and does it go back to the same person? Can HR override a manager, and is that logged differently? Does approval trigger a payroll adjustment, and what happens if payroll for that period is already closed? Is there a value threshold above which a second approver is required?

None of those are technical questions. They are business rules, and they need a decision-maker on your side who can answer them. We surface them during discovery precisely because finding them in month three is what turns a fixed-price project into an argument.

Reports decide your database design

Reporting is routinely postponed to the end of a project, which is the most expensive possible sequence. A report is a question asked of your data, and some questions are impossible to answer efficiently unless the data was stored with them in mind.

A concrete example: if you will ever need "stock value by branch at the end of each month", storing only current stock levels is not enough — you need a movement history you can reconstruct a point in time from. Adding that later means backfilling data that was never recorded. So we ask for the list of reports you need in discovery, even in rough form, and design the schema to serve them.

Audit trails, and why you want one from day one

Any system where money, stock or approvals move needs to be able to answer "who changed this, when, and what was the previous value?" Retrofitting that is genuinely hard, because the history you want is precisely the history you did not record.

We build it in from the start: an append-only log of significant actions with actor, timestamp, entity and before/after values. It is inexpensive at build time and it repays itself the first time there is a dispute about a price change or a deleted invoice. It also changes how deletion works — in most business systems records should be marked inactive rather than removed, so that historical documents referencing them remain intact.

Data migration is a project inside the project

"We will just import the Excel file" is the most consistently underestimated sentence in this line of work. Ten years of records entered by different people contain the same customer spelled four ways, phone numbers in six formats, dates as text, negative quantities, blank required fields, and duplicates that are not exact duplicates.

Our approach is to treat migration as its own scoped piece of work with real days attached, run it repeatedly rather than once, and produce a reconciliation report the client's own finance or operations people sign off — row counts, totals, and a list of records that could not be migrated cleanly and why. That last list is the important one. Somebody has to make decisions about it, and it is not the development team.

Integrating with systems you do not control

Most custom systems must talk to something else: an accounting package, a payment gateway, a courier, a government portal, a legacy application whose original developer is unreachable. These are the single most common cause of estimate overruns, because the estimate assumed documentation was accurate, a sandbox existed and someone at the other organisation would answer email.

So we validate every integration in the first two weeks with a throwaway script that makes one real call, before the build depends on it. And we ask you to name a person on your side responsible for chasing that third party — a development team cannot escalate inside another company on your behalf.

When we tell you to buy instead of build

We are a custom software company and we still recommend off-the-shelf products regularly, because for genuinely standard needs a mature product will beat a fresh build on cost, features and reliability. Standard accounting, standard payroll, standard email marketing, standard helpdesk — these are solved problems with decades of edge cases already handled.

Custom is the right answer when your process is a genuine competitive difference, when no product fits without distorting how you work, when you need several systems to behave as one, or when the licensing cost of a product at your user count exceeds building your own. If none of those is true, we will say so. That answer has cost us work and it remains correct.

Building it so it can be handed on

A custom system typically outlives the team that built it, so the real test is whether a competent developer who has never met us can pick it up. Which means migrations in version control and never a manual schema change on production; business rules covered by automated tests, specifically the calculations, permissions and thresholds where being wrong costs money; a documented API contract; structured logging and error tracking; a deployment that runs from a script rather than from memory; and a schema document explaining not just the tables but why they are shaped that way.

You also hold everything from day one — repository, hosting, credentials, backups — in your own company's name. For the wider picture on scoping this kind of project, our guide to writing a requirements document includes the exact role-matrix format we use, and why software projects fail covers the nine failure patterns we check for.