Keep what works, establish what customers will depend on and invest in the gaps that matter. A prototype's origin—agency, founder or AI tool—does not settle what to do next.
Separate demand from readiness
A demonstration shows that an experience is possible. Evidence of demand shows why customers would use it. Production readiness establishes whether you can serve them dependably.
Question
Evidence to seek
Is there a business worth building?
Current alternatives, the consequence of the problem and willingness to adopt or pay.
Does this product solve the important part?
Customers completing the intended workflow and receiving its result.
Can we deliver and operate it?
Software, people and controls supporting the first customers.
More infrastructure will not establish demand. Customer enthusiasm does not make an unsafe data model ready for launch.
Decide what the first customers can depend on
A supervised pilot may tolerate manual setup. It still needs deliberate access and data controls. A consequential AI decision needs a way to recognise incorrect output. A live service needs someone capable of responding to failure.
Define the smallest product you can responsibly deliver to those users. Make its limits explicit.
Customer workflow and demand
Existing code, data and dependencies
Decision
Production scope, controls and operating responsibility
Follow the consequences of failure
Review the actual user journeys with the code, data, integrations and operating setup:
- Does the essential workflow work across realistic inputs and permissions?
- Can critical data be protected and recovered?
- Can engineers change the software without breaking unrelated behaviour?
- Does the business control its code, accounts and dependencies?
- Can the team release, monitor and recover the service?
- Do infrastructure, AI usage and manual work support viable customer economics?
A full rewrite requires a stronger case than untidy code. Keep sound parts, repair isolated weaknesses and replace components whose limitations make continued development expensive or risky.
Give AI an acceptance standard
For the important tasks, define useful output, representative evaluation examples, unacceptable errors and when human review is required. Test permissions, failed integrations, latency and cost under realistic use.
The architecture should follow the work. For an AI workspace, I owned research and architecture and led implementation to a production-ready MVP, tested and market-validated with real company data. Business questions needed relationships across that data; the product connected ingestion, a warehouse and a knowledge/dependency graph. Read the case.
Establish a delivery model that can continue
Decide who leads technical decisions, implements changes and accepts quality. Use short steps, clear priorities and working-software reviews against real workflows, including failure cases. Retain the knowledge needed for the next release.
The delivery arrangement may keep existing developers, add expertise or change the team. Choose around capability, cost and the business's ability to keep developing its product.
Make launch a controlled commitment
Before customers depend on it, establish supported workflows, known limitations, evidence of essential behaviour, monitoring responsibility and a recovery route. A narrow release can be a sensible way to learn when its consequences are understood.
Where I can take responsibility
I can lead Product Engineering, Product Validation or AI Engineering as focused work, or join as fractional CTO.
CTO mandates start at
CHF 3'500per month
We agree the scope individually. Focused assignments are quoted separately.
Product Launch. · Execution and responsibility. · Economics. · Partner choice.