Six stages, and you can stop after any of them
The most expensive thing in software is not development. It is building the wrong thing carefully, for months, before anyone finds out. Everything below exists to make that less likely.
Discovery
Two to three weeks. We sit with the people doing the work and map the process as it actually happens - including the workarounds, because that is where the real rules live. You get a written scope with a cost range, and it is yours whether or not you continue with us.
Design
How it works before how it looks. Screens, flows and the data model, reviewed with the people who will use it every day rather than only the person paying for it. Changing a diagram costs nothing; changing a built system costs a fortnight.
Build
Shipped in stages, each one a working thing rather than a milestone on a chart. You see progress weekly and can redirect at any stage boundary. Nothing disappears into a three-month black box. Real usage tells you things no workshop will, so each slice is built on what actually happened rather than what we assumed in week one.
Migrate
Its own phase with its own budget, not an afterthought in the final week. We extract, clean and map your existing data, then rehearse the migration more than once before anything goes live.
Launch
Gradual where possible. Real users on the new system while the old one stays readable, so nobody is cut off from history while they are still learning. Training for the people who use it, at the point they need it rather than a month before.
Run or hand over
Keep us on for support and ongoing development, or take it in-house. Both are genuinely available because the code and infrastructure were yours from day one. We help with handover rather than obstruct it.
What we won't compromise on
You own it, from the first commit
Repository under your account. Infrastructure in your accounts, billed to you. No licence, no buy-out clause, nothing that makes leaving us difficult. We don't build dependency on ourselves as a retention strategy.
We have shipped the hard parts
Checkout and card payments, finance at the point of sale, dealer portals, trade pricing, registration lookups against live vehicle data, and the data migrations underneath them. Already built, already running.
Small releases, early
A first usable release in weeks, not a big launch in months. Real usage tells you things no workshop will, and finding out early is the cheapest time to find out.
Written down, in plain English
Scope, decisions, architecture and the reasoning behind them. Documentation for the people who use it and for whoever maintains it after us - including if that is not us.
Exit points at every stage
You can stop, change direction or change supplier at any stage boundary. No twelve-month commitment made before anyone understood the problem.
We run our own products
RampDesk and NearOps are ours, live and supported by us. We live with our design decisions instead of handing them over, which is why we're opinionated about the boring parts.
What we expect from you
Software projects fail from both sides, and it is worth being direct about the client half of it. None of what follows is unusual - most development contracts ask for the same things, usually in smaller print.
One person who can decide. Not a committee, and not someone who has to take every question upstairs. They don't need to be technical, and they don't need to be the person paying. They need to be able to say yes. Where several people have opinions, argue them out and send us one answer. Three that contradict each other, a week apart, is the expensive version.
Access to the people doing the work. Not just the person signing off. The most valuable hour in any build is the one spent watching someone do the job the software is meant to replace. That is where the workarounds surface, and the workarounds are usually the real requirements.
Decisions within a few days. A build stalls on open questions faster than on hard problems. We'll keep the list short and visible so it is never a surprise what we're waiting on. When an answer takes a fortnight, the stage moves out by about a fortnight. That is worth saying now rather than in a revised timeline later, where it would look like our slip.
Your data, and the way in. Exports, logins, the spreadsheet somebody keeps on their own machine, and someone who can tell us what the odd columns mean. Migration is its own stage for a reason, and it cannot start on goodwill.
Honesty about the mess. Every business has processes that are undocumented, data that is inconsistent, and workarounds nobody is proud of. We have never once been surprised by it. Telling us in week one is much cheaper than us finding out in week six.
How it works in practice
How much does discovery cost?
It is a small fixed price relative to a build, scoped to two or three weeks. It produces a written plan with a cost range that is yours to keep - including taking it to another supplier for comparison. We would rather you paid a little to find out the project should not happen than a lot to discover it halfway through.
What if we want to change direction mid-project?
That is expected rather than a problem, and the staged structure exists precisely for it. Each stage is quoted separately, so at every boundary you can continue, change what comes next, pause, or stop. Real usage routinely changes what matters, and a process that cannot absorb that is a process that delivers the wrong thing on time.
Do you work fixed price or time and materials?
Staged, which is a third option and in our experience the best of the three. Discovery is a small fixed price. Each build stage is quoted once the previous one has taught everyone something real. You get cost certainty for the work in front of you without paying a contingency premium for eighteen months of unknowns.
Who will actually work on our project?
The people you meet. We're deliberately small, which means you're not handed to a junior team after the sale - a pattern common enough in this industry that it is worth asking every supplier you talk to.
What happens after launch?
Whatever suits you - stage six covers the choice itself. In practice a handover takes a day to a week, depending on how big the system is. We walk your team through the code, the infrastructure and the decisions behind both. And we keep answering questions after the last day.
How do you handle our data during the project?
We work with the minimum we need, use anonymised or sample data in development wherever it is possible, and keep production access limited and logged. Where a project involves personal data we'll agree the specifics in writing before starting rather than afterwards.
Tell us what is slowing you down
A short conversation is usually enough for us to tell you what it would take to fix it, and what it would cost you to leave it alone.