← All posts

Why I Built Templates for Rails and Go

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.