The Four-Week Discovery

Most founders who contact the studio have a product idea that is technically credible but architecturally unspecified. They know what the product should do; they do not know how it should be built, what the AI layer should look like, or what the right phasing is between the parts that can be validated cheaply and the parts that cannot.

The Discovery engagement answers those questions. It does not produce code. It produces a validated technical plan.

This is a description of how the engagement works — what happens in each of the four weeks, what the deliverables are, and the reasoning behind the structure.

Why a Discovery and not a prototype

The instinct to prototype early is understandable. A working thing is more compelling than a plan. It is easier to show to investors, easier to test with users, easier to feel good about.

The problem is that a prototype built on an unvalidated architecture is a beautiful demonstration of something that may not be buildable at scale, may require the wrong technical decisions at the foundation, or may solve a problem that turns out not to be the real one.

The cost of rebuilding after a prototype has set expectations is not the cost of the prototype. It is the cost of the prototype plus the cost of the rework, plus the organisational friction of changing a direction that felt settled.

The Discovery is designed to do the work that prevents the expensive rework — not by slowing things down, but by making the first significant investment in code go in the right direction.

The output of the Discovery is specific enough to hand to a technical co-founder or a second studio and have them build against it. If the plan is used to brief the studio for a subsequent delivery engagement, the first sprint starts on week five with the architecture already decided.

Week one: domain mapping

The first week is about the domain, not the technology.

The studio runs two sessions with the founder and relevant domain experts. The goal of these sessions is to produce a domain map: a formal model of the entities, workflows, and relationships that the product will operate on. Not a data model — a domain model. What are the objects in this world? What states do they move through? Who acts on them and why?

The domain map session is deliberately low-tech. Pen and paper, whiteboard, or a basic diagram tool. The session is not a requirements gathering exercise; it is a structured exploration of what the domain expert knows and what they assume.

The distinction matters because expert knowledge is often implicit. A dental-tourism coordinator knows that a patient's treatment plan changes when the consultation produces a different diagnosis than the referral assumed — but they have never had to explain this to a software system, so they have never had to make it explicit. The domain mapping session makes it explicit. Not because the studio will build the treatment-plan-change-on-diagnosis workflow in week two, but because the architecture has to be able to accommodate it eventually.

By end of week one, the domain map is a shared artifact — reviewed by the founder, corrected where the studio's model diverged from the founder's understanding, and approved. The domain map is the source of truth for the rest of the discovery.

Deliverable: validated domain map.

Week two: AI layer design

The second week applies the domain map to the question of AI architecture.

Given the domain — the entities, the workflows, the users, the data — what does the AI layer look like? This is not a question about which AI provider to use; it is a question about what the AI does in the product's operating model.

The frame is the studio's own five-question diagnostic and the four capability levels it sorts into, set out in Agent-Native, Not AI-Powered. For each significant workflow identified in the domain map, the week-two session asks: what level of agentic capability does this workflow require?

Level 1 (completion): the AI generates an output that a human reviews and approves before it takes effect
Level 2 (orchestration): the AI coordinates across multiple steps within a workflow, with human approval at defined gates
Level 3 (autonomous domain operation): the AI acts on behalf of the user within defined constraints without step-level approval
Level 4 (multi-agent coordination): multiple specialised AI agents coordinate on shared goals with audit logging and conflict resolution

The answer is different for different workflows in the same product. A booking confirmation workflow might be Level 3; a treatment-plan change might be Level 2 with explicit human approval at the change point. The AI layer design maps each significant workflow to its appropriate capability level and specifies the authorisation model, tool definitions, and state management requirements for each.

This is the session that most often surfaces the assumptions the founder did not know they were making. "The AI handles the intake" — does that mean Level 2 (AI drafts the intake form response, human approves) or Level 3 (AI sends the response without human review)? The answer has significant implications for the architecture and for the product's liability model.

By end of week two, the AI layer design is a document that describes each significant workflow, its capability level, and the architectural requirements that follow from that choice.

Deliverable: AI layer design document.

Week three: constraint mapping and risk identification

The third week tests the domain map and AI layer design against the constraints — technical, regulatory, operational, and organisational — that the project will operate within.

Technical constraints include: existing systems the product must integrate with, data formats that cannot be changed, infrastructure requirements that are non-negotiable. Regulatory constraints include: data residency requirements, industry-specific compliance obligations, any AI Act provisions that apply to the use case. Operational constraints include: what the team can maintain, what the founder can fund, what the timeline is for the first deliverable. Organisational constraints include: who makes decisions, who can approve scope changes, who is available to the studio during delivery.

The constraint mapping session is structured to surface conflicts between the architecture and the constraints. If the AI layer design requires a real-time data feed from a third-party system and the third-party system's API has a 24-hour latency, that is a conflict. If the architecture assumes a Level 3 autonomous agent in a domain that has regulatory requirements for human oversight, that is a conflict.

Conflicts discovered in week three are cheaper to resolve than conflicts discovered in week six of delivery. The risk register documents each conflict, its severity, the options for resolution, and which option the team recommends. The founder reviews the risk register and makes the resolution decisions before week four.

Deliverable: constraint map and risk register.

Week four: the plan

The fourth week produces the deliverable the engagement was designed to produce: the validated technical plan.

The plan integrates the domain map, the AI layer design, the constraint map, and the risk-register resolutions into a coherent phased delivery plan. It includes:

