Release 1 – MVP App Development
Release 1 – MVP App Development
Chapter 03
Chapter 03
The idea has
earned its first
real release.
The idea has
earned its first
real release.
The Workshop framed the problem and built the PoC.
Validation found evidence.
The evidence has earned the build.
The Workshop framed the problem and built the PoC.
Validation found evidence.
The evidence has earned the build.
Release 1 turns that learning into production software built for real users.
Release 1 turns that learning into production software built for real users.
Focused enough to launch quickly. Serious enough to build on.
Focused enough to launch quickly. Serious enough to build on.
Built fast.
Not built
to throw away.
Built fast.
Not built
to throw away.
Release 1 is deliberately constrained, but it is still production software. The objective is to move quickly without creating a technical dead end that needs to be replaced the moment the product gains traction.
The First Production Release
The first version
that deserves
real users.
The first version
that deserves
real users.
Release 1 does not attempt to contain the entire future vision. It contains the workflows most directly connected to the problem the evidence has confirmed — focused enough for users to understand and for the founder to clearly learn from how they respond.
The First Production Release
The first version
that deserves
real users.
The first version
that deserves
real users.
Release 1 does not attempt to contain the entire future vision. It contains the workflows most directly connected to the problem the evidence has confirmed — focused enough for users to understand and for the founder to clearly learn from how they respond.
01
Solve the Core Problem
Release 1 focuses on the workflows most directly connected to the problem and value proposition already tested through the earlier stages. Do not build speculative future features simply because they may eventually be useful.
01
Solve the Core Problem
Release 1 focuses on the workflows most directly connected to the problem and value proposition already tested through the earlier stages. Do not build speculative future features simply because they may eventually be useful.
02
Make it Production Ready
Real users introduce responsibilities that prototypes do not have: authentication, data, reliability, deployment, analytics, notifications, integrations and operational support where required.
02
Make it Production Ready
Real users introduce responsibilities that prototypes do not have: authentication, data, reliability, deployment, analytics, notifications, integrations and operational support where required.
03
Create Real Usage
The purpose of Release 1 is not merely to publish an app. It is to create the first environment where we can observe what users actually do.
03
Create Real Usage
The purpose of Release 1 is not merely to publish an app. It is to create the first environment where we can observe what users actually do.
04
Preserve the Next Move
Release 1 should provide a credible foundation for the product to evolve rather than force an unnecessary rebuild if the market responds positively.
04
Preserve the Next Move
Release 1 should provide a credible foundation for the product to evolve rather than force an unnecessary rebuild if the market responds positively.
01
Solve the Core Problem
Release 1 focuses on the workflows most directly connected to the problem and value proposition already tested through the earlier stages. Do not build speculative future features simply because they may eventually be useful.
02
Make it Production Ready
Real users introduce responsibilities that prototypes do not have: authentication, data, reliability, deployment, analytics, notifications, integrations and operational support where required.
03
Create Real Usage
The purpose of Release 1 is not merely to publish an app. It is to create the first environment where we can observe what users actually do.
04
Preserve the Next Move
Release 1 should provide a credible foundation for the product to evolve rather than force an unnecessary rebuild if the market responds positively.
Smaller scope
does not mean
lower standards.
Smaller scope
does not mean
lower standards.
Prioritisation
Prioritisation
Every feature
has to justify
its place.
Every feature
has to justify
its place.
The hardest part of a first production release is rarely finding more things to build. It is deciding what not to build yet.
The hardest part of a first production release is rarely finding more things to build. It is deciding what not to build yet.
Must Exist
Without it, the core user cannot receive the intended value.
Must Exist
Without it, the core user cannot receive the intended value.
Must Work Properly
Production responsibilities such as authentication, data, security, deployment and critical integrations.
Must Work Properly
Production responsibilities such as authentication, data, security, deployment and critical integrations.
Should Wait
Useful functionality that does not materially affect the first learning objective.
Should Wait
Useful functionality that does not materially affect the first learning objective.
Roadmap
Ideas worth retaining but not worth funding before real-world usage exists.
Roadmap
Ideas worth retaining but not worth funding before real-world usage exists.
Must Exist
Without it, the core user cannot receive the intended value.
Must Work Properly
Production responsibilities such as authentication, data, security, deployment and critical integrations.
Should Wait
Useful functionality that does not materially affect the first learning objective.
Roadmap
Ideas worth retaining but not worth funding before real-world usage exists.
Release 1
Release 1
Release 1
is not a smaller version
is not a smaller version
is not a smaller version
of the entire roadmap.
of the entire roadmap.
of the entire roadmap.
It is a deliberately prioritised product: enough to solve the user’s deepest pain points, but focused enough that users can understand it and the founder can clearly learn from how they respond. Prioritisation controls both the investment required to build and the quality of the learning produced after launch.
Release 1
Release 1
Release 1
is not a smaller version
is not a smaller version
is not a smaller version
of the entire roadmap.
of the entire roadmap.
of the entire roadmap.
It is a deliberately prioritised product: enough to solve the user’s deepest pain points, but focused enough that users can understand it and the founder can clearly learn from how they respond. Prioritisation controls both the investment required to build and the quality of the learning produced after launch.
Release 1
is not a smaller version
of the entire roadmap.
It is a deliberately prioritised product: enough to solve the user’s deepest pain points, but focused enough that users can understand it and the founder can clearly learn from how they respond. Prioritisation controls both the investment required to build and the quality of the learning produced after launch.
Release 1
is not a smaller version
of the entire roadmap.
It is a deliberately prioritised product: enough to solve the user’s deepest pain points, but focused enough that users can understand it and the founder can clearly learn from how they respond. Prioritisation controls both the investment required to build and the quality of the learning produced after launch.
The Line Changes Here
The Line Changes Here
A prototype
can pretend.
Production software
has to work.
A prototype
can pretend.
Production software
has to work.
Proof of Concept
Can optimise for:
speed of learning
simulated data
limited interaction paths
visual realism
rapid change
disposable code
no production infrastructure
Built to answer questions.
Release 1
Must consider:
real users
authentication
persistent data
production integrations
security
deployment
app-store requirements where applicable
analytics
reliability
supportability
Built to operate.
Proof of Concept
Can optimise for:
speed of learning
simulated data
limited interaction paths
visual realism
rapid change
disposable code
no production infrastructure
Built to answer questions.
Release 1
Must consider:
real users
authentication
persistent data
production integrations
security
deployment
app-store requirements where applicable
analytics
reliability
supportability
Built to operate.
A Pilot Light Principle
We don’t start
Release 1
from a brief.
We don’t start
Release 1
from a brief.
We start with
everything we’ve learned.
By the time production development begins, the problem, users, workflows, assumptions, product decisions and validation history already form shared context. That continuity reduces the need to repeatedly explain why the product exists and allows Release 1 to stay connected to the evidence that earned it.
A Pilot Light Principle
We don’t start
Release 1
from a brief.
We don’t start
Release 1
from a brief.
We start with
everything we’ve learned.
By the time production development begins, the problem, users, workflows, assumptions, product decisions and validation history already form shared context. That continuity reduces the need to repeatedly explain why the product exists and allows Release 1 to stay connected to the evidence that earned it.
How We Build
How We Build
We choose
the fastest
responsible path
to Release 1.
We choose
the fastest
responsible path
to Release 1.
Some products can reach Release 1 faster using modern rapid-development platforms. Others need deeper custom engineering from the beginning. We choose the approach based on what the product actually requires, how quickly we need to learn and what options need to remain open afterwards.
Where rapid-development tools are appropriate, they reduce cost and time to launch without creating a technical dead end. Where they are not appropriate, we say so before development begins.
Release 1 works to a defined envelope — up to $40K and a 90-day production window, scoped by the Workshop so the envelope holds through prioritisation, not optimism.
The technology
should serve
the product.
Not the other
way around.
The technology
should serve
the product.
Not the other
way around.
Fast doesn’t have
to mean
fragile.
Fast doesn’t have
to mean
fragile.
01
Product Architecture
Choose technology based on what Release 1 genuinely requires and what foreseeable product decisions need to remain available.
01
Product Architecture
Choose technology based on what Release 1 genuinely requires and what foreseeable product decisions need to remain available.
02
Data and Backend
Use appropriate production services and structure rather than simulated prototype data.
02
Data and Backend
Use appropriate production services and structure rather than simulated prototype data.
03
Integrations
Connect external platforms, APIs, payments, notifications or specialist services only where Release 1 genuinely needs them.
03
Integrations
Connect external platforms, APIs, payments, notifications or specialist services only where Release 1 genuinely needs them.
04
Deployment
Prepare the product for its real operating environment, including web deployment or app-store publication where applicable.
04
Deployment
Prepare the product for its real operating environment, including web deployment or app-store publication where applicable.
05
Ownership
Ensure the founder owns the product assets created for them.
05
Ownership
Ensure the founder owns the product assets created for them.
Fast doesn’t have
to mean
fragile.
Fast doesn’t have
to mean
fragile.
01
Product Architecture
Choose technology based on what Release 1 genuinely requires and what foreseeable product decisions need to remain available.
02
Data and Backend
Use appropriate production services and structure rather than simulated prototype data.
03
Integrations
Connect external platforms, APIs, payments, notifications or specialist services only where Release 1 genuinely needs them.
04
Deployment
Prepare the product for its real operating environment, including web deployment or app-store publication where applicable.
05
Ownership
Ensure the founder owns the product assets created for them.
Own the Asset
You aren’t
renting software.
You’re buying
an asset.
You aren’t
renting software.
You’re buying
an asset.
The product should belong to the founder building the company around it.
source code
product designs
relevant project assets
production accounts
deployment accounts
infrastructure created specifically for the product
app-store listings where applicable
domain and product assets where included
Your product
should not become
hostage to your agency.
Your product
should not become
hostage to your agency.
From Definition to Release
Build the product.
Test the product.
Put it in
users’ hands.
Build the product.
Test the product.
Put it in
users’ hands.
01
Confirm Release 1
Turn the validated workflows and product definition into a tightly controlled production scope.
01
Confirm Release 1
Turn the validated workflows and product definition into a tightly controlled production scope.
02
Design and Handoff
Resolve the interfaces and interactions required for the first release and prepare them for implementation.
02
Design and Handoff
Resolve the interfaces and interactions required for the first release and prepare them for implementation.
03
Development and Integration
Build the production application, backend and required third-party integrations.
03
Development and Integration
Build the production application, backend and required third-party integrations.
04
Test and Refine
Carry out functional testing, integration testing and product review before founder UAT.
04
Test and Refine
Carry out functional testing, integration testing and product review before founder UAT.
05
UAT and Deployment
Put the release through real acceptance testing and prepare the required production environments.
05
UAT and Deployment
Put the release through real acceptance testing and prepare the required production environments.
06
Release
Deploy to the intended users and begin collecting real-world product evidence.
06
Release
Deploy to the intended users and begin collecting real-world product evidence.
From Definition to Release
Build the product.
Test the product.
Put it in
users’ hands.
Build the product.
Test the product.
Put it in
users’ hands.
01
Confirm Release 1
Turn the validated workflows and product definition into a tightly controlled production scope.
02
Design and Handoff
Resolve the interfaces and interactions required for the first release and prepare them for implementation.
03
Development and Integration
Build the production application, backend and required third-party integrations.
04
Test and Refine
Carry out functional testing, integration testing and product review before founder UAT.
05
UAT and Deployment
Put the release through real acceptance testing and prepare the required production environments.
06
Release
Deploy to the intended users and begin collecting real-world product evidence.
Momentum
matters.
Momentum
matters.
Release 1 should have a clear commercial and delivery boundary. Without one, first releases have a tendency to become permanent development projects.
Pilot Light typically targets a first production release in approximately 90 days once scope and readiness are established. Product complexity, integrations, approval processes and dependencies may affect this.
A defined delivery window creates pressure to prioritise the product rather than continuously expand it.
Time-box the release.
Not the quality.
Time-box the release.
Not the quality.
Controlled Exposure
Know what you’re committing to before we start.
Release 1 is defined around an agreed scope and commercial boundary rather than an open-ended feature backlog.
The founder should understand what the investment is intended to achieve, what is included and what has deliberately been left for later.
Prioritisation
Prioritisation
“Not yet”
is a product
decision.
“Not yet”
is a product
decision.
Release 1 is not a smaller version of the entire roadmap. It is a deliberately prioritised product: enough to solve the user’s deepest pain points, but focused enough that users can understand it and the founder can clearly learn from how they respond.
Release 1 is not a smaller version of the entire roadmap. It is a deliberately prioritised product: enough to solve the user’s deepest pain points, but focused enough that users can understand it and the founder can clearly learn from how they respond.
Examples that commonly wait
Examples that commonly wait
Secondary User Roles
Complex Administration
Advanced Reporting
Automation
Nice-to-Have Integrations
Edge-Case Workflows
Deep Personalisation
Growth Features
Sophisticated Analytics
Future Monetisation Options
Secondary User Roles
Complex Administration
Advanced Reporting
Automation
Nice-to-Have Integrations
Edge-Case Workflows
Deep Personalisation
Growth Features
Sophisticated Analytics
Future Monetisation Options
These aren’t bad features. They’re simply not automatically Release 1 features. They earn their place when the core product or real user behaviour demonstrates that they’re needed. What is deferred depends on the product — the exact list is unique to each opportunity.
These aren’t bad features. They’re simply not automatically Release 1 features. They earn their place when the core product or real user behaviour demonstrates that they’re needed. What is deferred depends on the product — the exact list is unique to each opportunity.
Deferred
doesn’t mean
dismissed.
Deferred
doesn’t mean
dismissed.
What You Leave With
What You Leave With
A real product.
And real questions
to answer next.
A real product.
And real questions
to answer next.
Production Software
A live first release built for real users rather than demonstration.
Production Software
A live first release built for real users rather than demonstration.
Owned Product Assets
The relevant source, design and production assets created for the product under the engagement.
Owned Product Assets
The relevant source, design and production assets created for the product under the engagement.
Deployed Environment
The production environments, publishing or deployment required to put Release 1 into use.
Deployed Environment
The production environments, publishing or deployment required to put Release 1 into use.
Measurable User Behaviour
A product capable of producing the real-world evidence that prototypes cannot.
Measurable User Behaviour
A product capable of producing the real-world evidence that prototypes cannot.
A Prioritised Roadmap
The functionality deliberately deferred from Release 1, now informed by what real users do next.
A Prioritised Roadmap
The functionality deliberately deferred from Release 1, now informed by what real users do next.
Production Software
A live first release built for real users rather than demonstration.
Owned Product Assets
The relevant source, design and production assets created for the product under the engagement.
Deployed Environment
The production environments, publishing or deployment required to put Release 1 into use.
Measurable User Behaviour
A product capable of producing the real-world evidence that prototypes cannot.
A Prioritised Roadmap
The functionality deliberately deferred from Release 1, now informed by what real users do next.
A Pilot Light Principle
After Release 1,
stop asking
what users say.
After Release 1,
stop asking
what users say.
Start watching
what they do.
Before launch, much of the evidence is necessarily based on interviews, behaviour history, research and controlled product tests. Release 1 creates a different quality of evidence: real people deciding whether to use the real product.
Do they activate?
Do they come back?
Where do they stop?
Which workflows matter?
What do they ignore?
What do they repeatedly request?
What behaviour indicates genuine value?
Real usage gets a vote.
Release 1
Measurement Framework
Release 1
Measurement Framework
Pilot Light does not simply launch the software. We establish what should be measured after launch so the evidence Release 1 produces is usable from day one.
Before Release 1 we agreed what we needed the product to teach us. After launch, we stay close enough to interpret what actually happens.
01
What We Need to Learn
Define the most important questions Release 1 needs to answer.
01
What We Need to Learn
Define the most important questions Release 1 needs to answer.
02
What We Track
Identify the behaviours, workflows and events connected to those questions.
02
What We Track
Identify the behaviours, workflows and events connected to those questions.
03
How We Measure It
Instrument appropriate analytics within the product so meaningful behaviour can actually be observed.
03
How We Measure It
Instrument appropriate analytics within the product so meaningful behaviour can actually be observed.
04
What You Can See
Provide an appropriate dashboard or reporting view of the agreed product metrics.
04
What You Can See
Provide an appropriate dashboard or reporting view of the agreed product metrics.
05
What Happens Next
Use the evidence to inform the next 30, 60 and 90 days of product and roadmap decisions.
05
What Happens Next
Use the evidence to inform the next 30, 60 and 90 days of product and roadmap decisions.
Pilot Light doesn’t
just launch the product.
We define what
the product needs
to teach us next.
Pilot Light doesn’t
just launch the product.
We define what
the product needs
to teach us next.
A Pilot Light Principle
After Release 1,
stop asking
what users say.
After Release 1,
stop asking
what users say.
Start watching
what they do.
Before launch, much of the evidence is necessarily based on interviews, behaviour history, research and controlled product tests. Release 1 creates a different quality of evidence: real people deciding whether to use the real product.
Do they activate?
Do they come back?
Where do they stop?
Which workflows matter?
What do they ignore?
What do they repeatedly request?
What behaviour indicates genuine value?
Real usage gets a vote.
Release 1
Measurement Framework
Release 1
Measurement Framework
Pilot Light does not simply launch the software. We establish what should be measured after launch so the evidence Release 1 produces is usable from day one.
Before Release 1 we agreed what we needed the product to teach us. After launch, we stay close enough to interpret what actually happens.
01
What We Need to Learn
Define the most important questions Release 1 needs to answer.
02
What We Track
Identify the behaviours, workflows and events connected to those questions.
03
How We Measure It
Instrument appropriate analytics within the product so meaningful behaviour can actually be observed.
04
What You Can See
Provide an appropriate dashboard or reporting view of the agreed product metrics.
05
What Happens Next
Use the evidence to inform the next 30, 60 and 90 days of product and roadmap decisions.
Pilot Light doesn’t
just launch the product.
We define what
the product needs
to teach us next.
Pilot Light doesn’t
just launch the product.
We define what
the product needs
to teach us next.
Shipping Release 1
is not the win.
Learning what happens
next is.
Shipping Release 1
is not the win.
Learning what happens
next is.
A successful launch does not mean the original product thesis was correct. It means we finally have the environment required to test it properly.
This is where the Pilot Light investment staircase continues — each stage earning the right to the next.
01
INVEST IN THE WORKSHOP
The Workshop
01
INVEST IN THE WORKSHOP
The Workshop
02
INVEST YOUR LEGWORK
Market Research and Validation
02
INVEST YOUR LEGWORK
Market Research and Validation
03
INVEST IN PRODUCT
Release 1
You are here
03
INVEST IN PRODUCT
Release 1
You are here
04
INVEST IN GROWTH
Beyond Release 1
04
INVEST IN GROWTH
Beyond Release 1
Shipping Release 1
is not the win.
Learning what happens
next is.
Shipping Release 1
is not the win.
Learning what happens
next is.
A successful launch does not mean the original product thesis was correct. It means we finally have the environment required to test it properly.
This is where the Pilot Light investment staircase continues — each stage earning the right to the next.
01
INVEST IN THE WORKSHOP
The Workshop
02
INVEST YOUR LEGWORK
Market Research and Validation
03
INVEST IN PRODUCT
Release 1
You are here
04
INVEST IN GROWTH
Beyond Release 1
Think you’re
ready to build?
Think you’re
ready to build?
Let’s first work out whether the evidence, product definition and scope are strong enough to justify Release 1.
Think you’re
ready to build?
Think you’re
ready to build?
Let’s first work out whether the evidence, product definition and scope are strong enough to justify Release 1.
Next Chapter
Chapter 04
The product
is live.
Now let the
evidence decide
what happens next.
The product
is live.
Now let the
evidence decide
what happens next.
Some products need more engineering. Some need growth. Some need capital. Some need time to learn.
The next investment should follow what Release 1 reveals rather than a predetermined agency roadmap. Real usage changes what the product earns next. The investment staircase continues only where evidence justifies it.
Next Chapter
Chapter 04
The product
is live.
Now let the
evidence decide
what happens next.
The product
is live.
Now let the
evidence decide
what happens next.
Some products need more engineering. Some need growth. Some need capital. Some need time to learn.
The next investment should follow what Release 1 reveals rather than a predetermined agency roadmap. Real usage changes what the product earns next. The investment staircase continues only where evidence justifies it.
What should
an MVP actually
include?
What should
an MVP actually
include?
A useful MVP should include enough functionality to deliver the product’s core value to real users and generate meaningful evidence about their behaviour.
It does not need every feature imagined for the future. The first production release should prioritise the workflows most directly connected to the problem being solved, while still meeting the technical responsibilities of real production software.
Why Pilot Light uses the term Release 1.
MVP is often interpreted as “cheap”, “unfinished” or “temporary”. Pilot Light uses Release 1 because the first production product should be deliberately limited without being treated as disposable.
Common Questions
Release 1
questions.
Release 1
questions.
Is Release 1 the same as an MVP?
How long does Release 1 take?
Why can't I include more features?
Will Release 1 need to be rebuilt later?
Do I own the product?
Can you publish the app to the Apple App Store and Google Play Store?
What happens after Release 1?
Common Questions
Release 1
questions.
Release 1
questions.
Is Release 1 the same as an MVP?
How long does Release 1 take?
Why can't I include more features?
Will Release 1 need to be rebuilt later?
Do I own the product?
Can you publish the app to the Apple App Store and Google Play Store?
What happens after Release 1?
The Primary Offer
Think you need
an app developer?
First, let’s work out
whether you’re
ready for one.
Think you need
an app developer?
First, let’s work out
whether you’re
ready for one.
The Founder Working Session
That’s exactly the kind of question the Founder Working Session is designed to answer.
We’ll work through where you are today, what you’ve already done and what still needs to be proven — then turn that into a practical 30, 60 and 90 day action plan.
I put some skin in the game too.
You leave with a tailored action plan I’ve prepared for your idea, not a recycled playbook.
“If I think you’re too early to spend money with Pilot Light, I’ll tell you.”
If you’ve already done enough to move into the Workshop, Validation or Release 1, I’ll tell you that too.
Founder capacity is deliberately limited. Applications are reviewed personally.
The Primary Offer
Think you need
an app developer?
First, let’s work out
whether you’re
ready for one.
Think you need
an app developer?
First, let’s work out
whether you’re
ready for one.
The Founder Working Session
That’s exactly the kind of question the Founder Working Session is designed to answer.
We’ll work through where you are today, what you’ve already done and what still needs to be proven — then turn that into a practical 30, 60 and 90 day action plan.
I put some skin in the game too.
You leave with a tailored action plan I’ve prepared for your idea, not a recycled playbook.
“If I think you’re too early to spend money with Pilot Light, I’ll tell you.”
If you’ve already done enough to move into the Workshop, Validation or Release 1, I’ll tell you that too.
Founder capacity is deliberately limited. Applications are reviewed personally.
The Decision Gate
What Release 1 has to earn: real users and real signals worth reading.
Progress
The evidence has earned the next stage.
Progress
The evidence has earned the next stage.
Refine
The direction is close but the assumptions need adjusting.
Refine
The direction is close but the assumptions need adjusting.
Learn More
The decision needs evidence we don’t yet have.
Learn More
The decision needs evidence we don’t yet have.
Stop
And that can be the most valuable outcome of all.
Stop
And that can be the most valuable outcome of all.
The outcome determines what happens next — not momentum.
The Decision Gate
What Release 1 has to earn: real users and real signals worth reading.
Progress
The evidence has earned the next stage.
Refine
The direction is close but the assumptions need adjusting.
Learn More
The decision needs evidence we don’t yet have.
Stop
And that can be the most valuable outcome of all.
The outcome determines what happens next — not momentum.
Previous
Market Research & Validation
Previous
Market Research & Validation
Next
Beyond Release 1
Next
Beyond Release 1