The Golden Rule: Don't Optimize for Scale You Don't Have

Hosting

Option 1: VPS (Virtual Private Server)

Option 2: PaaS (Platform as a Service)

Option 3: Cloud Giants (AWS, GCP, Azure)

My recommendation

Domain Name

DNS and CDN

Cloudflare. Just Use It.

Database

For most web apps: PostgreSQL

When PostgreSQL isn't enough

Object Storage (Files, Images, Uploads)

Authentication

Transactional Email

CI/CD (Continuous Integration / Deployment)

Monitoring and Error Tracking

Analytics

Payments

The $0 Stack (Everything Free)

The $10-20 Stack (Ready for Real Users)

Mistakes I've Seen (and Made)

When to Upgrade

Now Go Build Something You have an idea. You're ready to build. And then you open your browser to set up infrastructure and suddenly you're comparing 47 cloud providers, 12 database options, and 6 different ways to send an email. Three hours later you've deployed nothing and you're reading a blog post about Kubernetes. I've built side projects that died in a week and products that made it to production with real users. The biggest lesson: your infrastructure choices in week one don't matter nearly as much as you think. What matters is shipping fast, keeping costs near zero until you have users, and not painting yourself into a corner you can't get out of. For each piece of your stack, I'll tell you what to use when you're starting, when to upgrade, and what's not worth paying for until you actually need it. If you have zero users, your infrastructure needs are trivial. A $5/month VPS can handle more traffic than most side projects will ever see. The goal at this stage is: People overthink this one more than anything else. A VPS is a virtual machine you rent. You get root access, install whatever you want, and run your app however you like. It's the most flexible and often the cheapest option. When to use a VPS: When you want full control, when you're running a backend in any language, when your app is a single service (API + database on the same box is fine for starting out). When NOT to use a VPS: If you don't want to manage a server at all (updates, security, SSH). If that sounds painful, go with a PaaS instead. Pro tip: Hetzner's price-to-performance is absurd. A 4 vCPU / 8 GB RAM box costs what DigitalOcean charges for 1 vCPU / 2 GB. For a bootstrapped project, that matters. The tradeoff is fewer data center regions and less hand-holding in the UI. You push code, it runs. No SSH, no server management, no thinking about nginx configs. When to use a PaaS: When you want to focus 100% on code and ship in hours, not days. When you're a solo founder and don't want to play sysadmin. When NOT to use a PaaS: When costs start climbing. PaaS pricing is great at $0-20/month and terrible at $200+/month. That's when you migrate to a VPS. My honest advice: skip these at the start. Unless you already know them well. AWS has 200+ services. The billing is unpredictable. The console is a maze. You will spend more time configuring IAM policies than writing code. GCP is slightly better, Azure is slightly worse. All three are designed for enterprises with dedicated DevOps teams, not solo founders. When they make sense: When you need a specific managed service (SQS, Lambda, DynamoDB), when you're at scale and need the reliability guarantees, or when you got startup credits. Apply for AWS Activate or GCP for Startups. They give $5k-100k in free credits, and that changes the math completely. The exception: If you already work with AWS daily and can set up an EC2 instance with your eyes closed, go ahead. Use what you know. Speed of shipping beats theoretical optimization. Solo/bootstrapped, day one: Hetzner VPS ($4-8/mo) if you're comfortable with Linux, or Railway if you want zero ops. You need one. Don't overthink it. Avoid: GoDaddy (upsells everywhere, renewal prices spike), Google Domains (shut down, migrated to Squarespace). Cost: A .com runs $10-15/year. A .dev or .io is $15-40/year. Don't spend $2,000 on a premium domain before you have users. mycoolapp.dev is fine. Change it later if the project takes off. Pro tip: Buy the domain early even if you're not ready to launch. Good names disappear. But don't buy 15 domains for 15 ideas. Buy one for the idea you're actually building right now. This isn't even a decision. Cloudflare's free tier is absurdly generous and there's no reason not to use it. What you get for free: Set up Cloudflare on day one. Even if your app is just a landing page. It takes 10 minutes and you get production-quality DNS and CDN for $0. When to pay: Cloudflare's paid plans ($20/mo+) add WAF rules, image optimization, and analytics. You won't need these until you have real traffic. The free tier covers 99% of startups in their first year. Alternatives: Fastly (expensive, for big scale), AWS CloudFront (complex, pay-per-use). Neither is worth it when Cloudflare free exists. Bad decisions here actually hurt, because migrating databases is painful. Choose wisely. PostgreSQL is the right default for almost every project. It handles relational data, JSON data (with jsonb), full-text search, geospatial queries, and more. It's not the best at any single thing, but it's good-to-great at everything. One database that covers 90% of use cases means fewer moving parts. My recommendation for day one: Run Postgres on your VPS if you have one. It's free and simple. If you're on a PaaS, use Supabase or Neon's free tier. When to pay for managed: When your project has real users and you can't afford downtime. Managed databases handle backups, failover, and patching. That's worth $15-30/month when people depend on your service. Hot take on MongoDB: Most projects that use MongoDB would be better served by Postgres. Mongo is great for genuinely schemaless data at massive scale. If you're building a CRUD app with users and orders, that's relational data. Use a relational database. You need somewhere to store user uploads, images, PDFs, and other files. Don't put them in your database. Don't store them on your VPS filesystem (you'll lose them when you migrate servers). Go with Cloudflare R2. The free tier is generous, there are zero egress fees (AWS S3 charges you every time someone downloads a file), and it's S3-compatible so your code works with any S3 SDK. Why egress fees matter: With AWS S3, you pay to store files AND you pay every time someone downloads them. If you host images that get popular, your bill can spike out of nowhere. R2 and Backblaze B2 don't charge egress. For a startup watching every dollar, this is the difference between a predictable bill and a surprise. Don't build auth from scratch. You will get it wrong. Password hashing, session management, OAuth flows, email verification, password reset. That's a massive surface area for security bugs, and the cost of getting it wrong is losing your users' data. If you're using Supabase, use Supabase Auth. If not, Clerk for the fastest setup, Auth.js if you want to own everything. Most free tiers cover you until 10k+ monthly active users. That's a good problem to have. Your app needs to send emails: verification, password reset, notifications. Don't use Gmail's SMTP. It'll get rate-limited and flagged as spam. Resend if you care about developer experience (great API, React email templates). Amazon SES if you want the cheapest per-email cost at scale. Pro tip: Set up SPF, DKIM, and DMARC records on your domain from day one. Without these, your emails go straight to spam. Every provider above has docs on how to do this. It takes 15 minutes and saves you hours of "why aren't users getting my verification emails?" Your code needs a home. Short answer: use GitHub. Long answer: GitHub won the developer platform war. The ecosystem is unmatched. GitHub Actions for CI/CD, Dependabot for security patches, Copilot for AI-assisted coding, and the fact that every open-source library you'll ever use lives there. Your future hires already know it. GitLab is solid if you want everything (code, CI, registry, project management) in one platform and you prefer self-hosting. Some teams love it. But for a solo founder, GitHub's free tier covers everything you need. Bitbucket still exists, mostly because of the Jira integration. If your team is deep in the Atlassian ecosystem, it makes sense. Otherwise, skip it. Free tier: GitHub gives you unlimited private repos, 2,000 CI/CD minutes/month, and 500 MB of package storage. That's more than enough for any startup. You need automated tests and deploys. Manually SSHing into your server to git pull is fine for day one and embarrassing by day thirty. Just use GitHub Actions. It's where your code already lives, the free tier is generous, and you can go from running tests to deploying to your VPS with a simple workflow file. Pro tip: If you're on a VPS and want push-to-deploy without setting up CI pipelines, look into Coolify. It's a self-hosted Heroku alternative that runs on your VPS and gives you automatic deploys, database management, and SSL through a web UI. Install it on a Hetzner box and you've got a PaaS experience for $4/month. You don't need this on day one. You need this on the day your first real user reports a bug and you have no idea what happened. Set up UptimeRobot (free, 2-minute setup) on day one so you know when your site is down. Add Sentry when you have real users so you catch errors before they report them. Don't set up Grafana/Prometheus/Loki on day one. You don't need dashboards when you have 3 users. Tail your logs with journalctl and move on. You built it. But is anyone using it? You need to know. Guessing doesn't count. If you care about privacy (and your European users), go with Plausible or self-host Umami. If you want product analytics beyond page views (funnels, user journeys, feature usage), PostHog is hard to beat on the free tier. Google Analytics is fine if you just need basics and don't mind the privacy tradeoffs. But for a startup, PostHog gives you way more signal about what users actually do in your app, not just which pages they visit. If you're building a business, you need to charge money. This is one area where you should absolutely not build it yourself. The tax question matters more than you think. If you sell to customers in the EU, you're responsible for collecting and remitting VAT in every country. That's a nightmare for a solo founder. Lemon Squeezy and Paddle handle all of that because they're the merchant of record, meaning the sale technically goes through them. You pay a higher percentage, but you don't need an accountant in 27 countries. Stripe is the right choice if you're selling in one country or you already have tax infrastructure figured out. The API is the best in the industry and the ecosystem of tools (Stripe Billing, Stripe Tax, Stripe Connect) is unmatched. For most solo founders starting out: Lemon Squeezy until the 5% fee starts hurting, then migrate to Stripe + a tax solution when revenue justifies the complexity. Here's a complete stack that costs literally nothing: Total: $0/month. This stack can handle a real MVP with real users. You won't need to spend a dollar until you have traction. When free tiers feel limiting: Total: ~$7-8/month. This is what I'd recommend for most solo founders who are comfortable with a terminal. You get a real server, a real database, and PaaS-like deploys, all for less than a Netflix subscription. 1. Starting with Kubernetes. You have one service and zero users. You don't need container orchestration. You need a VPS and systemd. K8s is for teams running dozens of services at scale. You're not there yet. You may never be. 2. Using a microservices architecture. Build a monolith. Split it later if you need to. Every startup that succeeded started as a monolith. Most of them still are. 3. Paying for managed services before you need them. A managed database at $50/month makes sense when you have paying customers. Before that, Postgres on your VPS is fine. 4. Not setting up backups. This isn't a "scale" concern. Back up your database from day one. A cron job that dumps Postgres to R2/S3 once a day takes 10 minutes to set up and will save your project when (not if) something goes wrong. If you're using a managed database, make sure automated backups are actually enabled. 5. Choosing tech you don't know because it's "better". The best technology is the one you can ship with today. If you know Python, build it in Python. If you know JavaScript, use Node. The language and framework matter far less than actually launching. Here's a rough guide for when to start spending real money: The pattern: start free, pay when it hurts, and always know what you're paying for and why. Nobody ever lost a startup because they used Hetzner instead of AWS. Plenty of startups died because the founder spent three weeks configuring Terraform instead of talking to users. Pick a stack from the tables above, set it up this weekend, and ship something. You can always change things later. You can't get back the weeks you spent comparing options instead of building. What does your stack look like? Did I miss a service you swear by? Drop it in the comments. I'll update this post with good suggestions. If you're building with Go, I wrote a book that covers backend architecture, deployment patterns, and production-ready code. The stuff you need after the infrastructure is sorted. Templates let you quickly answer FAQs or store snippets for re-use. as well , this person and/or - My project: Hermes IDE | GitHub

- My GitHub: gabrielanhaia - Spend as close to $0 as possible. Every dollar spent before you have users is a dollar wasted.- Ship fast. Pick boring tools you already know.- Stay portable. Don't lock yourself into a vendor you can't leave. - DNS. Fast, reliable, globally distributed. Point your domain here.- CDN. Your static assets get cached on 300+ edge servers worldwide. Free.- DDoS protection. Basic but real. Free.- SSL/TLS. Free HTTPS certificates, auto-renewed. No more Let's Encrypt cron jobs.- Page Rules / Redirects. Basic traffic routing for free. - Espanol -- coming soon- Portugues -- coming soon