Three years ago, I made a bet: We could build a social commerce platform serving Nigeria on a single budget VPS. No cloud. No auto-scaling. Just me, a server, and a lot of optimization.
That bet paid off. We scaled to 102,000 users, processed around 2 million monthly events, and maintained roughly 99.2% uptime.
Now I'm about to reverse that bet. In Q1 2026, we're migrating everything to Azure.
This post isn't about our technical wins (I cover the architecture in another article). This is about the mistakes we made, the technical debt I'm now paying for, and the fears that wake me up thinking about this migration.
If you're a solo founder or small team considering "should I start with cloud or build lean first?" — this is for you.
The Decision That Started Everything
December 2021: The Budget Reality
We raised about ₦15 million (roughly $10,000 USD). In Silicon Valley, that's a weekend's AWS bill. For us in Nigeria, it needed to last 18 months.
We ran the numbers.
Option A: AWS from Day One (rough estimate)
- t3.medium instance: ~$40/month
- RDS MySQL: ~$50/month
- S3 + CloudFront: ~$30/month
- Data transfer: ~$20/month
Total: ~$140/month ≈ $2,520 over 18 months
Option B: Budget VPS
- VPS hosting: $20/month
- Domain: $12/year
- SSL: Free (Let's Encrypt)
Total: ~$20/month ≈ $360 over 18 months
Savings: roughly $2,160
That $2,160 was:
- 6 months of a junior developer, or
- User acquisition for thousands of users, or
- A few extra months of runway
I chose Option B.
At the time, it felt smart. Today, I'm not so sure.
What We Got Right
1. I Became a Really Good Optimizer
When you can't throw money at problems, you learn to actually solve them.
Example: Our feed query
- Started at: ~6.4 seconds (joining 7 tables)
- Optimized to: ~280 ms (denormalized + caching)
If I'd been on AWS, I might have just:
- Upgraded the database instance
- Added read replicas
- Thrown a managed cache at it
Instead, I learned:
- How MySQL query planning actually works
- When denormalization makes sense
- Strategic caching patterns
- Proper indexing
That made me a better engineer.
2. I Understood Every Bottleneck
When your server crashes, you don't have a DevOps team to call. You are the DevOps team.
Example: The image upload disaster
Synchronous image processing was holding connections for 8–15 seconds. At 50K users, this killed the server.
On a fully managed stack, I might have just:
- Scaled horizontally
- Never understood why it was slow
- Accumulated more inefficient code
Instead, I learned:
- Async job processing
- Queue management
- Background workers
- Resource optimization
That gave me a deep understanding of the system.
3. We Actually Made Money
Rough current metrics:
- Revenue: ₦850,000/month
- Infrastructure cost: ₦25,000/month
- Infrastructure margin: 97%
On a heavier cloud stack at this stage, those margins would likely have been much thinner.
For a bootstrapped team, that difference mattered.
What I Got Wrong
1. I Built Technical Debt Into the Architecture
The mistake: Everything runs on one server.
Single VPS:
├── Web server (Nginx)
├── Application (Laravel)
├── Database (MySQL)
├── Cache (Redis)
├── Queue workers
└── Cron jobs
This works… until something breaks. Then everything breaks.
What I should have done (even on bare metal):
- Separate the database
- Separate Redis
- Separate app and background workers
- At least design with separation in mind
Now I have to untangle this while keeping 102K users online.
2. I Avoided Managed Services Too Long
The mistake: I manage everything manually.
Things I do by hand:
- Database backups (daily scripts)
- Security updates (manual
apt-get) - SSL renewal (Let's Encrypt automation I maintain)
- Log rotation and retention
- Monitoring scripts and alerting bots
Time spent on ops per week: 8–12 hours.
Even on a budget, some managed pieces would have been worth it:
- Managed backups
- Automated security patching
- Proper observability
Those 8–12 hours each week are expensive at CTO rates.
3. I Optimized for the Wrong Metric
The mistake: I optimized for server cost, not business cost.
Hosting cost saved: $2,160 over 18 months.
What I didn't do because I was babysitting infrastructure:
- Ship a better iOS/Android experience sooner
- Implement marketplace v2 earlier
- Add real-time notifications
- Build proper internal analytics
- Focus on expansion outside our first market
The opportunity cost is easily larger than the hosting savings.
4. I Accumulated Monitoring Debt
My monitoring started like this:
#!/bin/bash
curl -f http://localhost/health || telegram_alert "Server down!"
It works, but it only tells me:
- That something broke
- After users start to feel it
What it doesn't tell me:
- Why it broke
- What's slow
- How things are trending over time
Proper observability (like Application Insights or similar) would have caught a lot earlier what I currently discover from user complaints.
5. I Have No Tested Disaster Recovery Plan
I do have backups:
mysqldump --all-databases > backup.sql
rsync backup.sql user@backup-server:/backups/
What I hadn't done (for a long time):
- Regular restore tests
- Measured recovery time
- Documented recovery steps
- Considered geographic redundancy
That's not a real DR strategy. That's just "I hope this file works when I need it."
Why I'm Migrating to Azure in 2026
It's not because the VPS stopped working. It's because I'm hitting ceilings.
Ceiling 1: Scaling Beyond ~150K Users
Current bottlenecks:
- Single database struggling with writes
- One server handling all traffic
- Manual, error-prone scaling
To reach 500K+ users, I'll need:
- Database replication or a more scalable database
- Load balancing
- Multiple app instances
- CDN and distributed caching
You can build all this yourself on VPSs, but it's complex and fragile. Azure gives you managed building blocks for these patterns.
Ceiling 2: Operational Burden on One Person
Right now:
- I'm the only person who can deploy
- I'm the only person who can debug production
- Real vacations are hard
- 3 AM alerts come to my phone
That doesn't scale.
On Azure, with managed services and clearer separation, more of the team can own operations, and the platform doesn't depend on me being awake.
Ceiling 3: We Can Now Afford Better Infrastructure
2021: every ₦1,000 mattered.
2025/2026: we have recurring revenue.
We can now justify:
- $500–$800/month on infrastructure
- Proper monitoring and logging
- Managed database/caching
- A lot less stress
It's time to graduate.
What Terrifies Me About This Migration
Fear #1: Cost Explosion
We've all heard stories like:
"We migrated to cloud. First month: $300. Second month: $1,200. Third month: $4,800. Someone left a test resource running."
My nightmare:
- Misconfigured auto-scaling
- No guardrails
- Surprise bill that burns months of runway
Mitigation I'm planning:
- Azure budgets and cost alerts
- Internal hard limits on what we provision
- Start with minimal services
- Gradual scaling, not "all-in" from day one
I'll still be watching bills nervously at first.
Fear #2: Downtime During Migration
Our users rely on the platform:
- ~102K active users
- 500+ vendors earning income
A bad migration could literally pause people's livelihoods.
Mitigation:
- Run VPS and Azure in parallel for a while
- Gradual traffic shift (1% → 10% → 50% → 100%)
- Clear rollback strategy
But there's always that "what if we missed something?" feeling.
Fear #3: Over-Engineering in the Cloud
Cloud makes it very easy to overdo things:
- Too many databases
- Overcomplicated microservices
- Three different messaging systems
- "Because we can" architecture
What we actually need:
- App Service (compute)
- Managed MySQL (or equivalent)
- Redis (caching)
- Blob Storage (files)
- CDN (static assets)
Anything beyond that has to prove it's necessary.
Fear #4: Vendor Lock-In
On VPS:
- We can move providers in a day or two
- Everything is relatively portable
On Azure:
- We'll be using Azure-specific services and tooling
- Moving away later will be harder
Mitigation:
- Prefer standard protocols and services where possible
- Avoid Azure-specific APIs until they're truly needed
- Keep an exit strategy in mind
Vendor lock-in is real, and I want to go in with open eyes.
Fear #5: My Optimizations Becoming Problems
I've leaned heavily on:
- Denormalization
- Custom caching layers
- Manual query tuning
- Homegrown job orchestration
I worry about:
- Which of these patterns will still make sense in a managed, distributed environment
- Which optimizations might become unnecessary or even harmful
Some will transfer directly. Some I'll need to unlearn.
The Migration Plan (3 Phases, 6 Months)
Phase 1: Hybrid Mode (Q1 2026)
Budget: $100–$150/month
Move to Azure:
- Azure CDN (static assets)
- Azure Blob Storage (uploads)
- Application Insights (observability)
Stay on VPS:
- Application server
- Database
- Redis
- Background jobs
Goal: learn Azure on low risk, measure impact.
Phase 2: Compute Migration (Q2 2026)
Budget: $300–$500/month
Move to Azure:
- Azure App Service (application)
- Azure Database for MySQL
- Azure Cache for Redis
Keep on VPS temporarily:
- Background jobs and some cron tasks
Goal: main user traffic on Azure; VPS as safety net.
Phase 3: Full Cloud (Q3 2026)
Budget: $500–$800/month
Move to Azure:
- Azure Functions (background processing)
- Azure Service Bus (job queue, if needed)
- Remaining services
Retire:
- VPS entirely
Goal: cloud-native, managed, and much less manual ops.
Questions I Need Answered
If you've migrated from self-hosted to Azure (or AWS), I'd love your input:
1. Cost Management
- How do you prevent cost surprises?
- Which Azure services tend to cause unexpected spend?
- What cost optimizations do you apply from day one?
2. Migration Approach
- Did you do lift-and-shift first or re-architect immediately?
- What do you regret (either way)?
3. Downtime Risk
- How did you handle database migration and cutover?
- How did you validate the new stack before full switch?
4. What Broke
- What worked fine on VPS / bare metal but broke in cloud?
- Any issues with file system assumptions, cron jobs, or long-lived connections?
5. What You Wish You'd Known
- Hidden costs (data transfer, logging, etc.)?
- Region selection surprises?
- Managed-service gotchas?
What I'm Learning
Lesson 1: "Start With Cloud" vs "Start Lean" Depends
If you're optimizing for:
- Learning → VPS is great
- Speed to market → Cloud is usually better
- Cost at 1K users → VPS often wins
- Cost at 100K users → Cloud may win
- Your personal time → Cloud usually wins
Lesson 2: Technical Debt Is Real Debt
I saved about $2,160 on hosting.
I accumulated:
- Manual ops burden (8–12 hours/week)
- Delayed features
- Fragile architecture
- Migration complexity
For learning, I'd do it again. For business, the trade-off is less clear.
Lesson 3: Know When to Graduate
There's a time to:
- Bootstrap and squeeze every resource
- Invest in stability and scalability
- Professionalize your infrastructure
I bootstrapped well. I might have stayed in that phase too long.
Lesson 4: Budget Constraints Teach You
Being forced to optimize made me better at:
- Query optimization
- Resource management
- System design under constraints
I don't regret the VPS era. But I'm ready for the cloud era.
Resources Helping Me Plan
Learning:
- Microsoft Learn: Azure fundamentals
- Azure Architecture Center
- Community posts, talks, and case studies
Tools:
- Azure Pricing Calculator
- Azure Cost Management (once live)
- Terraform for infrastructure as code
- Azure DevOps / GitHub Actions for CI/CD
Communities:
- Microsoft Tech Community
- Dev.to
- Local Nigerian tech ecosystem
Connect:
- Dev.to: @onoja5
Top comments (9)
Hi
Take a look at LayerOps.io.
It guarantees the portability of your services across clouds and enables you to use hybrid clouds.
In short, you can use VPS at the best price, with the ability to switch to the public cloud if necessary (downtime, scaling, etc.).
Thanks to the ability to combine different types of resources (VPS, bare metal, cloud instances, etc.), you can take advantage of the best of each offering, with the ability to switch at any time, either by choice or in the event of a major incident with your primary provider.
Thanks for this. LayerOps looks really okay, the hybrid VPS + cloud approach could solve my vendor lock-in concerns.
Have you used it in production? Curious about real-world experiences.
Appreciate the recommendation.
Sure.
Several use cases, including savings of 5x on a migration from AWS to hybrid cloud (3 bare metal 32GB RAM)
Check Youtube channel, you will understand ;)
youtube.com/@layerops/videos
Many thanks, I will look this up.
Another cool post, and what I love the most is your honesty!
For me this one felt a little bit less "compelling" than the first one - probably that's because that one was about your "pioneering" phase - but, I completely understand that at some point you'll need to "graduate" ...
P.S. the fact that you need to move to the cloud now speaks to the success of the project/company!
Thank you @leob and you are right, that early phase I wrote about makes for better stories than this, because it's time to be a responsible adults 😄.
The first post was more fun to write too, honestly. Funding and optimization war stories.
But yeah, needing to migrate because we outgrew the VPS is definitely a good problem to have. Appreciate you following the journey.
Yeah the pioneering story was for sure engrossing, the cloud thing is a bit more mainstream, but yeah as you said "we need to grow up and become responsible adults" LOL :D
Anyway, another good step - will be eagerly awaiting the follow-up!
Thanks for following along Leob, appreciate it.