Lead service · Business applications
Custom Software, Specified Before It Is Estimated
Most people expect to hand over a brief and get a price. We work the other way round. First we write down how the work really runs, exceptions included. Then we agree what the first release must do, and only then put a figure on it. Sometimes the honest outcome is that you should buy something instead, and we will say so.
Before any code
Custom Builds Usually Fail Before Anyone Writes Code
The trouble starts with reasonable-sounding beliefs about how software gets made. Here are the ones we hear most, what tends to happen instead, and what we do about it.
01 · The assumption
“Our brief already explains the job.”
What happens
A brief records the process as the person signing it believes it runs. The odd cases, the second approval, the column only one clerk understands: those live with whoever does the work every day.
What we do
We watch the work being done and talk to the people doing it before we draft a single screen.
02 · The assumption
“A fixed figure up front keeps us safe.”
What happens
A figure placed on a loose requirement does not remove the disagreement. It schedules it for later, usually for the week the system is meant to go live.
What we do
We put a written specification in front of you first and estimate against that document, not against a conversation.
03 · The assumption
“Version one should do everything the old way did.”
What happens
Every feature built before anyone has used the system is a guess. A long first release is late, and half of it gets reworked once real people touch it.
What we do
We agree a narrow first release that is useful on its own, then add to it based on how it is actually used.
04 · The assumption
“Once it is live, the spending stops.”
What happens
Release is when the running costs begin: hosting, library updates, small changes the business asks for, and the occasional fix nobody saw coming.
What we do
We name those costs before the build starts, and we can carry on looking after the system once it is in use.
A made-up example
Picture a Workshop Booking Repairs on a Whiteboard
This is an illustration, not a client. It shows how we would cut a requirement down to a first release worth having.
Say a repair workshop logs jobs on a whiteboard, keeps parts in a spreadsheet and chases customers by phone. The owner asks for “an app that runs the whole business”.
Watching a morning of work shows the real pain is narrower. Jobs get lost between the counter and the bench, and nobody can say which repairs are waiting on a part.
Release one
A job record with a status, the parts it is waiting on, and a single screen showing every open job.
Later, if used
Customer text updates, a parts reorder list and a monthly turnaround report.
Leave alone
Invoicing and the books. The accounting package already handles them, so the system simply exports to it.
Inside a build
The Parts a Brief Rarely Mentions
Requests describe screens. The effort mostly goes into what sits behind them, and these parts turn up in nearly every system we would write.
Records and the rules on them
The tables underneath: what is stored, what must be filled in, what can never be deleted, and which states a record is allowed to move between. Get this wrong and every screen above it inherits the mistake.
Screens for the person doing the job
Entry forms that follow the order the work actually happens in, keyboard-friendly where people type all day, with sensible defaults so the common case takes the fewest clicks.
Roles and permissions
Who can see a record, who can change it and who can sign it off. Written as rules in the system, so access no longer depends on who happens to know the shared password.
A history of every change
Who altered what, when, and from which value. Dull to build and invaluable the first time a figure is disputed or an order goes missing between departments.
Importing what you have now
Your existing spreadsheets and exports, cleaned, mapped and loaded, with the rows that do not fit reported back to you rather than quietly dropped on the floor.
Links to services you already pay for
Mail, messaging, payment gateways, accounting packages or another system's interface. Each connection logs its failures and retries sensibly instead of failing in silence.
Scope
Some Things Come With Every Build. Others Never Do.
Spelled out here so neither side has to guess later.
Included as standard
- A written specification you can read, question and sign off
- Source code in a Git repository that you control
- A test copy of the system to try changes on before they go live
- Migration of your current data, with a report of anything rejected
- Notes on setup, deployment and the reasoning behind key decisions
- Hand-over of every account and credential the system depends on
Left out on purpose
- Rewriting accounting, payroll or tax filing. Established products already do that well.
- Automating a process that has not settled yet. We would write it down with you first.
- Hosting the system under an account only we can open, unless you ask for that in writing.
- Features added mid-build without an update to the specification.
Go or no-go
We Agree to Build Only When These Hold
If any of these is missing, the useful next step is usually a conversation or a cheaper product, not a development contract.
- 01
You can describe the process on paper
If two managers would draw it differently, the drawing comes first. Software freezes whatever confusion it is given.
- 02
Buying has been tried, or ruled out for a reason
A packaged product with a monthly fee is often the cheaper answer. We would rather you hear that from us now than discover it after paying for a build.
- 03
Someone on your side will own it
A named person who decides what changes next. Systems without one drift until nobody trusts the numbers in them.
- 04
Upkeep is in the budget
Libraries age and requirements move. Plan for regular attention from the start, whether that comes from us or from anyone else.
- 05
The data stays yours to take elsewhere
Plain, documented database tables and a working export, so leaving us is a decision you can make rather than a project you dread.
Delivery
Written Down First, Built Second
Each step ends with something on paper or on screen that you can check yourself. Nobody is asked to trust a status update.
- 01
Requirement in Writing
We watch the work being done and write down what the software must handle. You correct that document until it matches reality.
- 02
Estimate With Its Limits
The estimate is drawn from the agreed document and states what it leaves out, so a later change can be priced on its own.
- 03
Small Working Releases
Features arrive in pieces you can use and check, rather than all at once near the deadline.
- 04
Tested on Ordinary Conditions
Each release is tried on modest phones, slow connections and the awkward inputs real users type.
- 05
Handover, Then Upkeep
You receive the code, the accounts and the notes. Ongoing care continues only if you choose it.
Technology
The Stack Follows the System's Job
We pick the tools after the specification, according to where the system will run and who is likely to maintain it. Fashion does not come into it.
Server and rules
- Node.js
- PHP
- Laravel
- REST APIs
Stored data
- PostgreSQL
- MySQL
- Firebase
Screens
- React
- Next.js
- TypeScript
- Tailwind CSS
Hosting and history
- AWS
- Google Cloud
- Git
After release. The same system can move straight into our application management work, so whoever fixes it later has already read the code.
How upkeep worksStart here
Bring the Spreadsheet. Skip the Specification.
Show us the file, the whiteboard or the paper form the work runs on now, and explain where it lets you down. Writing the specification is our job, and it may end with us advising you to buy rather than build.