A small first release
One process, done well, live in weeks. Real usage tells us more about what to build next than another month of workshops would.
✦ How we work
How we work: scope, build, launch, run
Rapid application development without the hand-waving. A half-day mapping your process, a written scope with a fixed price, working software every week, then a retainer that keeps it running and improving.
✦ Four stages
The software development process, start to finish
1
Scope
A half-day session with the people who actually do the work, not just the people who describe it. We map the process step by step, note every system it touches and every workaround that has grown up around it. You get a written scope, a proposed first release and a fixed price. If we think you should buy something off the shelf, this is where we say so.
2
Build
Short cycles with something working at the end of each one. You get a staging link from the first week and a demo every week after that. Your team is in the same channel as the engineers building it, so a question that would take a week of emails takes ten minutes. No six-month silence, no big reveal.
3
Launch
Data migrated and validated against the old system, training for the people who will use it daily, and a period of parallel running where both systems are live so nobody is betting the operation on a single switchover. We agree the cutover criteria in advance and only move when they are met.
4
Run
Monitoring, backups, security patching and support under the monthly retainer, plus an allowance of small changes each month. Every quarter we look at how the software is actually being used and agree what to improve next. The product keeps getting better instead of quietly rotting.
✦ Rapid, defined properly
What makes this fast
Speed comes from cutting the right things, not from working weekends.
Boring technology
We use well-supported tools that we and other developers can maintain for a decade. Novelty is a cost you pay in year three.
One decision-maker
Fast projects have one person who can settle a question the same day. Committees are the single most common cause of delay we see.
✦ Your side
What we need from you
Not much, but the things we do need are non-negotiable.
- One decision-maker who can answer questions within a day
- Access to two or three people who do the work the software will support
- An hour a week for the demo, from the same people each time
- Read access to the systems we need to integrate with, plus a contact at the vendor if there is one
- A sample of real data, warts and all - cleaned-up examples hide the hard problems
- Honesty about the workarounds. The spreadsheet nobody admits to is usually the most important requirement.
✦ Change requests
How we handle changes mid-build
Requirements change during a build. That is normal, and a process that pretends otherwise just produces software nobody wanted.
Small changes inside the agreed scope get absorbed - a field, a label, a different sort order. Anything larger, we price before we build it and you decide. If something new matters more than something already in the scope, we swap them rather than adding to the bill.
What we do not do is quietly log a change, build it, and present the invoice at the end. You will always know a change has a cost before it is made.
✦ Expectations
What a typical engagement looks like
Rough shape, so you can plan around it. Exact timings come out of the scoping session.
| Stage | Who is involved | What you get |
|---|---|---|
| First call (30 minutes) | You and one of our engineers | An honest view on whether custom software fits, and what we would look at first |
| Scoping (half a day) | Your team, our engineer and designer | A written scope, a first-release proposal and a fixed price |
| Build (weeks, in short cycles) | Our build team, your decision-maker | A staging link, a weekly demo and working software at each cycle |
| Launch | Everyone who uses it | Migrated data, trained users, parallel running, then cutover |
| Run (ongoing) | Our support team, your team | Monitoring, fixes, small changes and a quarterly improvement plan |
✦ Questions we get asked
How we work: the usual questions
How long does a first release take?
Weeks rather than quarters for a single well-defined process. Larger systems get broken into releases so something useful goes live early rather than everything landing at the end.
Do we have to replace everything at once?
No, and we would advise against it. We build the part that hurts most, run it alongside what you have, and move the rest across in slices once the first piece has proven itself.
Who writes the specification?
We do, out of the scoping session, and you sign it off. Handing a client a blank template and asking them to specify software is how projects end up quoted against the wrong thing.
What if the scope turns out to be wrong?
We reprice or reprioritise openly. Because the build runs in short cycles with a demo every week, a wrong assumption surfaces in days, not at the end of a six-month project.
Can we use our own developers alongside you?
Yes. We work in your repository with the same review process your team uses, and we are happy to hand over more of the build as your people get up to speed.
Start with the scoping call. We'll tell you what we'd build.
Thirty minutes to work out whether there is a project here at all. If there is, the next step is a half-day mapping your process and a fixed price against it.
No pitch deck · We map your process · You own the software