background

Build the first release people can actually use

A first product should do one important job before it tries to do ten. We help you define the user, the workflow and the release boundary, then build and test against agreed acceptance criteria.

What we deliver

Deciding what goes in the first release

Must-have now

The workflow a first user needs to get value, and nothing that can wait. Every feature on this list has a reason tied to that user.

Later, on purpose

Features that are useful but not needed for launch go on a written list for the next release, so they are parked rather than forgotten.

Accounts, roles and data where needed

Sign-up, permissions, storage and integrations are included when the core workflow needs them, not by default.

Acceptance criteria

Each feature has agreed checks that decide when it is finished, written before development starts.

After launch

First users and feedback

Who the first users are

We agree who gets the first release, such as a pilot customer or a waitlist, so the scope fits the people who will use it.

How feedback comes back

In-app feedback, analytics events or scheduled calls, decided up front, so the second release is based on evidence.

Handover

What you get at the end

The working product

Deployed and tested against the acceptance criteria.

Access and documentation

Admin access, environment notes and a walkthrough, so another developer can pick it up.

Scope

What expands an MVP

These are the usual reasons a first release grows. Each one is a decision you can make on purpose.

More than one user type at launch

Each role adds screens, permissions and tests.

Payments and billing

Subscriptions, invoicing and refunds add integration and testing work.

Integrations

Every outside system connected at launch adds build and test time.

Native mobile apps

A responsive web app is usually enough for a first release; separate app-store apps are a larger project.

How we work

From first call to handover

01 Scope call

We define the user, the core workflow and the release boundary.

02 Written proposal

Features, exclusions, acceptance criteria, price and milestones.

03 Build in sprints

Two-week sprints with a working build to review at each milestone.

04 Launch to first users

Deployment, handover and the feedback plan agreed in scope.

The stack

What we build it with

React

Next.js

Node.js

PostgreSQL

Firebase

AWS

  • React – JavaScript UI library
  • Next.js – React framework for production
  • Nuxt.js – Vue.js framework
  • .NET – Microsoft application framework
  • Bitbucket – Git code hosting
  • Microsoft Azure – cloud computing platform
  • Docker – container platform
  • AWS – Amazon Web Services cloud
  • Three.js – 3D JavaScript library
  • TypeScript – typed JavaScript
  • Python – programming language
  • Java – enterprise programming language
  • PHP – server-side scripting language
  • OpenAI – AI models and API
  • Node.js – JavaScript runtime
  • Angular – TypeScript web framework
  • Flutter – cross-platform UI toolkit
  • Laravel – PHP web framework

Define your first release

Bring the idea and who it is for. We will help you decide what goes in version one and what waits.

Discuss your MVP