4 posts tagged with "Startup"

Meta Description: A real-world migration from DigitalOcean to Hetzner cut monthly costs from $1,432 to $233 — with zero downtime. Here's the playbook and what every startup should know.

The Cloud Pricing Trap No One Talks About​

If you're running production workloads on DigitalOcean, AWS, or any major cloud provider, you might be overpaying by thousands of dollars a month — and not even realize it.

That's exactly what happened to Isa Yeter, a developer running a full production stack on DigitalOcean. His bill: $1,432/month for a single droplet. After migrating to a Hetzner dedicated server, he pays $233/month — saving $14,388 per year. And the new hardware is more powerful in every dimension.

This isn't a sponsored post. It's a pattern every bootstrapped founder and cost-conscious engineering team should understand.

The Numbers That Should Make You Rethink Your Cloud Bill​

Here's the side-by-side comparison:

84% cost reduction. Better hardware. This isn't a subtle optimization — it's a fundamental pricing gap.

Why Cloud Providers Charge So Much More​

Cloud platforms like DigitalOcean, AWS, and GCP charge a premium for:

• Elasticity — Spin up, scale down, pay per hour. Great for variable workloads.
• Managed services — Databases, Kubernetes, object storage with zero ops overhead.
• Global distribution — Deploy to 15+ regions instantly.
• Ecosystem integrations — Monitoring, IAM, networking all wired together.

But here's the thing: most startups don't use most of these features. If you're running a steady-state production server that stays on 24/7, you're paying for elasticity you never use. If your database is self-hosted MySQL on the same box, you're not using managed services. If all your users are in one region, global distribution doesn't matter.

For steady-state workloads, dedicated servers from providers like Hetzner deliver significantly better price-to-performance. You're paying for hardware, not abstraction layers.

The Migration Playbook: Zero Downtime in 6 Phases​

