Sprint zero
A fixed-scope discovery: audit, architecture, costed roadmap and a clickable prototype.
- — Technical audit
- — Solution architecture
- — Costed delivery plan
Descending through the problem, on purpose.
Every engagement runs through the same four phases, whether it's a two-week discovery sprint or a multi-year platform partnership. The names stay boring on purpose — the work is where the craft shows up. What comes out of that process is never the same twice: two problems that look similar on paper can need completely different solutions, and the fastest way to build the wrong one is to reach for whatever worked last time.
Weeks 1–2
Discovery
We spend two weeks in your codebase, your metrics and your team's heads before writing a line of production code. That means technical audits of what already exists, interviews with the people who'll use what we build, and enough architecture thinking to catch expensive mistakes on paper instead of in production. You leave discovery with a written plan you own — usable even if you never hire us for the build.
Weeks 2–4
Design
Prototypes you can click through, not slide decks you have to imagine. For product work, that's a design system and key screens. For infrastructure work, it's an architecture diagram and a migration plan with rollback points. Either way, this is where we surface disagreements while they're still cheap to resolve.
Ongoing, two-week cycles
Build
Every sprint ends with a live demo of something real and deployable — not a status update about progress you can't see. We work in the open: you can watch the backlog, join standups, or just show up every two weeks and see what shipped. Nothing waits for a big-bang launch.
Ongoing
Operate
Shipping isn't the finish line. We stay on to monitor what we built, iterate against real usage data, and keep a roadmap that weighs new features against technical debt honestly. Most of our client relationships outlast the original project scope by years, not months.
Same process. Never the same solution.
Four examples of problems that walk through the exact same discovery-design-build-operate cycle above and come out the other side looking nothing alike.
The problem
Validate an idea before spending real money.
Lean and fastA tight Sprint Zero, a single small team, and a shippable version in weeks. Architecture that scales to a million users is wasted effort on a product that doesn't have ten yet — we build for the stage you're actually at, not the one you're hoping for.
The problem
Migrate off infrastructure that can't go down.
Slow, staged, reversibleHeavy discovery up front, old and new systems running in parallel until the new one's proven, and a rollback plan at every stage. The cost of moving fast here isn't a wasted sprint — it's an outage. We move at the speed the risk demands.
The problem
An AI pilot that worked in the demo and fell apart with real users.
Foundation before featuresWe stop adding capability and start fixing the data pipeline and evaluation harness underneath it — the unglamorous work that's usually the actual reason the first version didn't hold up.
The problem
Ten disconnected systems, not a missing product.
Integrate, don't rebuildNo new product to build — a connective layer that makes what you already have behave like one system, without a risky rip-and-replace nobody asked for.
Everything on board, nothing outsourced.
One crew handles discovery, design, engineering and operations — so nothing gets lost in the handover between agencies. How that crew is structured around your problem is a separate decision, made after we understand it, not before.
Build squad
A cross-functional crew — product, design, engineering — shipping to production fortnightly.
- — Dedicated team
- — Fortnightly releases
- — Live demo every sprint
Deep support
We keep the systems we build alive: SLAs, on-call, iteration and quarterly roadmapping.
- — 24/7 monitoring
- — Response SLAs
- — Quarterly roadmap
“They replaced three vendors and a decade of duct tape in a single quarter — and we never took the platform offline.”
Process FAQ
How long does discovery actually take?
Two weeks for most engagements — long enough to audit an existing system or scope a new one properly, short enough that it doesn't become its own project. Larger, multi-team platforms sometimes need three to four weeks; we'll tell you upfront if yours does.
What if we already know exactly what we want built?
We still run a short discovery pass — usually compressed to a few days — because the brief and the codebase don't always agree, and that gap is where budgets and timelines quietly blow up. It's cheaper to find that in week one than in week six.
Do you work with in-house teams, or only as a full outsourced team?
Both, and it's set by the engagement model, not a rule. A Build Squad embeds alongside your existing engineers; Sprint Zero is typically standalone discovery you hand to whoever builds it next, including your own team.
How do you price engagements?
Sprint Zero is a fixed price for a fixed two-week scope. Build Squad and Deep Support are typically monthly retainers scoped to team size and SLA — we'll give you a real number after discovery, not a range designed to be renegotiated later.
What happens if we want to bring the work in-house later?
You can. We document architecture decisions and hand over a system a new hire can actually understand, specifically so that staying with us is a choice you keep making, not a lock-in.
More questions? See the full FAQ or talk to us directly.