Why 30 days matters more than you think
Most SaaS projects die in month three. Not because the idea was bad, but because the founder spent eight weeks building features nobody asked for, then lost momentum before a single person paid. A 30-day sprint forces you to confront reality early: either people want this enough to pay, or they don't.
The constraint isn't arbitrary. Thirty days is long enough to build something real but short enough that you can't hide behind "just one more feature." You'll make trade-offs that hurt. Some features you love won't make the cut. That's the point. Every SaaS that reached €10k MRR started with a version that embarrassed its founder.
This plan assumes you're working evenings and weekends, or can dedicate roughly 4-6 hours per weekday. If you're full-time on this, you'll move faster—but don't. The discipline of constrained time prevents gold-plating. You want to be slightly ashamed of what you ship on day 30.
Week 1: Brief, landing page, and first conversations
Days 1-2: Write the one-pager
Start with a single Google Doc. At the top, write the problem in one sentence a customer would say out loud. Not "businesses struggle with inefficient workflow management"—something like "I spend two hours a week chasing people for status updates." If you can't write that sentence, you don't have a problem yet. Talk to three people in your target market before writing another word.
Under the problem, describe your solution in three bullet points. Each bullet is a capability, not a feature. "See which projects are blocked without asking" is a capability. "Real-time dashboard with Gantt charts" is a feature. You're solving the problem, not listing widgets.
Add your business model: who pays, how much, how often. If you're targeting small agencies, you might charge €79 per agency per month. If you're going after freelancers, maybe €19 per user. Pick one. You can change it later, but you need a number to design around. Write down what someone gets for that price in plain terms.
Days 3-5: Ship the landing page
Build this in Marcus. You need seven elements: a headline that repeats the problem, three capability bullets, pricing, a FAQ with four questions, a signup form, and social proof (even if it's "Used by 12 teams" after you've demoed it to a dozen people). No blog. No about page. No feature comparison table.
The signup form should collect email and ask one qualifying question: "What's the biggest pain point you're trying to solve?" This isn't for you to feel good—it's data. When 80% of responses mention the same thing, that's your actual problem to solve. When answers are all over the map, your positioning is broken.
Deploy this by end of day 5. Share it in two places where your customers already gather. A Slack community, a subreddit, a LinkedIn group. Not Twitter unless your customers live on Twitter. You want 30-50 signups by end of week one. If you get six, your problem isn't painful enough or you're talking to the wrong people.
Days 6-7: Ten conversations
Email everyone who signed up and offer a 15-minute call. Your goal is to get ten of these calls done by Sunday night. Ask the same four questions every time: What are you using now? What does it cost you in time or money? What would make you switch? If I built this, would you pay €X for it?
Half will say yes and mean no. A quarter will say no honestly. The last quarter will say "build this and I'll pay you Monday." Those are your design partners. You're building the MVP for them, not for the polite yeses.
Week 2: Build the thinnest possible MVP
Days 8-9: Define the three-feature MVP
Look at your conversation notes. Find the three capabilities that came up in at least seven of the ten calls. Not features—capabilities. If people said they need to "stop hunting for files," that might be one capability. The feature could be a shared upload area with notifications. Pick the boring solution that solves it in 48 hours of build time.
Write these three capabilities on a notecard. Anything not on the card doesn't get built in week two. Not user roles. Not integrations. Not dark mode. When you're tempted to add a fourth thing, remember: you're trying to prove people will pay for this, not win an awwwards nomination.
Days 10-14: Build in Marcus, no custom code
Use Marcus's AI builder to scaffold the three screens you need. Most SaaS MVPs are a list view, a detail view, and a settings page. If you're building that status-update tracker, you'd have a project list, a project detail with updates, and a team settings page. That's it.
Wire up authentication using Marcus's built-in auth. Don't roll your own. Connect a database for storing projects and updates—Marcus handles the schema. Add one automation: when someone posts an update, email the project owner. This isn't Zapier integration territory. This is Marcus's built-in email action on a database trigger.
Deploy to a real domain by end of day 14. Not a staging subdomain. The actual product URL. It should load in under two seconds and work on mobile. Ugly is fine. Broken is not.
Week 3: Get five people to pay you
Days 15-16: Set up payments and onboarding
Add Stripe integration through Marcus. Create one plan: your target price from day two, billed monthly. No annual discount. No free tier. No trial that converts automatically. People pay upfront or they don't get in. This feels harsh. It's the only way to know if your solution is worth money.
Build a three-step onboarding flow. Step one: connect their team (even if it's just entering coworker emails). Step two: create their first project. Step three: post the first status update. Each step should take under 60 seconds. The whole flow should land them in the product looking at their own data, not an empty state that says "Get started by inviting your team!"
Days 17-19: Personal outreach to design partners
Email the people from week one who said they'd pay. Not a blast—individual emails. "I built the thing we talked about. Here's the link, here's what it costs. You're one of the first five people to use it, so if something's broken, text me at this number." Give them your actual phone number.
Offer to walk them through setup on a screenshare. Half will take you up on it. Do the calls. Watch where they hesitate. Watch what they click expecting it to do something it doesn't do. Don't explain how it's supposed to work—fix it that night so it works the way they expected.
Your goal is five paying customers by end of day 19. Not signups. Not trials. Five people who gave you their credit card and got charged. If you get two, you're probably solving a vitamin problem, not a painkiller. If you get eight, you're onto something real.
Days 20-21: Support and observation
Spend these two days in your customers' inboxes and in the product usage logs. Are they logging in daily? Weekly? Once and never again? Daily login means you're solving an active pain. Weekly means it's a nice-to-have. Once means you missed.
Answer every support question in under two hours. Not because that's scalable—it's not—but because these five people are telling you what's broken in language you can fix. When someone says "I can't figure out how to archive a project," don't send them a help doc. Add an archive button where they expected to find it.
Week 4: Iterate on the loudest signals
Days 22-24: Fix the top three friction points
By now you have real usage data. Look at where people drop off in onboarding. Look at what features they're ignoring. Look at what they're asking for in support emails. Make a list of every complaint and every confusion point.
Pick the three that came up most often and fix them. Not redesign—fix. If people can't find the settings page, put a settings link in the header. If they're confused about what happens when they post an update, add a one-sentence explanation under the text box. If they keep inviting the same person twice, dedupe the email list.
Deploy each fix the same day you build it. You have five customers. You can email them individually and say "that thing you mentioned yesterday—fixed." They'll notice. They'll tell other people you're responsive. That reputation matters more than your feature set in month one.
Days 25-27: Add the one feature everyone asked for
If four of your five customers asked for the same thing, build it. Not the way you'd architect it for scale—the way that gets it working in three days. If they want Slack notifications, use Zapier as glue code. If they want to attach files, use Marcus's file upload and store them in the database. If they want to filter the project list, add a dropdown with three options.
This is your first post-launch feature. Ship it by day 27 and email your customers to tell them. Include a screenshot. Half of them will reply with the next thing they want. That's your roadmap for month two.
Days 28-30: Get to ten customers
You have three days to double your customer count. This is not about going viral. This is about personal outreach to the 40 people who signed up in week one and didn't take your call. Email them again: "I've had five teams using this for two weeks. Here's what they're saying. Want to try it?"
Post in the same communities where you shared the landing page. This time you're not asking for interest—you're sharing a small case study. "We launched two weeks ago. Five agencies are using it to eliminate status update meetings. Here's how it works." Link to the product, not the landing page.
Offer a live demo to anyone who replies. Do the demos on day 29. Close as many as you can on day 30. Your target is ten total paying customers by midnight on day 30. If you hit it, you have a business. If you don't, you have clarity on what to fix in week five.
What to skip without guilt
No blog. You're not doing content marketing in month one. No integrations beyond Stripe and maybe Zapier. No mobile app. No user roles and permissions unless you're selling to enterprises, and if you're selling to enterprises in a 30-day sprint, you've misunderstood the assignment.
No analytics dashboard in the product. Use server logs and Stripe data. No email sequences. You'll email people manually. No help docs. You'll answer questions in emails until the same question comes up five times, then you'll add inline help text.
Skip anything that sounds like "we should probably..." or "users will expect...". Build only what you've watched a real human struggle without. Every feature you don't build is a feature you don't have to maintain when you're rewriting the MVP in month four.
The four non-negotiables
Authentication that works. If someone can't log in reliably, nothing else matters. Use Marcus's built-in auth or a service like Auth0. Don't build your own password reset flow.
Payments that are live on day 15. Not "coming soon." Not "beta pricing TBD." A real Stripe integration that charges real cards. The act of asking for money will teach you more about your value prop than a hundred customer interviews.
A way to reach you. Email, phone number, or in-app chat. One channel, monitored obsessively. The expected response time in week three is under four hours. You can slow down in month three. Not before.
Data you can export. Even if it's a CSV download with no formatting. Your customers need to know their data isn't trapped. This builds trust faster than any security badge or privacy policy. Add the export button on day 14 and test it yourself before anyone else uses it.
What happens on day 31
If you have ten paying customers, spend week five doing nothing but support and observation. Don't build new features. Watch how people use what you built. Read every support email twice. Look for patterns in confusion.
If you have five to nine customers, spend week five on outreach. You proved the problem is real, but your go-to-market needs work. Try a different channel. Write a cold email sequence. Post in a different community. The product is good enough—your distribution isn't.
If you have fewer than five, you have a decision. Either the problem isn't painful enough, the price is wrong, or you're talking to the wrong market. Pick one to change and run another two-week sprint. Don't rebuild the product. Fix the positioning or the price, then go find different customers.
The worst thing you can do on day 31 is retreat into building. You just spent 30 days learning what the market actually wants. Now you validate or invalidate those lessons with more customers, not more code.
Real numbers from a 30-day launch
When we built the first version of Marcus's project collaboration tools, we followed this exact plan. Week one: 47 signups, 11 calls. Week two: three core screens, no settings page. Week three: six paying customers at €29 per month. Week four: fixed email notifications, added file attachments, got to 14 customers.
Revenue on day 30: €406 per month. Not enough to quit a job. Enough to know we were solving a real problem. By day 90 we were at €2,800 per month with 73 customers. By day 180 we crossed €10k MRR. None of that happens if we spend week two adding user permissions and dark mode.
The feature we thought was essential—a timeline view of all updates—got used by 9% of customers in month one. The feature we added in week four because everyone asked for it—file attachments—got used by 91% of customers within three days. You can't know this from customer interviews. You learn it by shipping and watching.
Your 30-day launch won't look exactly like this. Your market is different, your problem is different, your execution will hit different snags. But the shape is the same: talk to humans, build the boring solution, charge money early, iterate on signal. Do those four things in 30 days and you'll know if you have a business. Most founders take six months to learn what you'll know in a month.