When the spreadsheet became the system of record
Most custom software gets commissioned at the point where a business has outgrown its tools but not its workarounds. There is a spreadsheet that three people maintain, an integration that runs on someone’s laptop, and a process that only works because a specific person remembers the exceptions.
You might be here because
Situations we are brought in for
- A core process runs on spreadsheets, email and one person who knows the exceptions.
- You have evaluated the available products and every one of them fits about 70%.
- Staff spend hours a week copying data between systems that should talk to each other.
- An off-the-shelf tool would work, but only if you changed how the business operates.
What you get
Concrete deliverables, not a retainer with a hope attached
Build-or-buy assessment
Before anything is built: what the market already offers, what it would cost to bend your process to fit it, and whether custom is genuinely the cheaper answer over five years. Sometimes it is not, and we will say so.
Process mapping
How the work actually happens, drawn from the people doing it rather than from the org chart. The gap between the documented process and the real one is usually where the value is.
The system itself
Built around your workflow rather than a vendor’s: the data model, the interface the team uses daily, the integrations, and the reporting the business actually asks for.
Migration off the workarounds
The spreadsheets, shared drives and manual steps retired deliberately, with their history imported rather than abandoned.
How it works
Four phases, each with an exit you control
- 01
Observe
We sit with the people doing the work. Requirements gathered from managers describe the intended process; requirements gathered from operators describe the real one.
- 02
Narrow
Custom software goes wrong when it tries to cover every case at once. We identify the smallest slice that removes the biggest manual burden and start there.
- 03
Build in the open
Two-week cycles with the eventual users in the demo. Software for internal operations lives or dies on whether the team prefers it to the workaround.
- 04
Absorb
The old process is switched off in stages, not in one weekend. Both run in parallel until the new one has run cleanly through a full business cycle, month-end included.
Tools we reach for
Chosen per problem, not per fashion
This is what we use most for custom software. If your team is already productive in something else, we work in that instead — familiarity in your team beats preference in ours.
- TypeScript
- SvelteKit
- React
- Node.js
- Python
- PostgreSQL
- Docker
Where this usually starts
Discovery Sprint
Discovery Sprint
Deciding what to build, before committing a budget to building it
A short, fixed-scope investigation that turns an ambiguous problem into a plan you could hand to any competent team — including one that is not us.
- Typical duration
- 1–2 weeks
- Commitment
- Fixed scope, fixed fee
Includes
- Stakeholder and user interviews
- Technical constraint and risk analysis
- Architecture options with trade-offs stated
- Scoped delivery plan with sequencing
- Written recommendation, including "do not build this" where that is the answer
You keep
- Findings document
- Annotated architecture diagram
- Prioritised delivery backlog
- Effort and risk assessment
Fee agreed after scoping. No commitment to that conversation.
Common questions
How much does custom software development cost?
The honest answer is that it depends on scope, and anyone quoting before understanding the scope is guessing. What we can say is the shape: a focused internal tool replacing one process is a different order of magnitude from a platform several departments depend on. We start with a fixed-fee discovery that produces a real estimate, and you own that estimate whether or not we build it.
Should we build or buy?
Buy, wherever a product genuinely fits. Custom software earns its cost when the process is a competitive advantage, when integration between existing systems is the actual problem, or when the available products would require reshaping the business around them. If none of those apply, we will point you at the product and save you the project.
What happens if we stop working with you?
You keep everything, and you can hire anyone to continue. We work in your repositories under your license, use mainstream technology rather than anything proprietary to us, and treat documentation as part of delivery rather than a closing task. Being replaceable is a design goal.
Related reading
Twelve questions to ask a development agency before you sign
The questions that reveal how an agency actually operates - including the ones we would rather not be asked, and what a good answer sounds like.
A technical due diligence checklist you can run yourself
The questions we ask when assessing an unfamiliar codebase, in the order we ask them, with what each answer actually tells you.
Other services
Product engineering
Ship the product your roadmap keeps promising — designed, built and maintained.
Platform & infrastructure
Make deploys boring, incidents rare, and cloud spend explainable.
Legacy modernisation
Untangle the system nobody fully understands — without stopping the business.
AI & applied ML
Put language models into production without betting the product on a demo.
SaaS development
Multi-tenancy, billing and onboarding — the unglamorous parts that decide whether it scales.
Web applications
Serious applications in the browser — dashboards, editors, real-time tools that stay fast with real data.
API development
Interfaces other engineers have to live with — versioned, documented and hard to misuse.
Mobile apps
Apps that work on a bad connection, clear store review, and can be shipped weekly.
Next step
Think this is your problem?
Send us the shape of it. We will tell you whether it is a fit, what we would do first, and roughly what that takes.