Our approach
How we scope, build and hand over software
Clients rarely ask us to explain our process. They ask what happens after they send an email — and when they will see something they can click. This page answers that.
The first conversation
Three answers before we write a line of scope
We want three things from a first call: what the software has to do, who will use it, and what it has to connect to. If you know your timeline and your budget range, that helps too. If you do not, we can work it out — but a scope is harder to write honestly without the first three.
We will also ask what you have already tried. A failed previous build, an abandoned spreadsheet or a tool nobody uses tells us far more about the real requirements than a feature list does. Most of our desktop application work starts in that conversation.
One call is usually enough to tell whether the work is worth scoping properly. If it is not, we will tell you that on the call.
A written scope before any estimate
You get a written scope before any estimate. It states what the software does, what it deliberately does not do, what it integrates with, and what each milestone delivers.
The does not do section is the one that saves money later. It is the cheapest place to remove a feature that would have cost ten times more to remove in month three.
Two-week sprints, and a tracker you can read
Build work runs in agile sprints, usually two weeks. You get access to the issue tracker — you can see the backlog, what is in progress and what is blocked, rather than a summary written at the end of the month.
The tracker is not a formality. When a client can watch a task move from in progress to done, questions get asked earlier — and earlier questions are cheaper than later ones. It also makes the handover document easier to write, because the reasoning is already recorded rather than remembered.
Not every week looks like this one — but the shape is the point. You see movement and blocks as they happen, not when a report is written.
A build that opens beats a percentage
Milestones are demonstrable wherever possible. For a desktop application that means a staging build you can install and click through. For a game it means a playable build with the core loop running — even if the art is placeholder.
A progress percentage tells you almost nothing. A build that opens and does two of the five agreed things tells you exactly where you actually are. That is what we hand over at the end of a milestone: something you can open, not a slide.
- A staging or playable build you can install and test
- Release notes written in plain English, not changelog notation
- A short list of what did not get done, and why
- The next milestone's scope section, so you can sign it off early
Early builds, whether or not there is a storefront
For games, Early Access is a release decision we talk through before the build plan is fixed — it changes what a milestone has to contain. For business software, we use the same principle without the storefront.
A live build has to be stable enough for players, and clear about what is coming next. It suits systemic, replayable games and it hurts narrative ones — we will say which of those yours looks like.
Scope changes, priced while the decision is still yours
Scope changes. The useful question is not how to prevent them but how to price them. We handle changes as documented items with a stated effect on the schedule, so you can decide whether the change is worth the delay while the decision still belongs to you.
If a change is small and the sprint has room, it just happens and gets logged. If it is significant, it gets its own estimate. We do not treat every change request as a negotiation, and we do not quietly absorb them until the deadline suffers.
We build it, then we hand you the source
Handover means source code, build instructions, and a written record of the decisions that would otherwise be rediscovered the hard way. For desktop applications that includes deployment notes and third-party licence terms. For games it includes project files, asset pipeline notes and a reproducible build.
We do not require an ongoing contract to release the code. Maintenance arrangements are available and many clients take them — but a project that only works while we are attached to it is not a finished project.
- Source code and repositories
- Build instructions you can reproduce
- A written decision record from the sprints
- Deployment notes and third-party licence terms
- Project files and asset pipeline notes for games
Software that ships and is then kept working
Software that ships and then gets ignored decays. Users change, integrations break, Windows updates arrive. We offer support and small-change arrangements so the application keeps working — and we are blunt when a request would be better solved by changing a process than by adding a feature.
For games, post-launch work is usually bug fixes, a content update or a mod support pass. Those are ordinary engagements, and they start from the same scope document as the original build.
Do you charge for the initial scope?
It depends on how much work is needed to write one honestly. A short tool with one user group can be scoped quickly. A project with several integrations and permission levels takes real analysis — and we will say so before starting, not after.
How much involvement do you need from us?
A named person who can answer questions during the build. Projects slow down when decisions queue up, and the queue is usually the client's team, not ours. A weekly call or an active issue tracker thread is normally enough.
What happens if the deadline slips?
You hear it from us before the deadline, not after. Sprints make that visible early, which is a large part of why we use them. If a milestone is going to move, we bring the reason and the new date together.
Can we take the code and maintain it ourselves?
Yes. Handover includes source, build instructions and decision notes, and there is no contract requirement to keep working with us. Some clients stay for support and later phases; some take it in-house. Both are normal outcomes.
Send the email. We will tell you if the scope can be honest.
The first call is free and the agenda is short: what the software has to do, who will use it, what it connects to. If we cannot scope it honestly, we will say so.
Or write to [email protected] — we reply from Woodley, Reading, Monday to Friday.