By Mehdi HassanWhat does this MVP case study cover?
This MVP case study is a hypothetical walkthrough, written to show how a six-week build runs week by week. The startup, founder and product are illustrative, not a real client, and nothing here reports real outcomes. What it does show is the process: the scope decisions, the deliverables at each stage and the trade-offs a small team makes to get version one live.
We wrote it this way because most published MVP examples skip the part founders need most: what got cut and why. For the broader framework behind each step, read our MVP design and development guide, and for where design polish goes in a build like this, see MVP design.
What was the napkin version of the product?
The hypothetical founder, a former operations manager at a property management firm, wanted to fix one problem: maintenance requests from tenants arrive by text, email and phone, and small landlords lose track of them. Her napkin sketch had a tenant app, a landlord dashboard, a contractor marketplace, invoicing and a mobile app for all three.
She had spoken to about a dozen landlords and had a short list willing to try it. That made her past the prototype stage: demand looked real, and the question was whether landlords would use the tool every week. If you're earlier than that, a clickable prototype tested with users usually comes first.
Napkin feature | Decision | Reason |
|---|---|---|
Tenant request form | Kept, as a public link | The core input; tenants shouldn't need accounts |
Landlord request board | Kept | The core flow: see, assign, close |
Contractor marketplace | Cut to version two | A second business, not a feature |
Invoicing | Cut | Landlords already use accounting tools |
Native mobile apps | Cut | A responsive web app tests the habit |
Contractor accounts | Replaced with email notifications | Removes a whole user role |
Week 1: how was the MVP scoped?
Week one produced a scope document and the product copy, not designs. The team agreed on the one role (the landlord), the one core flow (a request comes in, gets assigned, gets closed) and the one metric that would say it's working: landlords closing requests through the tool in their second and third weeks.
- Riskiest assumption written down: small landlords will change their habit if logging a request is faster than a text thread.
- Copy drafted first: the tenant form, the empty request board, notification emails and button labels.
- Integration spike: a day testing the email-to-request parsing, the only technically uncertain piece.
- Version-two list started: every cut feature recorded, so nothing felt lost.
Our guide to how to scope an MVP walks through the same cutting method for your own product.
Weeks 2–3: what got designed, and what didn't?
Weeks two and three covered the core flow in Figma with every state, while the technical foundation went up in parallel. Only the screens on the path from new request to closed request got custom design attention; everything else used a component kit.
Tenant request form
Mobile-first, three fields and a photo upload, with a confirmation screen that tells the tenant what happens next.
Empty request board
The first screen a landlord sees. It explains the tenant link and offers a copy button, so the board fills itself.
Request detail and assignment
Assign to a contractor by email, add notes, change status. Loading and error states included.
Notifications
Email templates for tenants and contractors, designed alongside the screens so the words matched.
Usability test
The clickable flow was tested with several landlords from the founder's list, and two confusing labels were rewritten.
Meanwhile the developer set up a Next.js app with hosted auth, a Postgres database, deploy previews and error monitoring. The stack choice is covered in our guide to the best tech stack for a SaaS MVP. The request board borrowed patterns from well-known products; our dashboard design examples show the kind of references used.
Weeks 4–5: how was the core flow built?
Weeks four and five built the core flow end to end with real data before anything else. By the end of week four, a tenant could submit a request that appeared on a landlord's board; by the end of week five, it could be assigned, updated and closed, with emails sent at each step.
Design moved one step ahead: the account page, simple billing through a hosted checkout and the marketing page were designed during week four so they were ready for week six. Two issues came up. Photo uploads from older phones were slow, so images were compressed on upload. And the email parsing from week one's spike missed some formats, so the team added a fallback that turned unparsed emails into a request with the raw text attached, rather than losing them.
Deep dive: the three trade-offs in the build weeks
Trade-off one: real-time updates on the request board. Live updates would have been nice, but a refresh on page focus did the job for a single landlord. Deferred.
Trade-off two: the contractor experience. Contractors got an email with a link to update status, no account. It was rougher than an app but removed a role, sign-up flow and permissions model.
Trade-off three: the onboarding. Instead of a product tour, the empty request board did the onboarding, with one action: share your tenant link. That decision follows the approach in our SaaS onboarding examples.
Week 6: what happened in launch prep?
Week six finished secondary screens, ran the launch checklist and onboarded the first landlords by hand. The founder sat with each one, either in person or on a call, while they shared their tenant link and logged their first request.
- Auth, password reset and email deliverability tested on fresh accounts.
- Analytics events added for each step of the core flow, with one funnel report.
- Privacy policy and terms published, written with advice suited to the founder's region.
- Every placeholder string removed; empty and error states read aloud and rewritten where vague.
- A short feedback email sent to every new landlord on their second day.
What does a six-week MVP case study teach founders?
The main lesson of this MVP case study is that the six weeks came from cuts made in week one, not from working faster. Every cut removed a role, a platform or an integration, and none of them removed the reason a landlord would use the product.
Decision | Time it saved | What it cost |
|---|---|---|
One role instead of three | Permissions, two sign-up flows | Contractors use email links |
Web instead of native | App store builds and review | No push notifications yet |
Hosted auth and checkout | Building and securing both | Less control over styling |
Component kit for secondary screens | Design and build time | A plainer settings area |
Copy written in week one | Rework when text arrived late | A slower start to screens |
After launch, the team would move to a weekly rhythm of shipping, measuring and interviewing, and the cut features would be re-ranked by real usage. If the founder had chosen a no-code tool instead, no-code vs custom code covers that trade-off. For the budget side of a build like this, see the MVP development cost guide.
