AI prototype for one use case
Two weeks from the kickoff workshop you have a working AI prototype and the number it saves.
You pick one process. We measure what it costs you today, build a prototype that runs it, and put the two numbers side by side. Working software, source code and documentation, ten working days from the workshop.
Two weeks from the kickoff workshop. Not from the first email. The clock starts the day the use case is agreed and the baseline is written down.
One use case, measured before anything is built. What the process costs you today goes into the contract as a number. The prototype is judged against that number and nothing else.
The Proven-Savings Prototype Guarantee. Late, short of the written requirements, or under a 75% cut against that baseline, and you get your money back.
The AI budget nobody wants to sign
Somebody has asked what AI would do here. The answers come back as platform licences, a discovery phase, and a programme that runs for three quarters before it touches a real process. The number at the bottom is large enough that signing it is a career decision.
So the question gets researched instead. A vendor demo, a strategy workshop, a pilot that never leaves the slide deck. Nine months later you know more about AI in general and nothing about AI on this process, with this data.
What would settle it is small. One process, running for real, with the cost before and the cost after written down.
Measure first, then build
The scope is one use case. Not a platform, not a strategy, not an integration programme. One process somebody runs today, with a cost that can be written down before the build starts.
The workshop measures that cost. Minutes per case, cases per month, at the rate you already pay. The figure goes into the contract, and it is the only thing the prototype is measured against. Both sides sign it before the build, so neither can move it later.
Then the build. AI drafts the parts that are the same in every codebase, and every line is reviewed and tested before it runs on your data. What comes out is ordinary software in an ordinary repository.
What you get
One use case, agreed in writing before the build starts, for a fee fixed at the same time.
A requirements workshop, four to six hours. The use case is chosen, the requirements are written down, and the cost of the process today is measured with the people who run it.
The build sprint. A prototype that runs the agreed use case end to end on your own examples, built against the signed requirements.
A presentation and next steps, two to four hours. What the prototype does, what it deliberately does not do, the before-and-after measurement against the workshop baseline, and what production would involve.
Working software, source code and documentation. Yours. How to run it, what it depends on, how to deploy it. Written so another supplier could pick it up without calling.
What the two weeks look like
Day 0
The kickoff workshop. Four to six hours. The use case is agreed, the requirements signed, the baseline measured and recorded. The clock starts here.
Working days 1 to 7
The build. Partway through you see the prototype running on your own examples, and again at the end.
Working days 8 and 9
The prototype runs against real cases from your process, and the result is measured against the baseline.
Working day 10
Presentation, two to four hours. The measurement, the software, the source, the documentation, and a written recommendation on what production would take.
Ten working days, counted from the workshop and never from the first email. If access to a system or to real example cases is outstanding, the clock pauses until it is granted, and you are told that day.
The Proven-Savings Prototype Guarantee
Delivered inside ten working days of the kickoff workshop, matching the signed requirements, and demonstrating at least a 75% cost reduction on the agreed use case against the baseline measured in that workshop. Miss any of the three and you get your money back.
The 75% is a promise with a refund behind it. Nothing here reports what anyone else saved. It states what has to be true at the presentation, and what happens if it is not.
The baseline is measured with you, in the workshop. Recorded with the people who run the process and signed by both sides before the build. If you disagree with the figure at the workshop, it is rewritten there. Afterwards neither side can move it.
The requirements document is the only measure of scope. Signed at the workshop. What is handed over is compared against that document and nothing else.
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. Someone at the workshop who can decide the use case, access to the systems the process touches, and real example cases to run against.
How you claim. Email info@peakcodeconsulting.ch within thirty days of the presentation, naming the requirement missed or the figure not reached. You get an answer within ten working days.
These terms go into the contract before the build starts, in these words. You can hold us to every one of them.
Who this is for
This is for you if
- One process somebody runs by hand today is the obvious candidate.
- Somebody can say how long that process takes and how often it runs.
- You want an answer on this process before a larger AI budget is committed.
- You can supply real example cases for the prototype to run against.
This is not for you if
- You want an AI strategy for the whole company. This answers one use case.
- The process is written down nowhere and nobody agrees on how it runs.
- You need a production system on day one. The next step is quoted separately.
- No example data can be shared in any form, anonymised included.
The questions we get asked
- What does it cost?
- Quoted in writing after the first call, against the use case you bring. There is no list price, because pricing a prototype before seeing the process is guessing. The fee is fixed before the build starts and does not move afterwards.
- Is the 75% a promise or a past result?
- A promise, with a refund of the fee behind it. It is the number that has to be true at the presentation, measured against the baseline recorded in the workshop. No client result is claimed here and no client is named.
- Is this a demo or working software?
- Working software. It runs the agreed use case on your own examples, and you get the source and the documentation. The scope is one use case rather than a production system, and everything outside it is deliberately absent.
- What happens to our data?
- The prototype runs on example cases you supply, and where those cases are processed is agreed in writing before anything is loaded. If the data cannot leave your systems, that constraint goes into the requirements at the workshop.
- What happens after the two weeks?
- You decide. Either the prototype and the measurement go to whoever signs the larger budget, or the next build is quoted, or nothing happens. The recommendation on the presentation day says plainly when stopping is the right answer.
Tell us which process to test
The first call is free.
Describe the process. We come back within 48 hours on whether it fits two weeks, what the baseline measurement would need, and what the workshop would have to cover.
If the honest answer is that AI is the wrong tool for what you are describing, the reply says so.