DEV Community: Ryan Dooley

How I'm Running a SaaS for (Almost) Free as a Solo Dev

Ryan Dooley — Thu, 20 Aug 2026 14:15:00 +0000

When I started building the infrastructure behind my templates, my only real goal was to find the cheapest possible way to host something. I wasn't trying to build the ultimate cost-optimized stack. I just didn't want to pay $50/month for a side project that might not go anywhere. What I ended up with is a stack that costs me roughly $7-8/month all-in, and most of the individual pieces are free.

Here's what I'm actually using, and why.

Compute: Hetzner (almost), then Contabo

I originally planned to host on Hetzner's Cost-Optimized CX line, cheap ARM instances that are usually the go-to recommendation for budget VPS hosting. Except when I went to actually spin one up, the entire line was out of stock across every EU location. Their next tier up, the Regular Performance CPX line, had just gone through a 2026 price hike and was going to run me about $23/month for the smallest instance that could actually handle what I needed.

That felt like too much for a project still in "let's see if this works" mode, so I looked elsewhere and landed on Contabo: $5-7/month for 3-4 vCPUs and 8GB of RAM, which is a lot more headroom for a lot less money. It's not as polished as Hetzner, but for a solo project, the extra $15-18/month saved matters more than the extra polish.

Lesson: the "obvious" cheap host isn't always available or actually cheap by the time you need it. Have a backup in mind before you're mid-setup.

Database: self-hosted Postgres instead of a managed service

My first instinct was to use a managed Postgres provider, Neon specifically, since it has a generous free tier. But once I had the app and the database living in different regions, I was paying for that in latency, and the free tier ceiling was going to force a decision eventually anyway.

Instead, I just run Postgres in a Docker container on the same box as the app. Same server, no network hop, no extra bill. The tradeoff is real (I now own backups and upgrades myself), but for the traffic I'm dealing with right now, that's a fine trade.

Error tracking: Sentry's free tier

Sentry's free tier covers error tracking for a project at this scale without paying anything. I haven't needed to think about this one much, which is exactly what you want from a monitoring tool at this stage.

Analytics: PostHog, in cookieless mode

