Solo Founder Tech Stack: What I'd Actually Pay For Again After Three Products

Three micro SaaS products over four years produced three genuinely different tech stacks, not because of shifting trends, but because each product's actual constraints — team size (one), budget (small), and how much time could go toward infrastructure instead of the product itself — pushed toward different tools each time. This isn't a "best tools of the year" list; it's an honest accounting of what got renewed without a second thought and what got cancelled within a month of the free trial ending.

Hosting: the one category where the answer changed each time, for real reasons

Product one ran on a single small VPS, managed entirely by hand — cheap, and it meant every deploy, every security patch, and every scaling decision was manual work competing directly with time that could have gone into the actual product. Product two moved to a managed platform (Laravel Forge plus a standard cloud VPS), which cost more monthly and paid for itself the first time a dependency needed an urgent security patch and it took ten minutes instead of an afternoon. Product three, aimed at a much smaller expected user base from the start, went fully serverless on a platform-as-a-service host, trading some cost efficiency at scale for near-zero ongoing maintenance — the right call specifically because product three's realistic growth ceiling was known to be modest from the outset, and paying a small premium for zero operational overhead was worth more than the marginal cost savings of self-managing infrastructure for a product that was never going to need to scale much regardless.

The lesson that generalizes: hosting choice should follow the product's actual expected scale and how much operational time you can realistically spend, not a general "best practice" recommendation that assumes a team large enough to have someone dedicated to infrastructure. A solo founder's most valuable resource is usually time, not a marginal monthly cost difference between hosting tiers.

Billing: paid for once, kept every time since

All three products used a hosted billing provider rather than building subscription logic from scratch, and this is the one category with zero regret across all three — a full breakdown of the specific trade-offs between providers is covered separately in Stripe vs Paddle vs LemonSqueezy, but the general point holds regardless of which specific provider: subscription billing, tax handling, and dunning logic for failed payments are genuinely hard to get right, and paying a percentage of revenue for a provider that's already solved it is one of the clearest cases across this entire stack where building it yourself would have been a bad use of time, not a badge of independence.

Error tracking: cancelled once, immediately regretted, resubscribed within a week

Product two's first few months ran without dedicated error tracking, relying on manually checking server logs — which worked until it didn't. A customer reported a checkout flow silently failing for a specific payment method, and reconstructing what had actually gone wrong from raw logs took the better part of an afternoon, information that a proper error tracker would have surfaced with full context in under a minute. Sentry (or an equivalent) has stayed subscribed on every product since specifically because of this one incident — it's a genuinely small monthly cost relative to how much time it saves the one time something breaks in a way that isn't immediately obvious from a user report alone, which is exactly when it matters most.

Customer support tooling: the one downgrade that actually stuck

Product one used a full-featured helpdesk platform from day one, priced for a team, with features — shared inboxes, complex routing rules, an internal knowledge base editor — that a single founder handling maybe fifteen support emails a week never touched. Product two and three both moved to a shared inbox tool costing a fraction of the price, and the downgrade in capability was never actually felt in practice, because the unused features were genuinely unused, not quietly missed. This is worth naming honestly: not every "best practice" tool recommendation scales down correctly to a team of one, and a lot of SaaS tooling pricing is built around team-based value that doesn't materialize for a solo operation, regardless of how good the tool objectively is for a larger team.

Analytics: three different tools, and the real reason none of them fully satisfied

Analytics was the one category tried three separate ways across three products — a full-featured product analytics suite, a privacy-focused simple pageview tracker, and eventually a combination of the two — without ever landing on something that felt fully right. The full-featured suite provided genuinely useful funnel and cohort data and cost meaningfully more than the other two categories in this post combined, at a price that was hard to justify against the actual size of the user base being analyzed. The simple tracker was cheap and honest about being limited, answering "how many people visited" well and "why did they leave" not at all. The eventual combination — simple tracking for baseline traffic, plus manually instrumented events for the handful of specific actions that actually mattered for the business (signup completed, trial converted, subscription cancelled) — ended up being the most honest answer: most analytics questions a solo founder actually needs answered are a short, specific list, and a general-purpose analytics suite's broader feature set mostly goes unused relative to its price, the same pattern that showed up in customer support tooling above.

