What to build first when the runway is short

With a long runway, the order in which you build things is a matter of taste. With a short one, it decides whether the company exists next year. The question "what should we build first?" is really three questions: which uncertainty is most expensive to leave open, what is the smallest build that resolves it, and how do you sequence the builds so each one pays for the next decision. This guide gives a method for answering all three, and for turning the answer into a scope that can be built quickly at a known cost.

The first build is an experiment with a product attached

Founders often treat the first build as the product's foundation. It is better treated as the most expensive experiment the company will run, with a product as its by-product. That framing changes what you build. The foundation framing says "build what the product will need". The experiment framing says "build what answers the question that could kill us". When runway is short, the second framing wins, because being wrong about the market is fatal and being behind on features is not.

The first step is therefore to write down the questions, not the features.

Step one: list the questions that could end the company

Most early-stage companies have three to five uncertainties that matter more than all others. Typical examples:

• Will the target user actually change their behaviour to use this?
• Will the person who benefits also be the person who pays?
• Can the core workflow be done well enough to replace what users do today?
• Is the data or integration we depend on actually obtainable?
• Will the economics work at the price users accept?

Write each as a question with a yes-or-no answer. Then, for each one, write what you would do differently if the answer were no. If the honest answer is "nothing", it is not a question that matters yet; drop it. The questions that survive are the ones the first build must address.

Step two: rank by the cost of being wrong

Rank the surviving questions by how much it would cost to discover the answer late. A question whose "no" means a pivot ranks above one whose "no" means a feature change. A question that investors will ask at the next round ranks above one they will not. Usually one question stands clearly at the top. That question defines the first build.

Be honest about which question is really at the top. Founders are tempted to put the most interesting technical question first because it is the one they want to work on. The method is there to stop that.

Step three: find the smallest build that answers it

For the top question, list the ways it could be answered, from cheapest to most expensive:

1. Conversations and commitments: can the question be answered by asking users for a signed letter of intent or a prepayment? If so, do that before building anything.
2. A manual service: can you deliver the outcome by hand to a few users, with a form in front and people behind it? This answers behaviour questions without code.
3. A narrow real product: the smallest software that produces the outcome for real users, built properly in its core.
4. The full first version: everything you believe the product needs.

Stop at the cheapest level that produces a credible answer. Many questions resolve at level one or two. The ones that do not, typically "can the workflow be done well enough to replace the current way", require level three: a narrow, real product.

Level three is where most of the cost and risk sits, and where the method for building an MVP in days applies: one outcome, a short capability list, a durable core and a disposable edge.

Step four: cut the capability list by asking "does the question still get answered?"

Take the narrow product and list its capabilities. For each one, ask: if this were missing, would the top question still get answered? If yes, cut it or make it manual. Typical cuts at this stage:

• Self-service onboarding becomes a manual account set-up by a founder.
• Billing becomes an invoice sent by hand.
• Notifications become a daily e-mail you send yourself, or nothing.
• Admin tooling becomes direct database access for the team.
• Settings and preferences become sensible defaults.
• Integrations become CSV import and export.

What remains is the main workflow, the data model that supports it, authentication, and data integrity. That list can be scoped precisely, which means it can be built quickly and priced fixed.

Step five: write it as a scope with acceptance criteria

Turn the remaining list into a scope document: the outcome, the capabilities, what is excluded (including every item you just cut, so nobody builds it by accident), acceptance criteria and real constraints. This document is what a vendor needs to quote a fixed price and what your own team needs to avoid scope drift. It should fit on a few pages. The general format is in how to write a scope for a fixed-price quote.

A scope at this size is also the right shape for a trial build. In our model, a real, bounded piece of the plan is confirmed in writing and delivered within 72 hours as tested, documented code for a fixed 9,900 euros, deducted in full from the main project. For a startup, the first build's main workflow is often exactly that piece.

Step six: sequence so each build pays for the next decision

After the first build answers the top question, the ranking changes. Some questions disappear, new ones appear, and the next build is chosen the same way. The sequence that results is rarely the one in the original roadmap, and it is nearly always cheaper.

Two rules keep the sequence disciplined:

• Never start a build whose question is already answered. If users have shown they will pay, do not build another experiment on willingness to pay; build what paying users need.
• Never start a build whose question cannot be answered by it. If the question is "will enterprises buy", a self-serve feature does not answer it, however useful it is.

Sequencing in short fixed-price scopes rather than one long project keeps the cash exposure per decision small and the learning per euro high. Each scope has a known price and a delivery measured in days, so a wrong bet costs one scope, not a quarter.

Spending runway on building versus learning

A useful discipline for a short runway is to track two numbers: how much has been spent on building and how much has been learned that changed a decision. If the first grows and the second does not, the build is too large or aimed at the wrong question. Fixed-price scopes make the first number known in advance; the method above keeps the second number up.

This is also the strongest argument against hiring an engineering team before the first build. Payroll converts runway into capacity at a fixed monthly rate whether or not anything is learned. A fixed-price build converts runway into a specific answer. Once the answers are in, hiring becomes a decision made with evidence, and the comparison between hiring and ordering applies in full.

A worked outline

Suppose a founder plans a scheduling product for small clinics. The questions that survive step one: will clinic managers switch from spreadsheets; will nurses actually check the app; will the clinic pay per seat. Step two ranks "will managers switch" first, because its "no" means a pivot. Step three finds that conversations give a soft yes but not a credible one; a manual service would not test the switching behaviour; a narrow real product is needed. Step four cuts everything except: a manager creates a weekly schedule, assigns shifts, publishes it, and nurses see their shifts on a phone. Billing is an invoice; onboarding is done by the founder; notifications are a daily e-mail the founder sends. Step five writes it as a two-page scope with acceptance criteria, including tests for schedule conflicts and the publish step. Step six plans the next build only after three clinics have used it for a month.

That first build is small, real and durable in its core. It answers the question that matters, and if the answer is yes, it is the product's first version rather than its prototype.

What this looks like with Ship in Hours

Startups bring us a scope at this size, or a rough version of it, through the request form and receive a written scope description for a trial build. The architecture and specification are designed in-house by AIPOS OÜ and agreed with you in writing; a multi-agent system then builds, tests, reviews and documents against them in continuous cycles. The code and the intellectual property are yours, delivered to you as a package. The startups page covers the fit, the prices and the founding-client offer.

Frequently asked questions