PostHog has a free tier that covers page views and event tracking, which is what I use for CTA clicks and basic funnel visibility. I run it in cookieless mode specifically to avoid needing an EU consent banner. The tradeoff is I lose cross-day and return-visit tracking (I can't tell if someone came back three days later), but at my current traffic, that's a diagnostic I don't need yet. If sales volume grows to the point where I need deeper funnel analysis, I'll revisit it. Until then, it's not worth the UX cost of a cookie banner.

This is where a lot of solo devs overspend early. Tools like Datadog or Mixpanel are excellent, but they're built for teams that need deep, real-time observability across complex systems. At the scale of "one person, one server, a few hundred visitors a day," you don't need that yet, and paying for it before you need it is money that could go toward literally anything else.

Email: Resend

Resend handles both transactional email (verification links, etc.) and newsletter sends via Audiences. The free tier is generous enough that I haven't hit a wall with it.

CI/CD: GitHub Actions

This one almost didn't make the list because it felt too obvious to mention: most people are probably already using GitHub Actions for CI. But "obvious" and "free" aren't mutually exclusive, and it's worth stating plainly: I'm not paying for CI at all. GitHub Actions' free tier covers everything I need for running tests and deployments on a project this size.

The running total

Compute (Contabo): ~$6/month
Database: $0 (self-hosted on the same box)
Error tracking (Sentry): $0
Analytics (PostHog): $0
Email (Resend): $0
CI/CD (GitHub Actions): $0
Domain: a few dollars a month amortized

All told, I'm running this for somewhere around $7-8/month, and almost all of that is the server itself. Every other piece of the stack is a free tier that hasn't needed to become a paid tier yet.

The actual point

None of these are exotic choices, and this doesn't count whatever tools you're using to actually write the code. That's a separate conversation.

The actual point

The point isn't "use these exact tools." It's that as a solo dev, your default should be to find the free tier first and only pay when you've actually outgrown it, not when you assume you will. I got here mostly by accident, because Hetzner ran out of servers and I had to make a decision fast. But it forced me to actually evaluate what I needed versus what I assumed I needed, and most of what I assumed I needed turned out to be free.

Where this shows up in the templates

These aren't just my personal choices in isolation. They're the same defaults baked into the templates themselves. The Rails and Go templates ship ready to talk to Sentry, PostHog, and Resend out of the box, and the deployment setup assumes a cheap VPS rather than a pricier managed platform. If you're starting a new SaaS project and don't want to spend a weekend wiring up error tracking and analytics from scratch, that's exactly the gap the templates fill. That said, everything is swappable. The templates aren't locked into these specific tools, just set up to make this particular cheap stack easy to start with.

What are you using?

I'd genuinely like to know what other solo devs are running for a cheap stack. If you're using something different for compute, error tracking, analytics, or email, especially if it's a tool I haven't mentioned here, I'd like to hear about it. If there's a common alternative enough people are using, it's worth me looking into supporting it more directly in the templates.

Rails vs Go for SaaS: What Convention Gets You (and What It Costs You)

Ryan Dooley — Tue, 11 Aug 2026 15:06:49 +0000

I recently built two SaaS starter templates, one in Rails, one in Go. Same feature set, same goal, two very different experiences getting there. This isn't a "Rails vs Go, which is better" hot take. It's a practical rundown of where each stack's philosophy showed up in the code, and what it cost or saved me building a real backend with each.

Quick summary: Rails wins on batteries-included tooling (auth, admin panels) and removes decision fatigue (one ORM, one obvious answer). Go wins on resource footprint, compile-time safety, and deployment simplicity, and lets you skip infrastructure you don't need yet, like a job queue for one background email. Details below.

Rails vs Go for authentication and admin panels

Auth. Devise gave me registration, login, session handling, password reset, and account confirmation almost for free. On the Go side, there's no equivalent default: I ended up rolling my own JWT exchange, issuing tokens, handling expiry, thinking through revocation. None of it was hard, exactly, but it was all surface area I had to design, implement, and test myself instead of configuring.

Admin. ActiveAdmin (or RailsAdmin) gets you a working, auth-gated CRUD interface in minutes. Go has nothing comparable baked into the ecosystem. Want an admin panel? You're building one, or bolting on a separate tool.

In both cases the pattern is the same. Rails had already made an opinionated call, tested by thousands of production apps, and I just had to opt in.

Rails ORM vs Go: Active Record vs sqlc and the decision fatigue problem

The auth and admin gaps are really instances of a bigger thing. Rails is an MVC framework with a specific, narrow purpose, and its community has spent two decades converging on "the" way to do things. Go doesn't have that. It's used across CLIs, infra tooling, backend services, all sorts of shapes, so there's no single obvious answer to a lot of questions a Rails dev doesn't even think of as questions.

The clearest example: how do you talk to the database?

Rails: Active Record. That's it. That's the answer. Migrations, validations, associations, all designed to work together.
Go: open question. Do you reach for an ORM (GORM, ent) that's trying to approximate Active Record but isn't nearly as battle-tested in this pattern? Or do you go with something like sqlc, a completely different philosophy: write raw SQL, generate typed Go from it?

That's not a "Go is missing an ORM" problem. It's a "you now have to survey an ecosystem, pick a paradigm, and live with it" problem: a real cost, separate from any individual feature gap, and one Rails just doesn't impose on you.

Background jobs in Rails vs Go: Sidekiq/Solid Queue vs a goroutine

Here's where it flips, though. My registration flow needed to send a confirmation email. In Rails, that meant I needed a queueing system, full stop. Any background job in Rails means picking one: Sidekiq (+ Redis), Solid Queue (+ Postgres), something else. For a single "send this email" job, that's real infrastructure to stand up before you've shipped anything.

In Go, I spun up an additional goroutine. That's it. No new dependency, no new infra, nothing to configure. For a simple fire-and-forget case, it was the right amount of solution for the problem size.

To be fair to Rails here: a goroutine isn't a queue. It doesn't survive a process crash, it doesn't retry with backoff, and it doesn't give you a dashboard to see what's stuck or failed. If your job needs are more than "send one email and move on," anything with real failure modes, you'll eventually want the durability Solid Queue gives you out of the box. But for the simple case, Rails made me pay an infra decision I didn't need yet, and Go let me not pay it until I did.

Why choose Go over Rails: resource footprint, safety, and deployment

It would be easy to read all of the above as "Rails wins, Go just has less." That's not the full picture. Go has advantages that have nothing to do with what it's missing:

Resource footprint. My Go template runs comfortably on a fraction of the RAM the Rails template needs. That's not theoretical, it's the reason I sized my hosting the way I did. For a solo dev watching hosting costs, this is a real, measurable win.
Compile-time safety. Type errors, nil checks, interface mismatches: caught at build time. Rails' dynamic typing is flexible, but a typo'd method call surfaces at runtime, sometimes in production.
Deployment simplicity. A single static binary. No gem/bundler/version-manager juggling, no runtime dependency drift between your machine and the server.
Concurrency as a first-class primitive. Goroutines are cheap and built into the language, which is exactly what made the "just spin up a goroutine" queueing story possible in the first place. Ruby's threading is GIL-bound in MRI, so real concurrency usually means extra processes or infra.
Explicitness. No callback chains or metaprogramming to trace through to understand what a line of code actually does. Some people find Rails' implicit, convention-driven behavior harder to debug than Go's "what you see is what executes."

FAQ: Rails vs Go for a SaaS backend

Is Rails or Go better for a SaaS MVP? Rails typically gets you to a working MVP faster because auth, admin, and background jobs are already decided for you. Go takes longer to assemble but gives you a lighter, cheaper-to-run result once it's built.

Does Go have an equivalent to Devise for authentication? Not a direct one. There's no single dominant auth library in Go the way Devise dominates Rails, so most teams roll a custom solution (session-based or JWT) or assemble one from smaller packages.

Do I need Redis or Postgres for background jobs in Go? Not necessarily. For simple, non-durable background work (like sending a single email), a goroutine is often enough. You only need a persistent queue once you need retries, durability across restarts, or observability.

Is an ORM necessary in Go? No, it's a genuine choice. Some teams use a Rails-like ORM (GORM, ent); others prefer sqlc, which generates typed Go code from raw SQL. Rails doesn't offer this choice: Active Record is the default.

Takeaway

There's no universal winner between Rails and Go for a SaaS backend. It's a real tradeoff, and which side you land on depends on what you're optimizing for. If you want a decision made for you so you can move fast, Rails' opinions are worth a lot. If you want a lighter footprint and don't mind making (and living with) your own calls, Go rewards that.

I ended up building starter templates in both, precisely because I didn't want to make either of these tradeoffs more than once. You can check them out at rdooley.dev.

User Registration Is Never Just a Form

Ryan Dooley — Wed, 05 Aug 2026 14:36:59 +0000

"Add user registration" sounds like a checkbox, but what does that actually entail? What does a registration flow really need to hold up: not just accept a signup, but keep bad actors out, keep passwords safe, and make sure the person on the other end is who they say they are?

Even the form isn't free

Before any of what follows, there's the form itself: two fields, submit button, done, right? Except now it needs styling that matches the rest of your app, inline validation so a bad email address or a too-short password doesn't round-trip to the server before the user finds out, and error states that don't look like an afterthought. None of that is hard. It's just real time, before you've stored a single user.

The form works. Now you need somewhere to put that user

That row can't just land in a table as-is. The password can't sit there as plain text, and it can't be encrypted either (encryption is reversible if you have the key, which means a breach hands over every password on your system). It has to be hashed: a one-way fingerprint you compare against, never reverse. And you shouldn't write that hashing yourself. It needs to be deliberately slow and resistant to brute-forcing, which is exactly the kind of non-obvious property a purpose-built library gets right and a homegrown one doesn't. On the Rails side, Devise handles this for you via bcrypt. On the Go side, I'm using golang.org/x/crypto/bcrypt, same algorithm, same reasoning.

The user's stored, but you don't know it's really them

Anyone can type an email address into a form. So you need email verification, both to confirm the address is real and to keep bots from mass-registering accounts. Which means you need to be able to send an email. Which means you need an SMTP setup before you've built anything a user will ever see.

Locally, I'm using Mailpit, a real SMTP server in Docker with a local inbox UI. If you're coming from Rails, your instinct is probably Letter Opener instead, and it's genuinely easier to drop into a Rails-only app. I went with Mailpit because it's language-agnostic: the exact same setup works for the Go template too, one tool instead of two. In production, that email goes out through Resend, mostly because the free tier is generous enough that I don't have to think about it yet.

Sending it can't block the request

You can't fire that email synchronously inside the registration request, or the user's signup hangs on a third-party API call. Invisible in dev, painful the first time Resend has a slow moment in production. So sending has to happen off to the side.

On the Rails side, that's Solid Queue, which hooks straight into Postgres, no Redis required. On the Go side, there's no equivalent convention to reach for, so I kept it simple: a goroutine. No persistence, no retry, if the process dies mid-send the email's just gone. Not the "proper" answer, but for a fire-and-forget verification email at this stage, that's a fine tradeoff.

The link works, until Gmail gets to it first

The user has to click the link to verify. Simple, right? Build the endpoint as a plain GET: click the link, hit the server, mark the account verified. Works fine in every manual test you'll ever run.

Then a real user with a Gmail account signs up, and their account gets marked verified before they've clicked anything. Gmail's link-scanning pre-fetches links in incoming email to check for phishing and malware, which means it hits your GET endpoint itself, and if that endpoint mutates state, Gmail just verified the account on the user's behalf.

So the endpoint has to be a POST instead. Gmail's scanner won't submit forms, only fetch links, which closes the hole, but it also means you can't just have a bare "click here" link anymore. Now you need a landing page with a confirm button that fires the POST. A small UI you didn't budget for until you hit this.

That's registration for a single method. One more thing worth naming: today, users also expect to sign up with Google or GitHub, so there's another users table decision buried in here too, making sure it can hold whatever an OAuth provider hands back, and still make sense for someone who signs up with Google today and adds a password next month.

And that's it. That's registration.

A users table that stores passwords correctly, and holds up for OAuth users too. A local email tool and a production email provider, wired up the same way. A queue or a goroutine so signup doesn't hang on a network call. A landing page and a POST endpoint just so Gmail doesn't verify accounts on your users' behalf.

You still haven't built login, sessions, or password reset.

If you'd rather not build all of that yourself, it's already solved in the templates over at rdooley.dev.

Why I Built Templates for Rails and Go (After 10 Years of Shipping Other People's Products)

Ryan Dooley — Fri, 31 Jul 2026 14:40:01 +0000

Originally posted on my blog.

I'll get an idea for a side project, get excited, and start coding. Then a few days in I hit the same point every time: the app works on my machine, and now I have to actually put it on the internet. And that's where I stall out, not because the idea is hard, but because I'm suddenly choosing between five different hosting platforms, each with a different price tag and a different set of assumptions about what I already know how to do.

It's a strange spot to be stuck in, because I've spent the last decade as a software engineer, most of it deep in Ruby on Rails, with a lot of Go mixed in more recently. On paper this shouldn't be the hard part. But most of that time has been inside one large codebase, on one team, where a platform team handles deployment and I just push code. So the one skill I never had to build is exactly the one I need the moment I try to ship something of my own.

Take Render versus something like DigitalOcean. Render makes deployment genuinely easy, but running a full app there costs a lot more than handling the server yourself. And handling it yourself means the other part of the wall: configuring the server, setting up a reverse proxy, the stuff that isn't hard exactly, but isn't something I touch every day either, so every time I do it I'm relearning it from scratch.

None of that is really about skill. It's just that this isn't the muscle I use day to day, and every time I want to ship something of my own, I end up paying that relearning tax before I even get to the idea itself.

I wanted to build something that closed that gap, for me first.

The second problem: too many ideas, not enough time

The other thing pushing me here was more personal. I've got a handful of SaaS ideas I'd genuinely like to explore, not just as hobby side projects but as things I'd want to actually test in front of real users. The problem is that "test an idea" and "build a SaaS product" are supposed to be two different amounts of effort, and in practice they're not. Setting up auth, billing, a database, deployment, a landing page: that's real time, and I don't have enough of it to pay that tax for every idea I want to poke at.

So the templates became a way to solve my own problem first. If I could build a foundation solid enough to trust, I could spend my limited side-project hours on the idea, not on re-plumbing the same infrastructure for the fifth time.

Why Rails and Go specifically

The Rails side is straightforward. It's what I know best, and it's still one of the fastest ways to get a real product in front of users.

The Go side has a different origin. At my day job, I ran into a genuine limitation of Ruby and Rails, a case where a Go service would have handled the job better than what we had. That sent me down a real rabbit hole of learning Go, and it stuck. I'll say clearly: these templates don't answer that original day-job problem. That was a specific, narrow case. What they do is give me (and hopefully other Rails devs) a low-stakes way to get curious about Go, without having to justify learning an entire new stack just to try it out.

What "solid" means to me

I'll be honest, I don't think these are the flashiest templates out there. But I built them to be genuinely solid: the kind of foundation I'd trust for my own SaaS ideas, with the features that actually matter for shipping something real, not just a demo. I didn't cut corners on the parts that are tedious but necessary just to make the launch date.

This is also just one piece of a bigger thing I'm building, a few different income streams running in parallel, of which this is the one I'm most excited about right now. I'll be writing more here as I go, including the more technical decisions behind each template.

If you're a strong engineer who's never quite gotten around to shipping your own idea, or a Rails dev curious about Go without wanting to commit to a full rewrite, this might save you some time.

If that sounds like you, I've put together two starter templates, one for Rails and one for Go, that handle the deployment, auth, and infrastructure setup for you. You can check them out at rdooley.dev.