4. Can we build it

§The hypotheses: the first version can be built by the people we have, with the resources we have, in the appetite we set, on a technical path we could change later without starting over.

§Feasibility used to be the risk that killed startups quietly: the idea was good and the thing could not be built in time. AI moved the risk. Almost anything can now be demonstrated. What cannot always be built is the thing behind the demonstration, at a cost the business can carry, by the people in the room.

§ 4.1Three questions#

§Can it be built at all? For most software first versions in 2026 the answer is yes, and the question is worth thirty seconds. It is worth much longer when the product depends on a capability that does not yet exist reliably, on data nobody has, or on an integration a partner has not agreed to. The sprint's resource test asked this; business design asks it again with the actual first-version definition in hand.

§Can it be built by us, with this? The people, their skills, the money, the time. A first version that needs an engineer the team does not have is a hiring plan before it is a product. A first version that needs a development partner is a dependency, and chapter 6 is about dependencies. The honest answer here often reshapes the first version more than any customer finding does.

§What does building it commit us to? The path chosen now constrains what can be changed later. A loyalty unit built on tokens is a different data model from one built on visits, and the fourth whitepaper's decision to build on visits was a one-way door that the technical path had to respect. Michael Nygard's decision records exist for exactly this: the choices whose consequences outlive the sprint.

§ 4.2The AI cost question#

§One feasibility question is new. Casado and Bornstein observed in 2020 that AI products carry a cost structure closer to services than to software: inference, data handling and the humans still in the loop mean gross margins well below the software norm, and they do not vanish with scale the way hosting costs did. Six years later the observation has been refined, not refuted. A first version that calls a frontier model on every interaction has a marginal cost per user that a spreadsheet must know, and "can we build it" includes "can we afford to run it," which chapter 8 takes up as unit economics.

§ 4.3The technical path recommendation#

§Whoever will build the first version writes one page. The options considered, usually two or three: build from scratch, assemble from services, extend something existing. For each: what it costs to reach the first version, what it costs to run per user, what it commits the company to, what it forecloses. Then a recommendation, with the trade-offs it accepts.

§It ends "subject to the team's judgment." The reason is the first whitepaper's: the person accountable for what gets built is the product owner, and the person who builds it advises. A development partner, an agency, a technical co-founder writing the path all recommend; the team decides, and the decision document records why. In the case the group's development partner wrote the recommendation, compared paths, and closed with the sentence.

§ 4.4What has to be true#

§Added to the running list: the first version can be built by the named people in the stated appetite. The cost to run it per active user, estimated, with the model and infrastructure assumptions behind the estimate. The one-way doors the technical path respects, listed. The dependencies on people or partners not yet committed, each with a name and a date.