03 / 03  Service for startups and SaaS teams

Your SaaS MVP, designed, built and ready for its first customers.

A first version that real customers can sign up for, use and pay for, with the brand, onboarding and analytics that cheap builds leave out.

Book a discovery call What is included

01 Scoping

Start by deciding what to leave out.

An MVP is not a smaller version of everything. It is the smallest product that lets a real customer get one job done and tells you whether they would pay for it.

Before any code, we write down the one job, the smallest loop that delivers it, and a cut list of everything that waits. You also get a short list of the biggest risks so they are tackled first, not discovered late.

02 Tech stack

Tools chosen to be maintained, not to impress.

01

Boring and well supported

Mature tools your next hire can read. Managed services for authentication, database and payments where they save time instead of custom-building them.

02

Chosen for your team

The stack is agreed in scoping around what your team can run and extend, not what I would enjoy using.

03

Documented

Decisions and set-up are written down, so a new developer can pick it up without me.

03 Phases

Four phases, with an estimate agreed in scoping.

  1. 01

    Scope

    The job, the loop, the cut list and the risks, written down and agreed.

  2. 02

    Build the core loop

    The smallest end-to-end version, shown to you early and often.

  3. 03

    Brand and onboarding

    The identity applied to product and launch page, with a first-run experience that gets people to value.

  4. 04

    Launch and measure

    Analytics events in place, deployment, handover and a plan for the first customers.

Timelines depend on scope. You get an estimate at the end of scoping, with the assumptions behind it, not a number promised up front.

04 What is included, and what is not

Clear edges, so there are no surprises.

Included

  • Scoping workshop, cut list and risk list
  • Design and build of the core user journey, front and back end
  • Accounts and sign-in
  • Brand basics applied to product and launch page
  • A first-run onboarding flow
  • Analytics events for the actions that matter
  • Deployment and written handover

Not included by default

  • Native mobile apps
  • Large third-party integrations, unless scoped
  • Enterprise features such as SSO and audit logs
  • Regulated-data compliance work
  • Paid acquisition and ongoing marketing
  • Ongoing support, unless agreed separately

05 What is different

Not an “MVP in 14 days” shop.

Very fast, very cheap MVP builds are fine for a demo. They tend to leave out the parts that decide whether the first customers actually stay: a clear brand, an onboarding path and a way to see what they do.

Typical template-led buildsThis approach
BrandOften a logo and a templateIdentity and messaging applied across product and launch page
OnboardingLeft to the founderDesigned as part of the product
AnalyticsAdded later, if at allBuilt in, with events agreed up front
ScopeEverything fits, until it does notCut list agreed before building
After handoverDependent on the builderDocumented, set up in your name

06 FAQs

Questions founders ask.

Who owns the code and the accounts?

My default approach is that the repository, hosting and third-party accounts are set up in your name from the start, with the exact terms written into the agreement. You should never need me to be able to ship.

What if the scope grows?

It will, and that is normal. Anything new goes through the same question: what does it do for the first customers? Additions are scoped and agreed before they are built, so nothing is added silently.

What happens after launch?

You get the working product, documentation and a handover. Many teams then keep a smaller ongoing arrangement for fixes and the next iteration; that is optional and agreed separately.

Do you build mobile apps?

The default is a responsive web product, which is usually the fastest route to real users. A native mobile app can be scoped as a separate piece if the product genuinely needs one.

07 Concept studies

Concept studies: the product and its first-run experience.

Self-initiated studies for a fictional SaaS product, built in code to show how I think about a first dashboard and onboarding. They are not client work and imply no results.

Ombrea: product dashboardConcept Study — self-initiated, not client work
The brief
A first dashboard that tries to show everything and so shows nothing.
Approach
Lead with the one question a user comes back to answer, support it with one trend and recent activity, and keep navigation to five items.
What is shown
Sidebar, three summary cards, a trend chart and an activity list. No figures are shown; all content is illustrative and invented.
Ombrea: onboarding screensConcept Study — self-initiated, not client work
The brief
New users who leave before they reach the first useful result.
Approach
Ask one question per screen, connect only what is needed now and end on a visible first win.
What is shown
Three screens: goal, connect and first win, with progress cues. Nothing here is real product data.

R Related services

01 / 03Startup brand and websitePositioning, identity and a website, shipped as one launch.02 / 03SaaS website designAudit and redesign a SaaS site so it explains the product and books demos.

Looking for the wider picture? See all services or self-initiated concept work (not client projects).

→ Discovery call

Tell me about your project.

Every project is scoped to your stage and budget. Tell me what you are building and where you are today, and I will reply with next steps.

  • Your stage and what is live today
  • The outcome you need, and by when
  • Who else decides, and who will maintain it