Coddect
Automated document analysis: turnaround divided by 14, costs divided by 30, 60 files processed per month.
Sixty days to find out whether your hypothesis holds. Not a polished demo that impresses in a meeting, but a product connected to your real data, with a quality measurement you can put in front of your board.
A successful demo does not prove a product is viable. That is the most expensive misunderstanding in these projects: three working cases are presented, the room is convinced, and six months later the error rate on real cases turns out to make the product unusable.
A serious prototype therefore answers four measurable questions. Does it work on a representative sample, awkward cases included? What is the error rate, and what rate can your business absorb? What does one unit of processing cost, and does that cost hold at the intended scale? And what happens when the system is wrong — who sees it, who corrects it?
Until those four answers are quantified, you have not validated a hypothesis, you have funded a demonstration.
People usually approach me with a technology question — which model, which provider, which architecture. In the large majority of cases, that is not where the project is decided.
What decides it is the state of your data. Does it actually exist, or does it have to be produced? Is it technically accessible, or locked in a tool nobody has an export from? Is there enough of it for the result to be meaningful? Is it allowed to be used for this purpose, under GDPR and your own customer commitments?
Those four checks happen during the two scoping days. I have concluded more than once that six weeks of data collection had to come before any development — far better news than discovering it in month two of a fixed-price engagement.
Four causes recur, and none of them is technical.
A scope chosen to impress rather than to decide: the most spectacular feature gets built instead of the one answering the riskiest question. No evaluation protocol, which makes comparing two versions impossible. Forgetting the human work around the system — correction, review, handling rejected cases — which is often where the real running cost sits. And confusing a product that works with a product someone will pay for.
My protection against this is simple: attack the riskiest hypothesis first. If it collapses, it collapses after three weeks rather than nine months, and you have saved the difference.
The format is the sixty-day fixed price: two weeks of scoping and architecture, five weeks of build delivered in weekly increments, one week of production launch and handover. The detail of scope, inclusions and exclusions is set out on the MVP development page.
Pricing starts at €29,000. The prior scoping engagement is billed at €4,900 and credited if the project goes ahead. The quote goes out within five working days of the workshop.
| The question it answers | What it does not prove | |
|---|---|---|
| POC | Is this technically feasible in our context? | That anyone will use it, or that unit cost holds |
| Prototype | What does it look like, and is the output good enough? | That the product is usable in real conditions |
| MVP | Do users actually use it, and pay for it? | That it will hold up at scale |
| V1 | Can we run it sustainably and sell it? |
Confusing these four is the leading source of misunderstanding on a quote. A prototype sold at MVP price, or the reverse, is always paid for somewhere.
Automated document analysis: turnaround divided by 14, costs divided by 30, 60 files processed per month.
Reference database for HR teams: over 2,000 job roles indexed, with skills, supply and demand.
The first fully independent French news site, debiased and free of advertising.
The fixed price starts at €29,000 for sixty days, scoping included in the process. An AI project is not mechanically more expensive than a conventional one: the cost driver is the state of your data and the quality level required, not the presence of a model.
Rarely, and almost never at prototype stage. In the large majority of cases an existing model, properly tooled — good data preparation, good guardrails, good evaluation — produces a better result at a fraction of the cost. Custom training becomes justified when you hold a genuinely distinctive volume of proprietary data.
It depends entirely on the use case, and that is precisely what scoping determines. For many document analysis cases, a few hundred representative examples are enough to measure whether the approach holds. What matters more than volume is that the sample reflects the hard cases, not only the easy ones.
Through a protocol defined with you at scoping, on an annotated sample the system has never seen. We set the acceptable threshold for your business together before starting, which avoids the most painful conversation of the final day: deciding whether the output is good.
It is a scoping item, not an end-of-project formality. We check the legal basis for the use, where the data is processed, what is sent to an external provider and what is not allowed to leave. When sensitivity requires it, we favour processing that keeps your data inside the European Union.
Sometimes yes, when the architecture was designed for it — and I design it for that. But I do not promise it: a prototype whose only job was to settle a question may deserve to be thrown away once the answer is in. The knowledge gained is then worth more than the code produced.
Book 30 minutes, or describe your idea in a few lines. We reply within 5 business days with free scoping — scope, risks, timeline and engagement pricing.