For founders
Build toward your first enterprise buyer with a scoped delivery plan
Pre-seed to Series B. You do not need a roadmap deck — you need the three or four structural decisions that decide whether year two is compounding or rewriting. Discuss an architecture review.
- Architecture review
- Agreed scope
- Timeline agreed before work
- Scoped
- See stage-labelled notes
- Products
- Analysis to architecture
- 25 yrs
Architecture review
Timeline agreed before work
See stage-labelled notes
Analysis to architecture
What actually breaks
Four risks to assess in an early platform.
Assess these risks early; effort depends on the existing system.
The data model was drawn around screens
A mismatch between the domain model and workflow can add delivery cost as requirements change. Assess it alongside other dependencies.
Permissions live in the UI
One path forgot the check. You find out during your first enterprise security review, or worse, from a customer.
The AI feature has no acceptance test
Nobody can say whether last week's prompt change made it better. Without a fixed evaluation set, you are shipping on vibes.
Compliance arrives as a rewrite
Retrofitting evidence and access boundaries can add rework; impact depends on the system.
The path
A scoped path from decision to an accepted first release.
Target architecture
Domain model, access boundaries, integration map, and the autonomy rung for every AI-touched workflow. Written down, argued about, and signed off before code.
Build and validate
The platform itself: schema with row-level security, the workflows that carry the business, the AI surfaces that earn their place, and the operational plumbing to run it.
Harden and hand over
Evaluation set, monitoring, rollback path, evidence trail and documentation. Handover or continued operation requires agreed responsibilities and staffing.
Timing depends on scope, access, integrations, review and customer availability. Acceptance checks and the schedule are agreed before a phase starts.
Architecture review scope
Discuss your system and agree the review scope.
Review duration, preparation, deliverables and availability require agreement. A non-binding scope enquiry, not a booking.
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
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.