I've been building Academy for over a year now.
It's a medical education platform for students. Flashcards, spaced repetition, study tracking, gamification. Launching September 2026.
Along the way, I've made every mistake possible. Wrong tech choices. Over-engineering. Under-engineering. Pricing that made no sense. Features nobody asked for.
Here's what I wish someone had told me before I started.
Lesson 1: pick boring technology
My first instinct was to use the shiniest tools. New frameworks. Cutting-edge libraries. Things I'd read about on Twitter.
Bad idea.
Every new tool is a learning curve. Every beta library is a potential bug. Every "exciting" choice is time not spent building features.
What I actually use:
- Next.js for the web app (stable, huge community, great docs)
- NestJS for the backend (structured, TypeScript-first, scalable)
- Flutter for the mobile app (one codebase, two platforms)
- PostgreSQL for the database (boring, reliable, works)
No bleeding edge. No "let's try this new thing." Just tools that have been battle-tested by thousands of developers.
The best technology is the one you don't have to think about.
Lesson 2: start with a VPS, not AWS
I spent weeks researching AWS. EC2, RDS, Lambda, S3, CloudFront... The complexity was overwhelming. The pricing was unpredictable.
Then I discovered: a simple VPS handles way more than you think.
My current setup:
- PulseHeberg PERF-4: 4 vCPU, 8GB RAM, €10/month
- Handles development workload easily
- Can scale to 2,000-5,000 users before needing upgrades
AWS makes sense at scale. But "scale" is not 100 users. It's not even 1,000 users. Start simple. Upgrade when you have the problem, not before.
Lesson 3: Stripe over everything else for payments
I evaluated RevenueCat, Paddle, Lemon Squeezy, and Stripe.
I chose Stripe. Here's why:
- RevenueCat: Great for mobile subscriptions, but takes 1-2% on top of app store fees. For a web-first SaaS with mobile app, it adds unnecessary cost.
- Paddle/Lemon Squeezy: Handle VAT/taxes for you, but take 5%+ fees. Good if you hate tax compliance, expensive otherwise.
- Stripe: 2.9% + €0.25 per transaction. You handle taxes, but you keep more money.
For Academy (€9.99/month freemium model):
- RevenueCat would cost ~€0.20 extra per transaction
- Over 1,000 subscribers, that's €2,400/year lost
I'd rather spend a few hours setting up tax compliance than lose that revenue.
Lesson 4: freemium is harder than it looks
My initial plan: free tier with basic features, paid tier with everything else.
Sounds simple. It's not.
Questions I didn't anticipate:
- What's "basic" enough to be useful but limited enough to convert?
- How do I prevent abuse of the free tier?
- How do I track feature usage to know what converts?
- What happens when a paid user downgrades?
What I learned:
- Free tier should solve one problem completely, not give a taste of everything
- Limits should be obvious: "5 flashcard decks" is clearer than "basic analytics"
- Track everything: which free features lead to upgrades?
- Make upgrading frictionless: one click, not a sales call
Lesson 5: don't build features nobody asked for
I spent 3 weeks building a complex analytics dashboard.
Beautiful charts. Export to PDF. Comparison views. The works.
Users wanted: "Show me what I studied today."
That's it. A simple list. Not a dashboard. Not charts. A list.
Now I follow this rule:
The best feature is the one that solves a real problem. Not the one that looks impressive in a demo.
Lesson 6: mobile and web are different products
"I'll just make a responsive web app" was my initial plan.
Then I tried using my own app on mobile. The experience was terrible. Tap targets too small. Navigation confusing. Performance sluggish.
Mobile users expect:
- Offline access
- Push notifications
- Native gestures (swipe, pull to refresh)
- Fast startup time
A responsive web app doesn't give you that. So I built a Flutter app.
But here's the catch: now I maintain two codebases. Two sets of bugs. Two release cycles.
My advice:
- If mobile is critical: build native (or Flutter/React Native) from day one
- If mobile is nice-to-have: start web-only, add mobile later when you have revenue
- Never assume responsive = mobile-ready
Lesson 7: your first pricing will be wrong
My first pricing: €4.99/month.
Too cheap. Users assumed it was low quality. I was leaving money on the table.
My second pricing: €14.99/month.
Too expensive for students. Conversion tanked.
Current pricing: €9.99/month.
Still might be wrong. But here's what I learned:
- Price based on value, not cost: What's passing an exam worth? Way more than €9.99
- Test pricing early: Better to lose a few early users than lock in bad pricing
- Annual discounts work: 2 months free for yearly = better retention + cash upfront
- Students are price-sensitive: But they'll pay for something that actually helps
Lesson 8: launch before you're ready
Academy was supposed to launch in March 2026.
Then I added "one more feature." Then another. Then I rewrote the auth system. Then I redesigned the dashboard.
New launch date: September 2026.
6 months of delay. 6 months of building without user feedback. 6 months of assumptions that might be wrong.
What I should have done:
- Launch with flashcards only
- Get 50 users
- Ask what's missing
- Build that
Instead, I built a complete platform for imaginary users with imaginary needs.
Lesson 9: distribution is harder than building
I can build features all day. Getting people to use them? That's the hard part.
What's working for me:
- Content marketing: Blog posts, LinkedIn (this series!)
- Warm leads: My girlfriend's medical school connections
- Niche communities: Medical student forums, Discord servers
What's not working:
- Cold outreach
- Generic social media posts
- "Build it and they will come"
The uncomfortable truth: a mediocre product with great distribution beats a great product with no distribution.
Spend as much time on marketing as you do on code.
Lesson 10: it's a marathon, not a sprint
I've been working on Academy for over a year. It's not launched yet. I have zero revenue.
Some weeks I'm motivated. Some weeks I want to quit.
What keeps me going:
- 10 hours/week maximum: Sustainable pace, no burnout
- Small wins: Shipped a feature? Celebrate.
- Real deadline: September 2026, no excuses
- Diversified income: Freelance pays the bills while SaaS grows
The founders who succeed aren't the smartest. They're the ones who don't quit.
The cheat sheet
| Lesson | Action |
|---|---|
| Boring tech | Next.js, NestJS, PostgreSQL. No bleeding edge. |
| Start simple | VPS first, cloud later. €10/month handles a lot. |
| Stripe for payments | Lower fees, more control, worth the tax hassle. |
| Freemium is hard | Free tier = one complete problem solved. |
| Build what's asked | 3+ users requested it → build it. Otherwise, wait. |
| Mobile ≠ responsive | Native app if mobile is critical. |
| Test pricing early | Your first price will be wrong. That's okay. |
| Launch early | 50 users with feedback > 0 users with perfect product. |
| Distribution matters | Marketing time = coding time. |
| Sustainable pace | 10 hours/week. Don't quit. |
The lesson
Building a SaaS is 20% coding, 80% everything else.
Tech choices matter less than you think. Marketing matters more than you want. And the only real failure is giving up.
I'll let you know how the launch goes in September.
This is part 5 of my "What I learned the hard way" series. Next up: deployment and DevOps lessons nobody warned me about.
Got questions? Hit me up on LinkedIn or check out more on my blog.