We understand your needs before preparing a scoped quote. Future proposals are in USD; scope, deliverables, timing and terms are agreed separately. An enquiry is non-binding, not a purchase or booking.
For founders · AI-built MVPs
Your AI-built MVP works in the demo. Now it has to survive real users.
Building fast with AI tools is the right way to start. The wall usually comes later — a buyer's security questionnaire, data that doesn't fit the model, costs that climb with usage. We read what you have and tell you what to keep, what to fix, and in what order. No rewrite for its own sake.
The usual walls
Six places AI-built prototypes break first.
Access control
Rules enforced in the screen, not the database, so one user can read another's data.
Data model
Tables shaped around the first screens, which fight every new feature.
Buyer questionnaire
No answers for audit logs, backups, retention or incident response.
Cost and speed
AI calls and queries that grow with every user and nobody measures.
Silent failures
Errors swallowed, so problems surface as customer complaints.
No way to change safely
No tests or environments, so each fix risks breaking something else.
These are patterns we look for in a teardown, not findings about your product.
Who we serve here · Proposed hypothesis
Who is involved, and what each person receives at the end.
A founder with a prototype built fast (often with AI tools) that now fails on data, security, scale or its first enterprise buyer's questionnaire.
Process owner
Named workflow decision owner
Needs: Define scope, permitted work and acceptance.
Doubt: Responsibility becoming unclear between people.
Proposed deliverables · agreed in scope
- • Proposed acceptance, approval and handover responsibilities as agreed
User
Founder
Needs: Know what to keep, what to rebuild and in what order.
Doubt: Being told to rewrite everything.
Proposed deliverables · agreed in scope
- • A written architecture teardown
- • A prioritised fix list
Approver
First enterprise buyer
Needs: Security and data answers that hold.
Doubt: The product is a demo.
Proposed deliverables · agreed in scope
- • A security and data-model summary the founder can share
Responsibilities, not a promised roster: economic buyer, process owner, user, technical approver and operator may overlap. Explore the Finance illustrative example →·MSP illustrative example →.
Our promise
An agreed review identifies observed risks, open questions and a prioritised next-step plan; production readiness needs scoped tests and acceptance.
Holds when
- • We can read the code and the environment
Limits — what we don't promise
- • The teardown is advice, not a warranty
- • We do not promise fundraising or sales outcomes
Before
A working demo that breaks under real users, data or a security review.
After
A scoped path toward a first release, subject to agreed tests and buyer review.
What it takes from you
Repo and environment access; founder time for decisions.
Constraints we respect
Keep what works; no rewrite for its own sake.
The experience
From first conversation to handover.
01
Architecture review
Review duration and any written findings require agreed scope and availability.
Scoped quote
02
Fix plan
Scoped path to an accepted first release.
03
Build
Agreed-scope phases.
Scoped quote
Evidence, labelled honestly
- Owned platforms in development; see their evidence limitsContext
- Teardown outcomes for foundersUnknown
Context = portfolio direction, not operational acceptance · Proposed = our method, not yet proven for this audience · Unknown = we won't claim it yet.
Access we ask for — and how you take it back
- • Read-only repo access
- • Read-only view of the environment config
No production changes during the teardown.
Initial inquiry: non-sensitive summary only. Later assessment: authorised redacted samples or read-only access. Sandbox and production write access require separate approval, minimisation, access expiry and retention agreement.
Agree repository access, revocation and permitted notes or retention before any review.
Something useful to pass along
A teardown summary the founder can give investors or a buyer.
Useful to: Investors and enterprise buyers doing diligence.. Shared only if you choose to.
Why you'd come back: Follow-up reviews before each major release.
What we watch for harm: Rework caused by our recommendations.
Not a fit: Pure idea-stage with nothing built yet (see Venture partnership)
Next step
Send us the repo link and the wall you hit.
We read it before the session, and you leave with a written, ordered fix list.