Build Sprint
The tool your operation needs, in production in weeks, at a price agreed before we start.
- Price
- from €9,000, fixed
- Duration
- 2–4 weeks
- Commitment
- One-off
The problem it solves
The tool your operation needs is too small for an integrator to bid properly, too specific to buy off the shelf, and permanently sixth in the IT queue behind the billing migration. So the rollout runs on a shared spreadsheet, dispatch happens over WhatsApp, and everyone builds their own version of the numbers.
What you get
-
A working system in production
Deployed, at a URL, running on your real data, used by the team that needed it — not a pilot environment nobody logs into.
-
The repository
Yours, with full commit history. No licence, no per-seat fee, no black box, and no dependency on us to keep it running.
-
Documentation and a recorded walkthrough
Written for whoever maintains it next, including the parts that aren't obvious.
-
A handover session
With your IT team if you have one — how it works, how to change it, how to run it without us.
-
Two weeks of post-launch support
Anything broken gets fixed. Included, not billed.
Timeline
-
Week 1
Scope lock
What's in, what's explicitly out, what "done" means, and which systems it reads from — in writing, signed by both of us before anything is built.
-
Weeks 1–3
Build
Something you can click on by the end of week one, and a checkpoint every week after. Not a status update — the actual thing, rough.
-
Week 3–4
Hardening
Edge cases, data validation, access control, documentation, and your security review if one is required.
-
Final days
Deploy and handover
Production deploy, handover session with IT, walkthrough recording.
What moves the price
- How many systems it reads from, and whether they have usable APIs
- Internal tool versus production system — SSO, audit trails and a security review are real work
- Whether it runs inside your infrastructure or hosted
- Number of user roles and how different their views need to be
- Deadline pressure — a compressed timeline is a premium, not a favour
What we need from you
- A written scope we both sign off before day one
- System access or credentials in week one, not week three
- One named person who can answer domain questions within a day
- Two or three real users to test it in week two, while there's still time to change it
A good fit if
- You can describe the outcome in a sentence
- The scope can be frozen for three weeks
- It's a current operational problem, not a nice-to-have
- You want to own the code and run it yourself afterwards
Not a fit if
- You're replacing your OSS, BSS or ERP — we are not it, and we will say so on the call
- Scope can't be frozen because requirements are still moving
- The real blocker is that two departments don't agree — that's a diagnostic
- You need a standing engineering team rather than a system
What usually gets built
These recur across almost every operation of this shape. Each is a sprint:
- Rollout and deployment tracking — where every site actually is against plan, without three people maintaining the same spreadsheet
- Subcontractor and crew scorecards — quality, rework rate and cost per job, visible before the month-end surprise rather than after it
- Provisioning and order exception views — the orders that are stuck and why, without trawling the ticketing system
- Dispatch and scheduling support — the layer your field service platform doesn’t cover
- Regulatory and SLA reporting — the monthly hand-rebuild, automated, with the numbers reconciled once
- Integrations nobody will scope — the join between the ticketing platform, the ERP and the field app that keeps getting deferred
Why fixed price, not a day rate
An hourly rate would price speed as a penalty. The delivery advantage comes from how we work — billing by the hour would hand that advantage to you and then quietly punish us for it.
Fixed price means we agree the outcome, and how fast we get there is our problem and our incentive. It also means you carry no overrun risk. If it takes longer than we estimated, that is not your invoice, and it is not a change request.
Common questions
Can you handle the regulatory and compliance side, not just the software?
Yes, and it is usually the part that decides whether something is workable. Reporting obligations, licensing and permitting, and what a regulator will actually accept as evidence shape the data model long before anyone writes code. We would rather raise those constraints in week one than discover them at go-live.
Is what you build a prototype, or is it production software?
Production. A build sprint ends with a system deployed at a URL, running on real data, with the repository handed to you. The diagnostic includes a genuine working prototype rather than a mockup, but it is scoped as a proof — the sprint is what hardens it.
Who owns the code?
You do, entirely. You get the repository with its full commit history, the documentation, and a handover session covering how to run and change it without us. There is no licence, no hosting lock-in, and no black box.
Who maintains the system after you hand it over?
That is exactly why the handover is part of the deliverable rather than an optional extra. You hold the code, the documentation and the walkthrough recording, so any competent developer can pick it up. If you would rather we kept it running and improving, that is what Run is for — a flat monthly fee, and the code stays yours.
You use AI to build. Does that mean the work is generated?
No. AI compresses implementation — scaffolding, boilerplate, integration glue, iteration speed. It does not decide which problem is worth solving, sit in the room with your team, or own the outcome. Those are the job. The speed is why this is affordable; the judgement is what you're buying.
Will you work with our IT and security review?
Yes, and it is better to involve them in week one than week three. Tell us at scoping that a review is required and we will plan for it — it affects the architecture and the timeline, and pretending otherwise is how fixed-price projects go wrong.
How do you price?
Fixed price for a defined scope, never an hourly rate. You agree the number before work starts and carry no overrun risk. Ranges are published on each service page along with what moves them, so you can estimate before we speak.
We're small. Are we too small for this?
Probably not — small companies are the ones with no analyst and no spare engineering capacity, which is the whole reason this exists. If a diagnostic is more than the problem is worth, we will tell you on the call and suggest something cheaper, including doing nothing.
We reply within one business day.