The original migration (documented in detail on Isa's blog) moved a complex production stack — 30 MySQL databases (248 GB), 34 Nginx sites, GitLab EE, Neo4j, and live mobile app traffic — with zero user-facing downtime. Here's how:

Phase 1: Full Stack Mirror​

Replicate every service on the new server with identical configuration — Nginx compiled from source with the same flags, PHP with matching .ini files, MySQL 8.0, Neo4j, GitLab EE, Node.js, Supervisor, and Gearman. SSL certs were rsync'd from the old server and force-renewed after cutover.

Phase 2: File Sync with rsync​

65 GB of web files (1.5 million files) cloned with rsync --checksum for integrity. A final incremental sync right before cutover caught any changes.

Phase 3: MySQL Replication (The Critical Piece)​

Instead of dump-and-restore (which would mean downtime), they set up live master-to-slave replication. mydumper handled the initial bulk export with 32 threads, turning what would have been days of mysqldump into hours. The new server became a read replica, staying in real-time sync until the cutover moment.

Phase 4: DNS TTL Reduction​

All A record TTLs were dropped from 3600 to 300 seconds via the DigitalOcean API — without touching MX/TXT records (changing mail TTLs causes deliverability issues). After one hour, DNS changes would propagate in under 5 minutes.

Phase 5: Reverse Proxy Safety Net​

A Python script converted all 34 Nginx configs on the old server into reverse proxy configs pointing to the new server. During DNS propagation, any request hitting the old IP was silently forwarded to the new server. No user ever saw a disruption.

Phase 6: DNS Cutover​

One script hit the DigitalOcean API and flipped all A records in ~10 seconds. The old server stayed as a cold standby for one week, then was decommissioned.

The Tricky Problems You'll Hit (And How to Solve Them)​

Migrations never go perfectly. Here are the real problems encountered:

MySQL 5.7 → 8.0 schema mismatch. The mysql.user table had 45 columns instead of 51, breaking authentication. Fix: mysqld --upgrade=FORCE. The sys database also imported as tables instead of views — dropping it and re-running the upgrade resolved it.

SUPER privilege bypasses read_only. All 24 app users had SUPER privilege, which silently bypasses read_only = 1 on the replica. This meant writes were going through when they shouldn't. Revoking SUPER from all users fixed it.

Replication duplicate key errors. Because the dump was taken in two passes, binlog replay tried to insert rows that already existed. Fix: SET GLOBAL slave_exec_mode = 'IDEMPOTENT' to silently skip conflicts.

GitLab webhooks still pointed to old IP. After migration, many project webhooks were hardcoded to the old server. A bulk update script via the GitLab API fixed them all.

When Should You Actually Migrate?​

This approach isn't for everyone. Here's when it makes sense:

Migrate if:

• Your workloads are steady-state (always-on, predictable resource needs)
• You're self-hosting databases and services (not using managed offerings)
• Your users are concentrated in one or two regions
• Your monthly cloud bill exceeds $200-300
• You have DevOps capacity to manage a bare-metal server

Stay on cloud if:

• You need auto-scaling for variable traffic
• You rely heavily on managed services (RDS, CloudFront, etc.)
• You need multi-region deployment
• Your team has zero ops bandwidth
• Your infrastructure changes frequently (infra-as-code, ephemeral environments)

The Startup Math That Matters​

Let's make it concrete. If you're a bootstrapped startup burning $1,500/month on cloud:

• Annual cloud cost: $18,000
• Hetzner equivalent: ~$2,800
• Annual savings: $15,200
• That's 1-2 extra months of runway just from switching hosting

For funded startups, this is a rounding error. For bootstrapped founders, it's the difference between hiring a contractor or not. Between extending runway by a quarter or not. Between profitability and not.

Practical Steps to Evaluate Your Own Migration​

1. Audit your current bill. Break down exactly what you're paying for. Identify steady-state vs. elastic resources.

2. Check Hetzner's dedicated server pricing. Compare equivalent specs to your current setup. The gap might surprise you.

3. List your cloud dependencies. Managed databases, load balancers, object storage — anything that would need a self-hosted replacement.

4. Estimate migration effort. A simple LAMP stack? A weekend. A microservices architecture with managed everything? Weeks.

5. Calculate the ROI. If the migration takes 40 hours and saves $1,000/month, it pays for itself in one month of a senior dev's time.

6. Use the open-source playbook. Isa published all migration scripts on GitHub with DRY_RUN mode so you can preview changes safely.

Conclusion​

Three takeaways:

1. Cloud pricing includes a massive "convenience tax" — if you're not using the convenience features, you're just paying the tax.
2. Zero-downtime migration is achievable — MySQL replication + reverse proxy + scripted DNS is a proven pattern.
3. For bootstrapped startups, infrastructure costs are a lever — cutting 84% from your hosting bill is the easiest runway extension you'll ever get.

Before your next cloud renewal, do the math. The savings might fund your next hire.

FAQ​

Q: Is Hetzner reliable enough for production workloads? A: Yes. Hetzner has been operating since 1997, runs multiple data centers in Germany, Finland, and the US, and is widely used in production across Europe. They offer enterprise-grade SLAs on dedicated servers.

Q: What about managed services like RDS or CloudFront? A: You'd need to self-host equivalents (MySQL/PostgreSQL directly, MinIO for S3-compatible storage, etc.). This adds ops overhead — factor that into your cost calculation. The break-even point depends on your team's capacity.

Q: How much downtime should I expect during migration? A: With the replication + reverse proxy approach described here, zero downtime is achievable. The critical path is: set up replication → convert old server to proxy → flip DNS. Users never see a disruption.

Q: Does this approach work for AWS/GCP too, not just DigitalOcean? A: Absolutely. The migration pattern (replication, proxy, DNS cutover) is cloud-agnostic. The savings will vary based on your current provider and instance types, but the gap between cloud pricing and dedicated servers is consistent across all major providers.

Arkin is a startup founder and developer building AI-powered products. He writes about infrastructure cost optimization, developer tooling, and the practical side of running production systems on a budget.

Meta Description: Anthropic's Claude Design turns conversations into polished designs, prototypes, and presentations. Here's how it works and what it means for your team.

The Design Tool Gap Nobody Talks About​

Every product team knows the bottleneck. You've got an idea, but turning it into something visual — a wireframe, a deck, a prototype — means waiting on a designer or wrestling with Figma for hours. For founders and PMs without a design background, the gap between "idea in my head" and "thing I can show people" is massive.

Anthropic just dropped something that shrinks that gap to zero.

On April 18, 2026, Anthropic launched Claude Design — a new product from their Labs division that lets you collaborate with Claude to create polished visual work. Think designs, prototypes, slides, one-pagers, and more, all generated through conversation and refined through natural interaction.

It's powered by Claude Opus 4.7, their most capable vision model, and it's available now for Claude Pro, Max, Team, and Enterprise subscribers.

What Claude Design Actually Does​

At its core, Claude Design follows a natural creative flow:

1. Describe what you need — Claude builds a first version from a text prompt
2. Refine through conversation — Use inline comments, direct edits, or custom sliders to tweak the output
3. Share and collaborate — Organization-scoped sharing with view and edit permissions
4. Export anywhere — Canva, PDF, PPTX, standalone HTML, or hand off directly to Claude Code for implementation

Here's what makes it different from other AI design tools:

Your brand, built in. During onboarding, Claude reads your codebase and design files to build a design system for your team. Every project after that uses your colors, typography, and components automatically. No more "make it look like our brand" prompts.

Import from anywhere. Start from text, upload DOCX/PPTX/XLSX files, point Claude at your codebase, or use the web capture tool to grab elements from your live site.

Fine-grained controls. Comment on specific elements inline, edit text directly, or use adjustment knobs to tweak spacing, color, and layout in real-time. Then ask Claude to propagate changes across the full design.

Handoff to Claude Code. When a design is ready to build, Claude packages everything into a handoff bundle that goes straight to Claude Code with a single instruction. This is the part that should excite every engineering team — the bridge from design to code just got a lot shorter.

Who's Using It and How​

Teams are already using Claude Design for some compelling use cases:

• Realistic prototypes — Designers turn static mockups into shareable interactive prototypes without code review or PRs
• Product wireframes — PMs sketch feature flows and hand off to Claude Code for implementation
• Design explorations — Designers rapidly explore a wide range of creative directions instead of being limited to 2-3 options
• Pitch decks — Founders go from rough outline to complete, on-brand deck in minutes, then export as PPTX or send to Canva
• Marketing collateral — Landing pages, social assets, and campaign visuals, with designers looping in for polish
• Frontier design — Code-powered prototypes with voice, video, shaders, 3D, and built-in AI

The Brilliant team reported that their most complex pages — which took 20+ prompts in other tools — required only 2 prompts in Claude Design. That's a 10x reduction in iteration cycles.

Why This Matters for Startups and Product Teams​

This isn't just another design tool. It's a fundamental shift in how teams communicate visually.

For small teams without dedicated designers, Claude Design removes the biggest barrier to producing professional-looking visual work. You don't need to know Figma. You don't need to understand grid systems or color theory. You describe what you want and iterate from there.

For teams with designers, this is about exploration at scale. The uncomfortable truth of product design is that even experienced designers ration exploration — there's rarely time to prototype a dozen directions. Claude Design makes it trivial to explore widely, then narrow down to the best option.

For engineering teams, the Claude Code handoff is the killer feature. The gap between "design is done" and "implementation starts" has been a persistent source of friction. Packaging design intent into a handoff bundle that an AI coding agent can execute on directly? That's a workflow change.

The Bigger Picture: AI Tools Expanding Beyond Text and Code​

Claude Design signals something bigger than one product launch. The AI tooling ecosystem has been dominated by text generation and code assistance. Visual design has been the next frontier, and Anthropic is making a serious play for it.

Consider the trajectory:

• 2023-2024: AI mastered text generation and code assistance
• 2025: AI agents started handling multi-step workflows
• 2026: AI expands into creative visual work — design, prototyping, presentations

For founders building AI-powered products, this is a signal: the competitive moat isn't in "AI that generates text." It's in AI that understands context (your brand, your design system, your codebase) and produces output that fits seamlessly into existing workflows.

The Anthropic-Canva integration is particularly telling. Canva's quote in the announcement — "bringing Canva to wherever ideas begin" — suggests these tools are converging. AI generates the first draft, traditional design tools refine it, and the handoff between them is seamless.

Getting Started​

Claude Design is available now for Claude Pro, Max, Team, and Enterprise subscribers. Access is included with your plan and uses your subscription limits, with the option to continue beyond those limits by enabling extra usage.

For Enterprise organizations, Claude Design is off by default — admins can enable it in Organization settings.

Start designing at claude.ai/design.

Over the coming weeks, Anthropic plans to make it easier to build integrations with Claude Design, connecting it to more of the tools your team already uses.

FAQ​

Q: Is Claude Design free to use? A: Claude Design is included with Claude Pro, Max, Team, and Enterprise subscriptions. It uses your existing subscription limits, with the option to enable extra usage if you exceed them.

Q: Can Claude Design replace Figma or professional design tools? A: Not entirely. Claude Design excels at rapid prototyping, exploration, and first drafts. Professional designers will still need dedicated tools for pixel-perfect production work. Think of it as a powerful starting point that handles 80% of the work, with handoff to professional tools for the final 20%.

Q: How does the Claude Code handoff work? A: When a design is ready for implementation, Claude packages everything into a handoff bundle — including design intent, specifications, and assets. This bundle can be passed to Claude Code with a single instruction, significantly reducing the design-to-code gap.

Q: Does Claude Design learn my brand's design system? A: Yes. During onboarding, Claude reads your codebase and design files to build a design system. Every subsequent project automatically uses your colors, typography, and components. You can refine the system over time, and teams can maintain multiple design systems.

Q: What file formats can I export to? A: Claude Design supports export to Canva, PDF, PPTX, standalone HTML files, and internal organizational URLs. You can also save designs as folders for team access.

Meta Description: Most engineering teams don't know their true ROI. Here's why measuring software economics matters — and why it's harder than it looks.**

The $60,000 Question​

Here's a scenario that plays out in engineering organizations every day: Your team spends three weeks building a feature that serves 2% of your users. With a typical all-in engineering cost of €100,000 per year, that's roughly €60,000 of investment for a minority of your user base.

Was it worth it?

If you're like most engineering leaders, you don't know. You have a gut feeling. You have some usage metrics. You have a vague sense that "the sales team said they needed this." But you don't have a number — or even a method for generating one.

This is the core thesis of the discussion around software team economics: Most engineering organizations are flying blind when it comes to understanding the financial impact of their work.

The Optimization Trap​

The seductive argument goes like this: If every feature decision were made with clear ROI calculations, organizations would make better decisions. A €60,000 feature for 2% of users is easy to evaluate against a €60,000 feature for 20% of users. Armed with this data, engineering leaders could reallocate resources to high-impact work and eliminate waste.

There's truth to this. In the zero-interest-rate era, companies hired aggressively, shipped aggressively, and worried about efficiency later. That era is over. Companies that can't connect engineering output to business outcomes are in trouble.

But there's a trap here.

What Gets Measured Gets Managed (And Sometimes Broken)​

The first problem is attribution. Software doesn't exist in a vacuum. Your company ships 10 features in a quarter, revenue goes up $1M, and you land a new enterprise contract that uses all of them. How much of that revenue belongs to Feature #7?

Every team will attribute the entire win to themselves. The alternative — revenue that disappears without explanation — is politically unacceptable. So you end up with sum-of-parts greater than the whole, and metrics that no one trusts.

The second problem is the measurement burden. If every feature needs a dollar value attached, who does the calculation? Product managers become analysts. Engineers spend time setting up measurement baselines for work that hasn't shipped yet. The meta-work of justifying work starts to rival the work itself.

The third problem is the most insidious: innovation doesn't have a clear ROI when you start.

The Innovation Paradox​

WhatsApp was built by 30 engineers serving 1 billion users. But WhatsApp in 2010 didn't have 1 billion users. It had a few thousand. At what point in that journey did the feature work of those 30 engineers become "worth it"?

If you measured strictly by short-term ROI at every step, you might have killed the project six months in. The features that matter now — end-to-end encryption, cross-platform sync, minimal data collection — were long-term bets that looked like waste when they were built.

This is the paradox: The most valuable engineering work often looks like waste until it becomes indispensable.

The Missing Layer: Baseline Before Optimization​

There's a sensible middle ground that gets lost in the "bean counters vs. pampered artists" framing.

The problem isn't measurement itself. The problem is measuring without baselines. Consider a DevOps engineer who automates a manual task that cost every developer 2 hours per week. That's 80 hours saved per week for a 40-person team. But what do those engineers do with the extra time?

If they use it to ship more features, the ROI is clear. If they take longer lunches, the ROI is zero. The difference isn't about the automation — it's about whether the freed-up capacity has a place to go.

As one commenter put it: "Profile before you optimize and the return on investment calculates itself." Most organizations skip the profiling step. They don't measure what happens now, so they can't measure what happens after.

The 3-5x Rule​

There's a rule of thumb that circulates in engineering leadership: A feature needs a 3-5x return on investment to be worth building. The math is simple: Building a feature costs €60,000. If it generates less than €180,000 of value, you're losing money.

But here's what this rule misses:

1. Lifetime value vs. first-year value. A feature might cost €60,000 to build but generate €20,000 annually for five years. That's a 4x return, but if you measure strictly in year one, it looks like a failure.

2. Capability building, not just features. Some work doesn't generate revenue directly but enables revenue-generating work. Infrastructure platforms, developer tooling, security hardening — these are investments in capability.

3. Option value. A feature for 2% of users might unlock an adjacent market segment. That 2% might be a beachhead for a much larger opportunity.

The Role of AI in All This​

The original discussion that sparked this thread included a provocative claim: AI agents can replace much of what engineering teams do today, at lower cost, with different trade-offs.

The counter-arguments were equally strong: AI-generated code becomes unmanageable technical debt. Agents can't reason through unfamiliar systems at scale. You still need a human to fire and sue.

But the deeper question isn't "Will AI replace engineers?" It's: "How does AI change the economics of software production?"

If AI can ship a 95% clone of Slack in two weeks (as the original article claimed), what does that mean for teams spending years building products from scratch? The value of engineering has always been more than lines of code per hour. But as the cost of code drops, the value of everything else — product judgment, user empathy, strategic thinking — rises.

What Actually Matters​

Here's what the most productive engineering teams actually do:

They focus on problems they care about. One commenter put it best: "The only thing that matters is whether the people on the team care deeply about the product." Teams that don't care have a productivity ceiling no amount of process can fix.

They build in increments. Shipping 10 major features in a quarter makes attribution impossible. Shipping one feature every week makes it clear what landed and what didn't.

They understand the business. Engineers who know how their company makes money — not just "we sell software" but "we sell to HR directors at 500-person companies with specific compliance needs" — make better decisions.

They accept uncertainty. Not every feature will succeed. Not every infrastructure investment will pay off. The goal isn't to eliminate uncertainty — it's to take calculated bets and learn from the results.

A Framework, Not a Formula​

Here's a practical framework for thinking about engineering economics, short of full financial modeling:

1. Measure the things you can. If you're building something, know the baseline. How long does this take now? How many users touch this? What's the current failure rate?

2. Know your multipliers. A €60,000 feature for 2% of users might be worth it if that 2% represents your highest-value customers. A €60,000 feature for 50% of users might be a waste if those users don't pay.

3. Distinguish between capability and output. Infrastructure that makes everyone 10% faster is different from a feature that drives direct revenue. Measure them differently.

4. Track learning, not just outcomes. Did a feature fail because the market wasn't there, or because the execution was wrong? That's valuable data either way.

5. Keep the meta-work minimal. If calculating ROI takes longer than building the feature, you're optimizing the wrong thing.

The Bottom Line​

Engineering organizations are flying blind — but maybe that's okay up to a point.

The extreme of no measurement is waste: teams working on things that don't matter for users who don't care, with no accountability for results.

The extreme of hyper-measurement is paralysis: every decision requires a business case, every feature needs a revenue forecast, every engineer becomes a part-time analyst.

The middle ground is pragmatic: Measure what you can, accept what you can't, focus on problems worth caring about, and trust that the outcomes will follow.

The €60,000 question isn't whether that feature for 2% of users was worth it. The question is: Did you learn something that makes the next decision better?

FAQ​

Q: How do I measure ROI for engineering work? A: Start with baselines. Measure before you change. For features, track adoption, retention, and revenue impact. For infrastructure, measure time saved, error reduction, or developer satisfaction. But accept that some value is unmeasurable — like team morale or strategic option value.

Q: What's the 3-5x rule for engineering ROI? A: It's a heuristic that a feature should generate 3-5x its cost to be worth building. If building costs €60,000, the feature should generate €180,000-€300,000 of value. But this rule misses long-term value, capability building, and option value — so use it as a filter, not a law.

Q: How does AI change software team economics? A: AI lowers the cost of code generation, which changes the relative value of engineering skills. As code becomes cheaper, product judgment, user empathy, and strategic thinking become more valuable. Teams should focus on what AI can't do: understanding problems deeply, making judgment calls, and building relationships with users.

Q: Should every feature need a business case? A: No. Hyper-measurement slows down innovation. A better approach: quick business cases for major bets, lightweight ROI tracking for routine features, and space for experimental work where the value is learning, not revenue.

About the Author: Arkin is a software engineer and startup founder building Orbits Studio. He writes about engineering economics, startup strategy, and the intersection of technology and business. Find him at arkin-dev.com.

Meta Description: A founder runs multiple profitable SaaS companies spending just $20/month on infrastructure. Here's the lean tech stack playbook — single VPS, Go, SQLite, and local AI.

The Bootstrapper's Dilemma​

Here's a story that sounds familiar: a founder walks into a pitch meeting. They have real users, real MRR, real product traction. The VC's response? "What do you even need funding for?"

That's exactly what happened to Steve Hanov — the creator of websequencediagrams.com and several niche SaaS products. His costs are so low that VCs can't figure out what to fund. And that's the point.

In 2026, the default startup playbook says: spin up AWS, provision EKS clusters, configure RDS instances, set up NAT Gateways, and accidentally burn $300/month before your first user even loads the landing page. The lean playbook says: rent a $5 VPS, compile a static binary, ship it.

One approach buys you a maze of managed services. The other buys you infinite runway.

The $20/Month Stack, Deconstructed​

Hanov's approach isn't about being cheap for its own sake. It's about keeping the architecture so simple that you spend your time solving user problems instead of debugging infrastructure. Here's what the stack looks like:

One Server, One Binary​

No Kubernetes. No container orchestration. No microservices talking to microservices. A single VPS from Linode or DigitalOcean at $5-10/month. 1GB of RAM with a swapfile if needed.

The backend? Written in Go, compiled into a single statically-linked binary on a laptop, SCP'd to the server, and run. No dependency hell, no virtual environments, no pip install nightmares. The deployment process is literally:

GOOS=linux go build -o app .
scp app root@yourserver:/opt/app/
ssh root@yourserver 'systemctl restart app'

A basic Go HTTP server handles tens of thousands of requests per second on potato hardware. No framework required.

SQLite Over Postgres​

This is the part that makes most developers flinch. SQLite — in production? For a real SaaS?

Yes. And here's why it works:

• A local .db file communicating over the C-interface is orders of magnitude faster than making a TCP network hop to a remote Postgres server
• Enable Write-Ahead Logging (WAL) with two pragmas, and readers don't block writers, writers don't block readers
• On an NVMe drive, a single SQLite file handles thousands of concurrent users

PRAGMA journal_mode=WAL;
PRAGMA synchronous=NORMAL;

The enterprise mindset says you need an out-of-process database server. The lean mindset says: your database is a file on a disk, and that's a feature, not a bug. No connection pooling, no network latency, no separate server to manage and monitor.

Local AI Instead of API Bills​

This is where it gets really interesting. Hanov runs batch AI workloads — deep stock market research, summarizing thousands of quarterly reports — on a used RTX 3090 bought from Facebook Marketplace for $900. No OpenAI API bills. No rate limits. No "logic bug in my prompt loop that cost me $200 before I noticed."

The upgrade path is pragmatic:

1. Start with Ollama — one command to spin up any model, perfect for iterating on prompts
2. Move to vLLM for production — PagedAttention makes it dramatically faster for concurrent batch requests. Send 16 async requests and they all finish in roughly the time of one
3. Transformer Lab for fine-tuning — when you need to customize models on local hardware

For frontier model tasks that can't run locally (user-facing chat, complex reasoning), he uses OpenRouter as a single API gateway to every major model. One integration, automatic fallback routing — if Anthropic goes down, it falls back to OpenAI. Users never see errors.

The Copilot Hack​

Here's a detail that resonates with any developer watching their AI tooling costs: Hanov uses a standard GitHub Copilot subscription (~$10-20/month) plugged into vanilla VS Code. Not Cursor. Not Windsurf. Not a $200/month API habit.

The trick: Copilot charges per request, not per token. So a brutally detailed prompt that tells the agent to "keep going until all errors are fixed" while it spends 30 minutes chewing through an entire codebase still costs roughly $0.04. Write good prompts with strict success criteria, hit enter, and let Microsoft subsidize your compute.

Why This Matters in 2026​

The timing of this playbook matters. Three trends are converging:

AI has collapsed the cost of building. A solo founder with good prompting skills and a $5 server can now build what took a 5-person team two years ago. The bottleneck isn't engineering capacity — it's finding the right problem.

VCs are asking harder questions about burn. The zero-interest-rate era of "growth at all costs" is over. Investors want to see capital efficiency. A founder who can demonstrate $10K MRR on $20/month infrastructure has a fundamentally different conversation than one burning $50K/month on AWS.

Simple stacks survive longer. Every abstraction layer you add is a maintenance burden. Every managed service is a potential single point of failure and a definite line item. A single server with a single binary and a single database file is boring — and that's exactly why it works.

The Real Lesson: Constraints Create Focus​

Hanov's stack isn't just about saving money. It's about what happens when you remove infrastructure as a variable:

• You know exactly where your logs are — they're on the one server
• You know exactly why something crashed — it's the one binary
• You know exactly how to fix it — restart the one process
• You have infinite runway — $20/month means you can iterate for years

The traditional startup playbook optimizes for scale that hasn't arrived yet. The lean playbook optimizes for survival and learning. When you're pre-product-market-fit, survival and learning are the only metrics that matter.

You can always migrate to Kubernetes later, when you actually have the traffic that justifies it. But you can't undo the months of infrastructure complexity you built "just in case."

When Lean Stops Working​

To be fair — this approach has limits. The $20/month stack works beautifully up to a point. When you need:

• Multi-region redundancy for enterprise SLAs
• Complex relational queries across millions of rows
• Real-time collaboration features (CRDTs, WebSockets at scale)
• SOC 2 compliance and audit trails

...you'll eventually need to graduate beyond a single VPS and SQLite. But that's a good problem to have, and by the time you have it, you'll have the revenue to solve it properly.

The mistake is pre-optimizing for scale you haven't earned yet.

Conclusion​

Steve Hanov's $20/month stack is a reminder that the tech industry's default complexity is a choice, not a requirement. You can build real businesses — profitable ones — on simple, boring infrastructure.

A single VPS. A Go binary. SQLite with WAL. Local AI for batch work. OpenRouter for frontier models. Copilot for coding.

Total cost: less than a Spotify subscription.

The question isn't whether this stack can scale to millions of users. The question is: do you need to scale to millions of users before you've found ten who love your product?

Start lean. Graduate when the data tells you to. And enjoy the infinite runway.

FAQ​

Q: Can SQLite really handle a production SaaS with thousands of users? A: Yes, with WAL mode enabled. SQLite with Write-Ahead Logging allows concurrent reads and writes without blocking. On NVMe storage, it handles thousands of concurrent connections. It's used in production by companies like Turso and Fly.io for their own infrastructure.

Q: What's wrong with using AWS for a new startup? A: Nothing is wrong with AWS — but it encourages over-engineering from day one. Managed services, EKS clusters, and RDS instances add up fast ($300+/month before your first user). A $5 VPS forces you to keep things simple and gives you the same runway as a $1M seed round with a high burn rate.

Q: How do you handle database backups with SQLite? A: SQLite backups are just file copies. You can use the .backup command for consistent snapshots, or simply copy the .db file during low-traffic periods. Combine with S3 or any object storage for offsite backups — still well under $20/month total.

Q: Is local AI really practical for production workloads? A: For batch processing — research, summarization, data extraction — absolutely. A used RTX 3090 ($900 one-time) running vLLM can process thousands of inference requests without per-token API costs. For real-time user-facing features, you'd still want a cloud API for latency reasons.

About the Author: Arkin is a software engineer and startup founder building Orbits Studio. He writes about lean engineering, indie hacking, and building products without the enterprise bloat. Find him at arkin-dev.com.