# How to Build a SaaS MVP After You Raise | Gr8r Studio > How to build a SaaS MVP after you raise: pick one job, scope v1, design the core flow, build in demo sized steps and get it into real customers' hands. Source: https://gr8rstudio.com/blog/saas-mvp-product-design-guide [MVP](https://gr8rstudio.com/blog) # How to Build a SaaS MVP After You Raise Tanjim Islam Founder & CEO 路 26 Oct 26 路 12 min read Summarise with AI [Summarise with AI: ChatGPT](https://chatgpt.com/?q=Summarise%20the%20key%20points%20of%20this%20article%20from%20Gr8r%20Studio%2C%20then%20tell%20me%20how%20they%20apply%20to%20my%20product%20or%20workflow%3A%20https%3A%2F%2Fgr8rstudio.com%2Fblog%2Fsaas-mvp-product-design-guide)[Summarise with AI: Claude](https://claude.ai/new?q=Summarise%20the%20key%20points%20of%20this%20article%20from%20Gr8r%20Studio%2C%20then%20tell%20me%20how%20they%20apply%20to%20my%20product%20or%20workflow%3A%20https%3A%2F%2Fgr8rstudio.com%2Fblog%2Fsaas-mvp-product-design-guide)[Summarise with AI: Perplexity](https://www.perplexity.ai/search?q=Summarise%20the%20key%20points%20of%20this%20article%20from%20Gr8r%20Studio%2C%20then%20tell%20me%20how%20they%20apply%20to%20my%20product%20or%20workflow%3A%20https%3A%2F%2Fgr8rstudio.com%2Fblog%2Fsaas-mvp-product-design-guide) On this page 1. [ 01What does "MVP" mean for a funded SaaS team?](#what-does-mvp-mean-for-a-funded-saas-team) 2. [ 02How do you decide what goes into v1?](#how-do-you-decide-what-goes-into-v1) 3. [ 03How do you plan v1 across the first 90 days?](#how-do-you-plan-v1-across-the-first-90-days) 4. [ 04Why should you design v1 before you build it?](#why-should-you-design-v1-before-you-build-it) 5. [ 05What does the build process look like week by week?](#what-does-the-build-process-look-like-week-by-week) 6. [ 06Who should build your v1?](#who-should-build-your-v1) 7. [ 07What if you already have a prototype built with AI tools?](#what-if-you-already-have-a-prototype-built-with-ai-tools) 8. [ 08What does v1 need for security and data from day one?](#what-does-v1-need-for-security-and-data-from-day-one) 9. [ 09How do you know v1 is ready to ship?](#how-do-you-know-v1-is-ready-to-ship) 10. [ 10How do you get v1 into real customers' hands?](#how-do-you-get-v1-into-real-customers-hands) 11. [ 11What should happen in the weeks after launch?](#what-should-happen-in-the-weeks-after-launch) 12. [ 12What does a well built v1 look like?](#what-does-a-well-built-v1-look-like) 13. [ 13What are the most common v1 mistakes?](#what-are-the-most-common-v1-mistakes) 14. [ 14How do you start this week?](#how-do-you-start-this-week) 15. [ 15Frequently asked questions](#frequently-asked-questions) 16. [ 16Next step](#next-step) 17. [ 17Related reading](#related-reading) This article supports [Product Engineering](https://gr8rstudio.com/services/product-engineering)[Scope your MVP](https://cal.com/tanjim-38/30min) ## TL;DR - Pick one painful job for one kind of customer. - Cut v1 down to the single flow that proves value. - Design it before you code it, then build in small steps you can demo every week. - Ship to a handful of real customers early and let their use decide v2. To build a SaaS MVP, pick one painful job for one kind of customer and cut v1 down to the single flow that proves you can do it. Design that flow before you code it. Build in small steps you can demo every week. Then put it in front of real customers early and let what they do decide v2. The money is in the bank. The deck promised a product. This guide is the path from that moment to the day a customer logs in and does the thing you said they could. ## What does "MVP" mean for a funded SaaS team? An MVP for a funded team is the smallest version of the product that a real customer will use for real work, and ideally pay for. It is smaller than your roadmap and more finished than a demo. Before a raise, an MVP is often a test of whether anyone cares. After a raise, the bar moves. Investors expect customers. Customers expect sign in to work, their data to be safe, and the main job to be done well. A prototype that wobbles in a live demo is a risk now. So picture v1 as one clean road, fully paved, from the front door to the destination. Side streets come later. ## How do you decide what goes into v1? Write one sentence about one customer doing one job, then sort every idea into must have, should have and later. Only the must haves go. Start from one customer doing one job, and include only what that job needs. Everything else goes on a list called "later". Write one sentence: "A \[type of customer\] uses \[product\] to \[job\] in \[time\] instead of \[how they do it today\]." Scoping starts once you can write it. Then sort every feature idea into three piles: | Pile | Test | Examples | | ----------- | ---------------------------------- | --------------------------------------------------------- | | Must have | The job fails without it | Sign in, the core flow, saving work | | Should have | The job is painful without it | Basic settings, email notifications, simple help | | Later | Nice, but the job works without it | Dashboards, integrations, roles, billing tiers, dark mode | Be strict with the second pile. Most of it can wait one release. Ryan Singer's Shape Up method from Basecamp has a useful idea here: set an appetite, a fixed time budget, and shape the scope to fit it instead of estimating a scope and hoping the time works out ([Basecamp, Shape Up, "Set Boundaries"](https://basecamp.com/shapeup/1.2-chapter-03)). For a v1, choose the appetite first. Then cut until the work fits. ## How do you plan v1 across the first 90 days? The first 90 days after a raise decide whether v1 ships while the money still feels new. Split them into five stages across about 12 weeks, and give each stage one thing you could put in an investor update. Before week 1, settle four things: what v1 must do, who builds it, how it will be hosted, and who owns the code and designs at the end. Then run twelve weeks. | Weeks | Design work | Build work | What you can tell investors | | -------- | ---------------------------------------------------------------- | --------------------------------------- | -------------------------------------------- | | 1 to 2 | Customer interviews, the v1 promise, first concept | Accounts, hosting, app shell | The problem, the first users, the v1 promise | | 3 to 4 | Core flow screens tested with real people, a small design system | Sign in, data model, billing setup | Screens and early feedback | | 5 to 8 | Empty, error and loading states; onboarding | The core flow end to end | A working product in a test space | | 9 to 10 | Polish, accessibility fixes | Edge cases, monitoring, backups | Ready for first customers | | 11 to 12 | Fixes from real use | Private launch with the first customers | First real usage and what comes next | A few weekly habits keep the plan honest. Hold one demo of working software every week, even if it is ugly. Keep one written list of what is out of v1, and add to it every time someone asks for more. Talk to at least one customer every week. The biggest early choice is who builds it: a technical cofounder, your own hires, a freelancer or a product studio. The section on who should build v1, below, compares the four options. ## Why should you design v1 before you build it? Because changing a screen in a design file takes minutes, and changing it in code takes days. Design is where you make the cheap mistakes. Design for a v1 does three jobs: 1. **It forces decisions.** What happens when the list is empty? What does a new user see first? Who can delete what? Code will answer these by accident if design does not answer them on purpose. 2. **It gives customers something to react to.** Put clickable screens in front of five target customers before a line of production code. Their confusion is free research. 3. **It sets the parts list.** Buttons, inputs, tables and colors defined once become a small design system that engineers reuse, so the product feels like one thing. Get the first concept in front of the team early, while the decisions are still fresh. Onboarding deserves its own care, covered, and how big the design system should be is in [When Your SaaS Needs a Design System, and How Big](https://gr8rstudio.com/blog/saas-design-system-v1). ## What does the build process look like week by week? We split a v1 into five stages, each ending in a demo: foundations, the core flow, the edges, polish and safety, and a private launch. Illustrative diagram based on this article. Not product UI, not real data. Build in steps you can demo. Each week should end with something a person can click, ideally on a real server with real data. A typical v1 moves through five stages: 1. **Foundations.** Accounts, sign in, the app shell, the database, hosting and deployment. Boring, and everything depends on it. 2. **The core flow.** The one road from the sentence you wrote earlier, end to end, even if rough. 3. **The edges.** Empty states, errors, loading, permissions, the weird inputs. 4. **Polish and safety.** Performance, accessibility, security review, backups, monitoring. 5. **Private launch.** A handful of real customers, watched closely. Tie progress to demos. "By Friday you can sign up, create a project and invite a teammate" is a milestone you can check. Accessibility is cheaper on day one than as a retrofit. The W3C's Web Content Accessibility Guidelines are the standard reference for what that means in practice ([W3C WAI, WCAG overview](https://www.w3.org/WAI/standards-guidelines/wcag/)). ## Who should build your v1? Pick the team shape that matches your stage and what you lack. The best choice is the one that gives you design, frontend and engineering pulling in the same direction. | Option | Good when | Watch out for | | ---------------------- | ------------------------------------------------- | -------------------------------------------- | | Technical cofounder | You want a long term partner and can share equity | It is the hardest hire and can take months | | Freelancer | The build is narrow and you can manage it | Design, frontend and backend may not join up | | Product team or studio | You are funded and need a whole team now | Pick one that shows working software weekly | | In house hires | You are ready to build a permanent team | Hiring takes time while the clock runs | Our view at Gr8r: whichever route you choose, judge it on working software. Ask to see a live product, ask who will actually do the work, and pay against demos. The cofounder question has its own post in [who should build your startup's first product](https://gr8rstudio.com/blog/who-should-build-your-first-product), and choosing an outside team in [how to choose an AI MVP development company](https://gr8rstudio.com/blog/choose-ai-mvp-development-company). ## What if you already have a prototype built with AI tools? You have three options: keep it and harden it, keep the design and rebuild the code, or start fresh with what it taught you. Treat it as a sketch with code in it. It is valuable for what it shows, and risky for what it hides. Tools like Lovable, Bolt, Cursor and Claude Code can turn an idea into something clickable in an afternoon. That is a gift for testing an idea. The trouble starts when the same code meets real customers: sign in that was never hardened, payments wired directly to the page, data rules missing, no tests. Three honest options: - **Keep and harden.** The structure is sound; add tests, security and proper data rules. - **Keep the design, rebuild the code.** The screens are right; the plumbing is not. - **Start fresh.** It taught you what to build. Now build it properly. How to choose between them is in [Your Vibe Coded MVP Broke](https://gr8rstudio.com/blog/fix-vibe-coded-app), and the full path from demo to production. ## What does v1 need for security and data from day one? It needs the basics done properly, because customer data arrives on the first day of a private launch. Skipping them saves a week now and costs a month later. The short list for most SaaS v1s: - **Sign in you did not write yourself.** Use a proven authentication provider with password reset, email checks and sessions that expire. - **Data rules per customer.** One customer must never see another's records. Test this on purpose, with two test accounts side by side. - **Backups you have restored once.** A backup nobody has tested is a hope. - **Secrets out of the code.** API keys and passwords live in your hosting settings, out of the repository. - **Error tracking and logs.** When a customer says "it broke", you should see what happened before they finish the sentence. - **Payments through a provider.** Card details never touch your own database. None of this shows up in a demo. All of it shows up the first time something goes wrong. ## How do you know v1 is ready to ship? It's ready when outside people finish the core job without help, every screen and error leads somewhere, and you'll know when something breaks. v1 is ready when a new customer can finish the core job alone, nothing they touch leads to a dead end, and you can see and fix what breaks. Perfection is a later problem. Run this check before inviting the first customers: | Check | Pass when | | ------------ | ----------------------------------------------------------------- | | Core job | Three people outside the team finish it without help | | Empty states | Every list and screen makes sense with no data | | Errors | Every failure tells the person what to do next | | Mobile | The core flow works on a phone, even if the rest is desktop first | | Access | Keyboard navigation and contrast pass a basic check | | Data | Two test customers cannot see each other's records | | Support | A customer can reach a human from inside the product | | Monitoring | You get an alert when errors spike | If a row fails, fix it or cut the feature that causes it. ## How do you get v1 into real customers' hands? Hand pick your first customers, onboard them yourself, and watch what they do. Early users come from manual effort. Paul Graham's essay "Do Things that Don't Scale" (July 2013) makes the case that founders should recruit early users by hand and give them unusual attention ([Paul Graham, July 2013](https://paulgraham.com/ds.html)). For a funded SaaS team, that looks like: - Ten to twenty named target customers, contacted personally - A setup call with each, where you share your screen and theirs - A shared channel for questions, answered the same day - A weekly review of what each customer actually did in the product Michael Seibel's "How to Plan an MVP" in Y Combinator's Startup Library is a good companion on launching small and iterating ([Y Combinator Startup Library](https://www.ycombinator.com/library/6f-how-to-plan-an-mvp)). The goal of a private launch is learning. Watch where people stall, what they ask for twice, and what they ignore. ## What should happen in the weeks after launch? Fix what blocks the core job first, then build what paying customers ask for repeatedly. Ignore one off requests for now. A simple rhythm: - **Weekly:** review usage, support questions and bugs. Fix blockers. - **Every two weeks:** ship a small improvement customers will notice. - **Monthly:** revisit the "later" list. Promote only items more than one customer needs. Resist the urge to redesign at the first sign of friction. Small fixes to a working flow beat a fresh coat of paint on a flow nobody has finished yet. When a redesign is due, read [how to redesign a SaaS product](https://gr8rstudio.com/blog/saas-product-redesign). ## What does a well built v1 look like? It does one job with no dead ends. A new user knows what to do first, every screen has a way back, and nothing breaks when the data is empty or messy. Some real work you can open: - **HostOp.** For [HostOp](https://hostop.ai), we designed the product, built its Framer website and built an agentic design system for it. Across 50+ projects shipped, the pattern holds: the teams that ship fastest are the ones that cut hardest at the start. ## What are the most common v1 mistakes? Most v1 mistakes are scope mistakes in disguise. - **The 50 page spec.** Writing everything down and building it all at once. - **Building the dashboard first.** Charts need data, and a new product has none. - **Skipping design.** Engineers make the product decisions by default, one screen at a time. - **Demo milestones on paper only.** Progress reported in documents instead of working software. - **No owner for the code.** Code living in someone else's account. - **Launching to everyone.** Opening the doors before a handful of customers have finished the core job. ## How do you start this week? Write the one sentence: who, what job, how fast, compared with what. Then list every feature idea and sort it into the three piles. If the "must have" pile is longer than a page, cut again. ## Frequently asked questions ### How long does it take to build a SaaS MVP? It depends on how much you cut. A v1 built around one core flow, with sign in, the main job and basic settings, can usually ship in weeks to a few months. Most delays come from scope creep, unclear decisions and rebuilding a prototype that was never meant for production. ### Should a non technical founder hire a freelancer, a product studio or find a technical cofounder? A cofounder makes sense if you want a long term technical partner with equity. A freelancer suits a narrow, well defined build. A product team suits a funded company that needs design, frontend and engineering working together from day one. Whichever you choose, insist on weekly demos and owning the code. ### Can I build my SaaS MVP with AI coding tools like Lovable or Bolt? They are useful for a clickable first version you can show users and investors. Once you need real sign in, payments, permissions and customer data, the code needs a proper review and often a rebuild of key parts before real customers rely on it. ### What should be in v1 and what should wait? Keep the one flow that delivers the core value, plus the minimum around it: sign in, the main screen, basic settings and a way to get help. Push dashboards, integrations, roles and billing tiers to later unless a paying customer cannot start without them. ### How do I protect my idea and code when working with an outside team? Put the work in your own accounts from the start: your code repository, your hosting, your design files. Make sure the contract assigns all work to you once it is paid for. At Gr8r, clients own everything once it's paid for. ## Next step [Task Management](https://gr8r-studio.vercel.app/), a workspace Gr8r built, is a compact example of a v1 home screen: counters, a My tasks list and a project progress table. Built by Gr8r for its own portfolio. Not client work. It runs on demo data, so it shows the screens, not results. Task Management, built by Gr8r for its own portfolio. Not client work. Demo data. Screenshot from 6 Nov 2026 checks. If you want help with this, [book a 30 minute call](https://cal.com/tanjim-38/30min). ## Related reading - [how long an MVP takes](https://gr8rstudio.com/blog/mvp-cost-and-timeline-drivers) - [MVP examples from our in house builds](https://gr8rstudio.com/blog/mvp-examples-in-house-builds) - [rescue or rebuild a vibe coded MVP](https://gr8rstudio.com/blog/fix-vibe-coded-app) - [What Is Product Discovery, and What Should It Hand You?](https://gr8rstudio.com/blog/what-is-product-discovery) - [freelancer or product team for your MVP](https://gr8rstudio.com/compare/freelancer) - [MVP Development](https://gr8rstudio.com/services/product-engineering) - [Product Design](https://gr8rstudio.com/services/product-design) _Tanjim Islam is the founder of Gr8r Studio, a digital product and AI engineering partner for scaleups and enterprise teams, founded in 2023._ Written by Tanjim Islam Founder & CEO Share [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fgr8rstudio.com%2Fblog%2Fsaas-mvp-product-design-guide)[X](https://x.com/intent/post?url=https%3A%2F%2Fgr8rstudio.com%2Fblog%2Fsaas-mvp-product-design-guide&text=How%20to%20Build%20a%20SaaS%20MVP%20After%20You%20Raise) This article supports [Product Engineering](https://gr8rstudio.com/services/product-engineering)[Scope your MVP](https://cal.com/tanjim-38/30min) ## Keep reading - [ MVP 26 Oct 26 6 min read What Is an MVP in Software Development?What is an MVP in software development? A plain definition, what goes in and out, and how it differs from a prototype, a v1 and a proof of concept.By Tanjim Islam](https://gr8rstudio.com/blog/what-is-an-mvp) - [ MVP 26 Oct 26 6 min read What Drives the Cost and Timeline of an MVPHow much does it cost to build an MVP? It depends on seven drivers you control. What each one does to cost and time, and how to shrink the range.By Tanjim Islam](https://gr8rstudio.com/blog/mvp-cost-and-timeline-drivers) - [ MVP 26 Oct 26 6 min read MVP Examples: Five First Versions We Built and What Each Left OutMVP examples from five builds you can open today: a hospital system, a referral tool, an agent workspace, an asset catalog and a task app.By Tanjim Islam](https://gr8rstudio.com/blog/mvp-examples-in-house-builds) ## Book a call with our CEO. Pick a time that suits you. A product idea or a workflow that slows your team down: a clear problem is enough, no full specification needed. 5.0 [11 verified reviews Read them on Contra ](https://contra.com/tanjimislam/reviews) - Tanjim is a great designer without any doubt. I love the way he heard my project details and created the better design I was looking for. I highly recommend Tanjim to other Business owners. Thanks Tanjim 馃 Muhammad Talha 路 Founder, SetFrame - Amazing work as always! Md Nomail Hossain Samir 路 Co-founder, Remarked Design - It was really amazing to work with Tanjim, superfast delivery and amazing work Dhruval Golakiya 路 Founder, Ryplix - It was really amazing to work with Tanjim, Superfast delivery and amazing work, highly recommended for any website design and development Dhruval Golakiya 路 Founder, Ryplix - Tanjim and his team did a great job on the hero section I needed in Framer. Super easy to work with and delivered exactly what I had in mind. Highly recommeded! Muhammad Talha 路 Founder, SetFrame - Tanjim is very good at what he does & super easy to work with. He is a genuinely good guy. I highly recommend him! Md Nomail Hossain Samir 路 Co-founder, Remarked Design - Tanjim is a very talented designer who delivers high-quality work with precision. I hired him to handle client projects for my agency & he exceeded expectations every time. If you need an efficient designer, he is the one to go for! Md Nomail Hossain Samir 路 Co-founder, Remarked Design - Every project I鈥檝e entrusted to Tanjim has exceeded expectations. If you're looking for a top-tier designer who consistently delivers exceptional work, Tanjim is the one. Looking forward to working together on more projects 馃 Md Nomail Hossain Samir 路 Co-founder, Remarked Design - Tanjim is an excellent guy. He is super professional in his work and always goes the extra mile. If you're looking for any UI or Framer work, I highly recommend him! Md Nomail Hossain Samir 路 Co-founder, Remarked Design - Tanjim is the founder of Gr8r studio and his Framer expertise is exactly what you need if you are looking for design and development work. Tanjim goes the extra mile on his projects and his attention to detail makes every website stand out I collaborated with Tanjim on a project and he is my main choice for a design partnership. Miguel Queir贸s 路 Collaborator Your call is with Tanjim Islam, our CEO A free 30-minute conversation about your problem, not a sales pitch. Calendar not loading? [Open the booking page](https://cal.com/tanjim-38/30min) Ask Ali