Build the first version around one useful journey.

Choose the question the first release must answer

A first release might test whether a customer can complete a transaction, whether a group will return to a product or whether an operational model works outside a demo.

Those questions need different scopes. We help you decide which user journey must work and what can be handled manually while you learn. If a prototype or existing tool can answer the question, that is worth considering before commissioning a product.

Make the rules explicit

The difficult work often sits behind a simple screen: who can participate, what happens at a deadline, which data is authoritative and how an administrator corrects a problem.

We map these rules with the interface. The first scope should identify required integrations, access boundaries, failure states and the information you need to operate the product.

A feature list alone does not settle those decisions. We write acceptance checks around what a user or administrator must be able to do.

Include the work around the product

The release may need account management, transactional email, content administration or a reporting view. We include what the intended operation requires and identify what remains manual.

For third-party services, we check access, provider limitations and the cost of depending on them. A mock integration in a prototype does not prove the production service is available.

The 21Goals case study shows how custom football-prediction rules, live data and administration fit into a delivered product.

Agree the launch and the handover

Before launch, the critical user journeys need testing with representative data. The plan should cover deployment, access to production accounts, a recovery route and the support period included in the engagement.

Ownership of code, configuration, data and provider accounts should be explicit. We also agree how future changes will be requested and scoped.

Budget for the next decision

The first release is a commitment to a defined scope, not a guarantee of demand or a promise that future changes will be free. Infrastructure, subscriptions, support and further development belong in the budget.

Bring the users you want to serve, the most important journey, any existing work and your budget or deadline constraints. That is enough to start deciding what belongs in the first release.