AI software development sprint
Your next release is scoped, built and handed over 15 days from the kickoff workshop.
You bring the requirements. We write them down, build against them, and hand over working software with the source. Fifteen working days from the kickoff workshop, matching what was agreed, at least 75% below the estimate you are working with today.
Fifteen working days from the kickoff workshop. Not from the first email. The clock starts the day the requirements are signed off, and that day is in the contract.
The requirements are written before anything is built. What ships is measured against that document. If it does not match, it is not done, and it is not billed as done.
The Sprint Delivery Guarantee. Late, short of the written requirements, or above 25% of the estimate you came in with, and you get your money back.
The release that was supposed to be out by now
The requirements exist. Somebody wrote them, somebody argued about them, and they have been stable for a while. What is missing is the capacity to build the thing, and the capacity is missing because everyone who could build it is holding up something that is already in production.
So the quote goes out for tender. It comes back with a number that assumes a discovery phase, a ramp-up, and a team that has to learn your domain before it writes a line. Most of the estimate is not the software. It is the cost of somebody arriving.
Meanwhile the release slips another quarter, and the reason it slipped is not technical.
Why fifteen days is a real number
The sprint is short because the discovery is compressed into the workshop, not spread across six weeks of meetings. Four to eight hours, everyone who has an opinion in the room, and the output is a written requirements document that both sides sign.
The build is short because AI writes the parts of a codebase that have been written a million times before: the scaffolding, the data access, the tests around the edges, the boilerplate that consumes most of an estimate and none of the thinking. What it does not do is decide what to build, or judge whether the result is correct. That is the work, and that is what the fifteen days are actually spent on.
The result is ordinary software in an ordinary repository. It is not generated and abandoned. It is reviewed line by line, tested against the requirements document, and handed over with the source, because a release you cannot maintain is not a release.
What you get
One fixed scope, agreed in writing before the sprint starts.
A requirements workshop, four to eight hours. The scope is fixed here and written down. Anything that does not make the document does not make the sprint, and both sides know which is which before the clock starts.
A ten-day build sprint. Built against the signed requirements, in your repository or one handed to you at the end. Every requirement in the document has a check behind it, and that is how the guarantee is settled.
A presentation and handover day. A walkthrough of what was built, what was deliberately left out, and what the next sensible increment is.
The source code and written documentation. Architecture, dependencies, how to run it, how to deploy it. Written so another supplier could pick it up without calling. What transfers on the handover day, and on what terms, is set out in the contract before the sprint starts.
What the fifteen days look like
Day 0
The requirements workshop. Four to eight hours. The scope is fixed and signed. The clock starts here.
Days 1 to 10
The build sprint. A working increment is visible at the end of each week, not only at the end.
Days 11 to 14
Testing against the requirements document, and the corrections that come out of it.
Day 15
Presentation, handover of the source and the documentation, and a written recommendation for the next increment.
Fifteen working days, counted from the day the requirements are signed. If access to a system we need is outstanding, the clock pauses until it is granted, and you are told on the day it happens.
The Sprint Delivery Guarantee
Delivered inside fifteen working days of the kickoff workshop, matching the signed requirements, at no more than 25% of the estimate you came in with. Miss any of the three and you get your money back.
The requirements document is the only measure. It is signed before the sprint starts. What ships is compared against that document and nothing else. Neither side can move it afterwards.
The cost comparison is against a figure you supply. Bring the written estimate you are working with for the same scope, from whatever source. That figure goes into the contract as the baseline. Without one, this clause of the guarantee does not apply, and the contract says so plainly.
Defects against the requirements are fixed at no cost. Nobody can guarantee software with no defects. What is guaranteed is that anything failing to match the signed requirements is corrected without a further invoice.
What is needed from you. Attendance at the workshop by someone who can make a decision, access to the systems the release touches, and a named person to answer questions during the sprint.
How you claim. Email info@peakcodeconsulting.ch within thirty days of the handover, naming the requirement that was missed or the figure that was exceeded. You get an answer within ten working days.
These terms go into the contract before the sprint starts, in these words. You can hold us to every one of them.
Who this is for
This is for you if
- The requirements exist and have been stable for a few weeks.
- One release, or one self-contained increment of one, would unblock the rest.
- Somebody on your side can commit to the scope in a single session.
- You can grant access to the systems the release has to talk to.
This is not for you if
- The scope is still being argued about. Fifteen days cannot absorb a discovery phase.
- You want a team embedded for a year. That is a different engagement and a different conversation.
- The release depends on a third party who has not committed to a date.
- You want the sprint but not the written requirements. The guarantee is settled against them.
The questions we get asked
- What does it cost?
- It is quoted in writing after the first call, against the scope you bring. There is no list price, because pricing a release before seeing the requirements is guessing. The fee is fixed before the sprint starts and does not move afterwards.
- Does AI write the production code that ships?
- AI writes the parts that are the same in every codebase and are reviewed line by line before they are committed. The architecture, the domain decisions and the correctness judgements are not delegated to it. The code that ships is code somebody read.
- Who owns the result?
- Ownership and the transfer terms are set out in the contract, and that is signed before the sprint starts. The source and the documentation are handed over on the handover day. Nothing about who holds what is left to be worked out after the build.
- What if fifteen days is not enough for the scope?
- Then the workshop says so, and the scope is cut to what fits or the sprint is not sold. A scope that does not fit is a fact worth knowing on day zero rather than day fourteen.
- What happens after the sprint?
- Either another sprint on the next increment, or nothing. The handover is written so that a further sprint is a choice rather than a dependency, and the recommendation on day fifteen says plainly when the answer is that no further work is needed.
Tell us what the release has to do
The first call is free.
Describe the release. We come back within 48 hours on whether it fits fifteen days, what would have to be cut if it does not, and what the workshop would need to cover.
If the honest answer is that this is the wrong shape of engagement for what you are describing, the reply says so.