What never made it past a free trial

• A dedicated project management tool — a single-founder product with no team to coordinate doesn't need Kanban boards or sprint planning; a plain text file did the same job for free.
• An A/B testing platform — genuinely useful at scale, and a product with a few hundred monthly signups doesn't generate statistically meaningful results fast enough to justify the subscription cost relative to just making a considered decision and moving on.
• A dedicated uptime-monitoring service beyond a free tier — the free tiers of several providers covered the actual need (get notified if the site goes down) completely; the paid tiers' additional features (multi-region checks, detailed historical uptime reports) never came up as something actually needed.

The pattern across all three products

Looking at what survived versus what got cancelled across all three stacks, the actual dividing line wasn't price or feature count — it was whether a tool solved a problem that would otherwise cost real, unpredictable time when it eventually went wrong (billing, error tracking) versus a tool that solved a problem manageable well enough with a free or much cheaper alternative for a team of exactly one person (project management, most of a full-featured analytics suite, a full helpdesk platform). The former category is worth paying for without much second-guessing. The latter is worth testing with genuine skepticism about whether the extra capability actually gets used, rather than defaulting to whatever tool a larger, better-funded company would reasonably choose.

What I'd tell someone starting their first micro SaaS today

• Pay for billing and error tracking from day one — both are the kind of thing that's cheap relative to the cost of the problem they prevent, and neither is worth building or going without, even in the earliest, most cost-conscious stage.
• Default to the cheapest tool that solves the actual problem for a team of one, and upgrade only once a specific, concretely-felt limitation shows up — not because a larger company's stack looks more legitimate or complete.
• Revisit the stack after each product, not just once — the right hosting and tooling choice depends on that specific product's realistic scale and constraints, not a fixed personal preference carried unchanged from the last one.

If you're still validating whether a specific idea is worth building this stack around at all, that decision comes before any of this — how to validate a micro SaaS idea before writing a single line of code covers that earlier step, and once you're past validation and into actually pricing the product built on this stack, pricing a micro SaaS product picks up directly from here.

The one category where paying more actually saved money overall

Transactional email — receipts, password resets, welcome messages — is a category where a cheap tier looked adequate on paper across all three products and quietly wasn't, in a way that only became visible once deliverability was actually measured rather than assumed. Product two ran on a budget email provider's lowest tier for its first several months, and a later audit found a meaningful share of transactional emails were landing in spam, silently, with no bounce or visible error suggesting a problem existed at all — a genuinely costly failure mode precisely because it produces no obvious symptom pointing back to its cause. Moving to a mid-tier plan on a provider with a stronger sending reputation and better deliverability tooling cost more monthly and resolved the problem completely, and in hindsight the cheap tier's real cost wasn't its price, it was the support tickets and quiet customer confusion caused by password reset emails nobody ever received.

What building in-house never once made sense for, across three tries

Every product included, at some point, a moment of considering whether a specific paid tool could be replaced with something built in-house to save the monthly fee — and across three products and roughly a dozen serious instances of this consideration, exactly zero of them turned out to be a good trade once actually weighed honestly against the real cost of building and maintaining the replacement. The pattern each time was the same: the paid tool's fee looked expensive in isolation, and the actual engineering time required to build even a rough equivalent, plus the ongoing maintenance burden that never fully goes away once it's built, cost meaningfully more than continuing to pay for something a dedicated team already maintains full-time. This isn't a universal rule — at a large enough scale, building specific pieces in-house genuinely can make sense — but at the scale of a single-founder product with a few hundred to a few thousand users, it essentially never did, in this direct experience across three separate attempts to talk myself into it.