The architecture decision record. Every significant architectural decision made during the discovery, with the alternatives considered and the reasoning for each choice. The architecture decision record is the human-readable version of the OpenSpec design file — it is written for the founder and any future technical stakeholders, not just for the agents that will execute against it.

The delivery phasing. A sequence of delivery phases, each with a specific outcome, an effort estimate, and a dependency on the prior phase. The phasing is designed to deliver value early — the first phase produces something the founder can show to stakeholders — while building toward the full architecture.

The OpenSpec triplet for Phase 1. A complete proposal, design, and tasks file for the first delivery phase. This is the artifact that, in subsequent delivery engagements with the studio, gets handed directly to the orchestrator as the first dispatch. If the founder takes the plan elsewhere, the Phase 1 triplet serves as the technical brief for the first development sprint.

The confidence ratings. Each section of the plan carries a confidence rating: high (the studio has built this before and the pattern is well understood), medium (the approach is sound but the specific context introduces variables), or low (the approach is directionally correct but the discovery surfaced unresolved questions that will require iteration). Low-confidence sections are not failures of the discovery; they are honest admissions that some questions can only be answered by building.

Deliverable: validated technical plan (architecture decisions + phasing + Phase 1 OpenSpec triplet + confidence ratings).

What the plan is not

The plan is not a fixed specification that the studio guarantees to build exactly. The plan is the best architectural thinking available before code runs. When code runs, new information appears: the third-party API behaves differently than documented, the regulatory requirement turns out to be more specific than assumed, the domain expert in week five knows something the domain expert in week one did not share.

The plan survives first contact with implementation because it is built on validated assumptions — the domain mapping, the AI layer design, the constraint mapping. It does not survive first contact with implementation unchanged, because no plan does.

The confidence ratings in the plan are the mechanism for managing this. High-confidence sections should change very little. Medium-confidence sections should be reviewed at the end of Phase 1 and adjusted if needed. Low-confidence sections are expected to change — they are the areas where the discovery was honest about the limits of pre-build knowledge.

What a domain map catches: an illustration from a build

An example from the studio's own work, with the caveat stated plainly: this was a fixed-scope build, not a Discovery. It is here because it shows what the week-one session is for, not because it is an account of a Discovery we ran.

The VSThermo Moldova catalogue presents a range of thermal-break window profiles for a distributor. Nine products. The obvious model for a product catalogue is nine pages and a list.

What the domain actually contains is a compatibility album of fifty-one window systems, cross-linked with the products in both directions — five and a half times more systems than products. And the direction of the lookup is the reverse of the vendor's instinct: a client arrives knowing the window system they already have installed, and needs to find which profile fits it. Not "here are our nine products," but "you have that system, so you need this profile."

That is one sentence of domain knowledge, and it decides the shape of the catalogue: the load-bearing entity is not the product, it is the product-to-system compatibility. A build that modelled nine products and added compatibility as a field on each would have produced a working site that answered the wrong question.

Expert knowledge is like this by default. A distributor who has spent years answering "will this fit what I've got?" on the phone has never had to explain to a software system that the question runs in that direction — so they have never had to make it explicit. The week-one session exists to make it explicit, before the architecture assumes otherwise.

The Discovery does this work in the four weeks before any code is written. On a fixed-scope build it happens too, but under delivery pressure, and the cost of getting it wrong is measured in rework rather than in a revised diagram.

Is Discovery the right starting point?

The Discovery engagement is the right starting point for most briefs that arrive at the studio. If you have a product problem that requires an AI architecture layer — not a chatbot feature, but an architectural commitment to AI as the operating layer — and you want to understand what building it correctly looks like before you invest in building it, the Discovery is designed for you.

The engagement starts after a brief call to confirm fit. The brief call is free. Discovery runs four weeks at fixed scope. Price is fixed once the scope is — we give a firm figure after the brief call, not before it.

The offer is on the site as the Growth diagnostic — the same engagement, described from the buyer's side.

FAQ

What does the Discovery cost?

The price is fixed once the scope is. We give a firm figure after the brief call that confirms fit, not before it — an estimate offered before we know the shape of the problem is a guess with a decimal point. Where the scope genuinely cannot be defined up front, we say so and work time-and-materials rather than pretend to a fixed price.

What do I receive at the end of the Discovery?

A validated technical plan: domain map, AI layer design, a phased delivery plan with effort estimates, an OpenSpec triplet for the first change, and a confidence-rated risk register. The plan is designed to be actionable — sufficient for a technical co-founder to evaluate, sufficient for another studio to execute against, sufficient for the founder to raise investment with technical specificity.

Does the Discovery guarantee a subsequent engagement?

No. The Discovery is a standalone engagement. The plan it produces is yours to use as you choose — with the studio, with another team, or as the basis for recruiting a technical co-founder. It is designed to be useful in all three cases, which is why it ends with a spec rather than a proposal.

What does the studio need from me to run the Discovery?

Access to the relevant domain experts — typically the founder plus one or two people who know the operational detail of the problem — for four structured sessions over four weeks, each around ninety minutes. Any existing documentation, user research, or technical constraints you have. A willingness to be specific about what the product must do, not just the vision of what it might become.

Why four weeks and not two?

The first two weeks surface assumptions that neither the studio nor the founder knew were assumptions. The second two weeks test those assumptions against the constraints and produce the plan. A two-week discovery produces a plan that is confident but untested. A four-week discovery produces a plan that is confident and tested. The difference is visible in how the plan survives first contact with implementation.