Most SaaS founders I meet are building their third version of something nobody's asked to pay for yet. They've spent six months polishing the user interface, debating database schemas, and adding features that sound impressive in pitch decks but solve problems that don't exist.
Eight weeks changes everything. It's short enough to maintain urgency but long enough to build something genuinely useful. More importantly, it's the perfect timeframe to test whether people will actually pay for what you're building before you've spent your entire seed round.
Week 1-2: Pick your single workflow obsession
Your MVP isn't a smaller version of your grand vision. It's one specific workflow that one specific type of person does repeatedly. The accounting software that only handles invoicing. The project management tool that only tracks time. The CRM that only manages follow-ups.
We worked with a startup that wanted to build "Salesforce for small businesses". After two weeks of customer interviews, they discovered their target users spent three hours every Monday manually updating pipeline spreadsheets from Friday's sales calls. Their MVP became a weekend call logger that auto-generated Monday pipeline updates. Nothing else.
This constraint feels brutal if you're used to feature-rich roadmaps. But single-workflow products are easier to explain, faster to build, and simpler to price. Most importantly, they're testable. You can watch someone use your invoice generator and know immediately if it works. You can't watch someone "manage their business better".
Week 3-4: Build the unhappy path first
Most developers build the perfect scenario first: user registers, enters correct data, everything works beautifully. Then they spend months handling edge cases when real users arrive.
Start with failure states instead. What happens when someone enters the wrong file format? How do you handle duplicate entries? What's the experience when your payment processor goes down? These scenarios aren't edge cases—they're Tuesday morning.
The authentication flow that assumes everyone has Google accounts will break when your first enterprise client shows up with SAML requirements. The billing system that assumes monthly payments will collapse when someone wants annual invoicing. Build these complications early, when your codebase is still manageable.
This approach reveals architectural decisions that seem trivial until they're expensive. Single-tenant vs multi-tenant database design doesn't matter until you sign your first customer who can't share servers with competitors. Role-based permissions feel like overkill until the person paying isn't the person using your product.
Week 5-6: Make billing your competitive advantage
Every SaaS tutorial teaches you to build features first and figure out billing later. This backwards approach kills more startups than technical debt ever will.
Your billing model shapes everything: user behaviour, feature priorities, customer conversations, even your database architecture. The per-seat pricing that seems obvious for team software creates perverse incentives where customers avoid adding users who'd benefit from your product. Usage-based pricing sounds fair until customers can't predict their monthly costs.
Start charging from day one, even if it's just £10 monthly for early access. Real money changes how people interact with your product. Free users click randomly and abandon features that don't make immediate sense. Paying users read documentation, contact support, and tell you exactly what's broken.
We've seen founders validate entire SaaS concepts with nothing but a billing flow and a "coming soon" message. If people won't pay for a promise, they definitely won't pay for your implementation.
Week 7-8: Test the subscription handover
Your eight-week deadline isn't about launching publicly. It's about testing the complete customer lifecycle with real users who found your product, signed up, and started paying without your direct involvement.
This handover process breaks most MVPs. The onboarding that works perfectly when you're walking someone through it falls apart when they're clicking through alone at 11pm. The feature that seems intuitive in demos becomes confusing when there's no one to ask questions.
Find five people who match your target customer profile but have never heard of your product. Send them only your landing page URL. Watch them sign up, complete onboarding, and attempt their first real task. Don't help, don't explain, don't intervene when they're struggling.
This exercise is painful. You'll watch people misunderstand obvious buttons, skip crucial setup steps, and abandon flows that seemed foolproof. But you'll learn more about your product in five user sessions than in fifty customer development interviews.
Beyond the eight weeks
Eight weeks gives you something most founders never get: validated demand for a specific solution to a specific problem. You'll know your customer acquisition cost, your conversion rates, and your actual churn patterns. More importantly, you'll know whether you're building something people want or just something people say they want.
The temptation after eight weeks is to start building the bigger vision again. Resist this urge until you've proven your single workflow can sustain a business. The best enterprise software companies started by solving one problem exceptionally well before expanding to adjacent workflows.
Your next eight weeks should focus on making that single workflow indispensable, not adding features that dilute your core value proposition.
