Custom Software Development
Software you commission should outlive the engagement that produced it. We build for the team that inherits it — readable, tested, documented where documentation earns its keep, and free of the cleverness that reads well in review and costs you dearly in year three.
Start by narrowing the problem
The most expensive decisions on a software project are made before anyone writes code, and they are usually made too fast. We spend the first weeks establishing what the system must do, who it must do it for, what it deliberately will not do, and which constraints are genuinely fixed rather than merely assumed.
That work routinely shrinks the scope. Some of the best outcomes we have had involved talking a client out of two thirds of their original brief and shipping the remaining third properly.
How we deliver
Working software early
Something running in a real environment within the first few weeks, then extended in short cycles. Progress you can use beats progress described in a status report.
Tests that pay for themselves
Coverage concentrated where failure is expensive and behaviour is subtle. We are not interested in a percentage figure; we are interested in whether a change can be made confidently.
Boring technology, chosen deliberately
Proven tools for the parts of the system that must simply work, with novelty reserved for the places it buys you something specific. Every unusual choice should have a reason you can repeat.
Architecture that fits the team
The right structure depends on how many people will work on it and how they are organised. We size the design to your team as it is, not to a reference diagram.
Continuous delivery from day one
Pipelines, environments and release automation set up at the start, when they are cheap, rather than bolted on before launch, when they are not.
Handover as a first-class goal
Your engineers in the codebase throughout, decisions recorded with their reasoning, and a deliberate transition rather than a dropped archive.
How an engagement runs
Narrow it to one outcome
A discovery of two to four weeks that ends with a written plan, a shape, and a number — not a proposal deck. If the plan says the project should not happen, that is a result worth paying for.
Ship something real in week three
Thin and unglamorous, but deployed, in your infrastructure, exercised by someone who is not us. Everything after that is an argument about priority rather than about whether it works.
Cycle in public
Weekly, against real data. Your engineers review our pull requests from the first one, which is how the knowledge moves across rather than being handed over at the end.
Harden before feature-freeze
Load, failure modes, the boring operational work. Done while there is still budget to fix what it finds, not in the last fortnight.
Leave
A handover week where your team runs a change end to end while we watch. If they cannot, the engagement is not finished, regardless of the scope document.
What you are left with
Running system
In your accounts, in your repositories, deployable by your team from a clean machine.
Test suite
Fast enough that people actually run it, covering the failures that would cost you money.
Decision records
The why behind the architecture, including the options rejected and the reason.
Handover week
Your engineers ship a real change with us in the room, before the engagement closes.
Engagement shapes
Most work falls into one of three shapes. A discovery engagement of two to four weeks, producing a validated scope, an architecture and a costed plan. A build engagement running in cycles against that plan. Or an embedded team joining an existing effort where the constraint is capacity rather than direction.
We will tell you which one your situation calls for, including when the honest answer is that you need none of them yet.
- Discovery — two to four weeks, ends with a plan and a number
- Build — small senior team, working software every cycle
- Embedded — our engineers inside your existing team and process
- Support — an agreed level of care for systems already running
When not to hire us
We are a poor fit for staff augmentation by the seat. If what you need is four bodies who will take tickets from your backlog and not ask why, there are firms who do that well and cheaply, and we are not one of them.
We also decline projects where the scope is fixed, the date is fixed, and the budget is fixed. Something has to be able to move, or the only variable left is quality, and it will move without anyone deciding to.
Common questions
Both, and the choice should follow the uncertainty. Fixed price suits well-understood scope where the requirements are genuinely settled. When the work involves discovery, a fixed price simply moves the risk premium into the quote and pushes both sides into arguing about change requests. We often run a fixed-price discovery followed by time-and-materials delivery against the plan it produces.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.