Deciding to develop custom software is straightforward. What follows is less so, and the parts that determine success are rarely the parts that get planned.
What follows is the shape of a build that works, in the order the work actually happens.
Discovery is observation, not interviews
Asking people how the process works gets you the official version. Watching it happen gets you the real one, and the gap between them is where projects fail.
Budget real time for this — a week or two of sitting with the people doing the work is not overhead, it is the cheapest risk reduction available. You are looking for the side spreadsheets, the verbal approvals, the customer types handled differently for historical reasons, and the steps people have stopped noticing they perform.
Model before you build
Before any interface exists, the core records need named states and legal transitions between them. Which changes are allowed, by whom, and which are reversible.
This is unglamorous and it is the difference between a system that enforces your rules and one that merely records what people typed. It also cannot be added later without a data migration, because by then you have records that violate the rule you now want to enforce.
Decide the failure behaviour of every integration
Anything crossing a network will be unavailable sometimes. Each integration needs an explicit answer: block and retry, drop silently, or queue and reconcile.
A payment confirmation blocks. An analytics event drops. A document upload queues. Left undecided, these get chosen ad hoc by whoever writes the function that week, and the system behaves inconsistently under exactly the conditions where consistency matters.
Ship something real, early
Not a prototype and not a design — a working slice, in front of actual users, doing one complete thing end to end.
The purpose is not to demonstrate progress. It is to find out which of your assumptions were wrong while changing them is still cheap. Every week between building something and someone using it is a week of unvalidated decisions accumulating on top of each other.
Expect the scope to shrink
A build that reaches release with the original scope intact has usually not been examined. Real discovery removes things: features that turn out to serve one person, steps that exist because the previous system required them, reports nobody reads.
The useful measure of a first release is not how much it contains but how quickly it can be put in front of someone.
Plan for the second release before the first ships
Most of the value arrives in version two, because version two is informed by usage. That has a practical consequence: the first build should be easy to change where you expect to learn something and can be rigid elsewhere.
Knowing which parts are which is the actual expertise. Making everything flexible costs as much as building the wrong thing and takes longer.
Handover is a deliverable
A system nobody can maintain is a liability regardless of how well it works on delivery day. Settle before the contract, not after:
- Who owns the intellectual property, in writing.
- Whose cloud accounts the infrastructure runs in.
- Whether you have repository access throughout or only at the end.
- What documentation exists, and whether a different team could pick it up cold.
The ongoing cost is not optional
Dependencies need patching whether or not you are adding features. APIs you consume will deprecate versions on their timeline. Plan for roughly fifteen to twenty per cent of the build cost per year, indefinitely, and identify who internally owns the system’s direction.
Without a named owner, custom software becomes something everyone depends on and nobody is allowed to change.
We develop custom software from offices in the United States, Saudi Arabia and South Africa, with engineering in Islamabad. See how we approach custom software development, or read about choosing between an ERP module and a custom workflow. For what the budget is actually spent on, see where the money goes in a custom build.
Common questions
How long does custom software take to build?
It depends less on feature count than on how much discovery is needed. Budget real time for observing the process before building — a week or two of watching the work is the cheapest risk reduction available, and it usually shrinks the scope.
What ongoing costs should we plan for?
Roughly fifteen to twenty per cent of the build cost per year, indefinitely. Dependencies need patching whether or not you add features, and APIs you consume will deprecate versions on their timeline rather than yours.
Who should own the code we pay for?
You should, in writing, before the contract is signed. Settle intellectual property, whose cloud accounts the infrastructure runs in, repository access throughout the build, and what documentation is delivered.
