The 10-day sprint: how I ship a production-ready module

Why such a tight format

Most freelance engagements fail on the same thing: a fuzzy scope, weeks with no visibility, and a deliverable that's only "almost done" to the person who wrote it. The Product Sprint is my answer to those three risks — 10 days, a scope frozen in writing, a fixed price, and an artifact delivered every day.

The perimeter is deliberately small. One module, one feature, one AI integration — not three. That's what makes it finishable, in the production sense: merged, tested, deployed, handed over.

Day 0 — scoping (free, and eliminatory both ways)

It all starts with a 30-minute call, free. Its goal isn't to sell: it's an honest go/no-go. I ask the uncomfortable questions — what already exists, what's been tried, who maintains the module after me, and what "successful" looks like to you, in one measurable sentence.

Two possible outcomes:

• No-go: I'm not the right profile, or the subject doesn't fit in 10 days without distorting it. I say so immediately, and point you elsewhere if I can.
• Go: within 48 h you receive a one-page written proposal — frozen scope, explicit success criteria, fixed price, terms (50% at kick-off, 50% at delivery).

That document is the moral contract of the sprint. Anything not in it is not in the sprint — that's what protects the timeline, and therefore your budget.

Day 1 — kick-off: architecture before code

The first day doesn't produce a feature. It produces the frame that makes the next nine fast:

• access to your repo, your CI, your staging — I work in your house, not on a clone that will drift;
• architecture decisions written down: where the module lives, what boundaries with the existing code, which patterns (yours first — a module that clashes with the rest of the codebase is debt, not a gift);
• dedicated branch, compiling skeleton, first commit by end of day.

That evening you get the first written progress note: five lines, what's done, what's blocked, what's coming tomorrow. You'll get one every working day — non-negotiable, and it replaces the status meeting.

Days 2-7 — implementation, with a mid-sprint demo

Six days of building, with two disciplines:

Tests go with the code, they don't trail it. The module's critical paths are covered as we go — unit on the logic, integration on the boundaries. That's what makes Day 10 calm rather than heroic.

The mid-sprint demo (around Day 5) is on the real thing. Not slides: the module running, wired to your staging data. That's when we adjust — a UX detail, a business case missed at scoping. Adjustments that fit the envelope are folded in; those that don't are noted for a possible next sprint, and we say so clearly.

Days 8-9 — staging, monitoring, and production if it's ready

A module "done on my machine" is not done:

• deployment to your staging via your CI/CD (I extend it if needed, I don't replace it);
• monitoring wired: structured logs, metrics on the critical paths, alerts on what should wake someone up;
• production rollout if your process allows it within the window — otherwise everything is ready for your team to do it without me.

Day 10 — the delivery that creates no dependency

The last day is entirely about handover:

• final demo against the success criteria written on Day 0 — each criterion is green, or its state is documented without ambiguity;
• PR merged into your main branch, reviewed by your team if you have one;
• architecture doc: the decisions made and their why, not a novel — what's needed so the next developer doesn't undo in a month what was thought through in ten days;
• handover session over a call with your team: the code, the choices, the traps, the questions.

After Day 10, questions and fixes on the delivered scope are included. The goal is explicit: no dependency on my presence. If your team can't evolve the module without me, I missed something.

What I refuse to put in a sprint

The format doesn't fit everything, and saying so is part of the offer:

• a full rewrite — 10 days isn't enough, and pretending otherwise produces sloppy work;
• a scope that depends on uncontrolled external unknowns (a third party who must deliver "soon", an API that isn't documented yet);
• frozen legacy with no room to manoeuvre — if nothing can move, nobody can deliver cleanly inside it.

For those cases, the right format is a longer engagement — or sometimes, honestly, something other than a freelancer.

The questions I get at scoping

Why a fixed price rather than a day rate? Because the overrun risk should be on me, not on you. The frozen scope is the counterpart: it's what makes the fixed price tenable.

And if the sprint reveals a bigger problem? It happens — a sprint is also a full-scale audit of your codebase. The problem is documented, costed, and you decide: next sprint, longer engagement, or nothing. No pressure — the current sprint's deliverable is still owed.

Ten consecutive days? Full but spreadable over three weeks — it absorbs your scheduling constraints and mine without diluting the commitment.

The full offer, pricing and other formats are on the services page. And if you want to check that I actually deliver — four of my products are online, publicly testable.