Why I Built Templates for Rails and Go (After 10 Years of Shipping Other People's Products)
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 actual idea is done, prototyped, working. Now I'm staring down everything around it. Auth, deployment, SEO basics, some kind of analytics so I'm not flying blind. A landing page that doesn't look like a placeholder. None of it is the hard part, exactly, but all of it has to happen before a single real user ever sees the thing.
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 auth was already solved, a platform team handled deployment, and someone else owned analytics. I just pushed code. So the skills I never had to build are exactly the ones I need the moment I try to ship something of my own.
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.
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. A way to quickly prototype the other ideas I've got, without paying the setup tax every time.
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. It just turned out solid enough, and useful enough on its own, that it made sense to put it out there too.
The templates
If you're a strong engineer who's never quite gotten around to shipping your own idea 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 try the live demos free at rdooley.dev.
Curious how other people are approaching this. Are you building all of it yourselves, or just shipping a scrappier first version and backfilling the rest later?
This resonates a lot, I just packaged my own marketplace codebase (NestJS/Next.js, built for a local marketplace in Senegal) into a boilerplate. The hardest part for me wasn't the code, it was figuring out payouts as a solo dev outside the US/EU. How did you handle pricing, one-time vs subscription?
Congrats on getting your boilerplate out!
I am not exactly sure who your target audience is here since I'm based in the US, but for me the reasoning is because of the use case I was trying to solve. Someone has an idea that they want to spin up quickly. They want the template to solve all of the boilerplate issues and they'll take it from there. The only thing i could really think for a subscription is keeping the packages up to date, but at that point their app could be far past the point of easy upgrades.
The interesting positioning challenge here is that “templates for Rails and Go” describes the format of the product, but not necessarily the expensive problem it solves for the buyer. After 10 years of shipping other people’s products, the founder likely has a much stronger insight into what repeatedly slows teams down than the homepage headline may communicate. I’d be curious whether the messaging leads with “ready-made templates” or with the painful outcome they eliminate—because experienced developers don't necessarily buy templates for templates’ sake; they buy back weeks of product-building time.
Thanks for the feedback! I really appreciate it! I will definitely take this back and think about it.
When I was writing this post I struggled a little bit back and forth on the framing of this and my message might be a little split. Theres two different problems I solved for myself at one time:
But the selling point here really is eliminating the start up cost.
I wanted this post to be more about the problems I was solving for myself because I was afraid of this turning into a marketing post haha.
Really appreciate your feedback and ill take it with me
That makes total sense — and honestly, I think you’ve already found the strongest positioning angle.
The “I built these because I needed them myself” story is great for the post, but the homepage has a different job: make the right developer immediately think, “Yes. I’m wasting time rebuilding all of this every time I start a project.”
That’s the gap I’d be most interested in checking.
If you want, I do a $10 SaaS Homepage Conversion Leak Audit where I look specifically for places where the page may be making the product sound like “Rails/Go templates” instead of “a shortcut around the setup tax.”
It’s a small written audit — no call, no sales pitch — just the conversion leaks I’d fix first.
If you’re curious, you can send me the homepage and I’ll take a look.
I really relate to the “setup tax” problem here. It’s easy to underestimate how much time gets lost getting auth, deployment, billing, databases, and all the other basics into place before you can even test the actual idea.
The part about building something solid enough to trust, without overbuilding it, is a tricky balance. A reusable foundation seems especially useful when you have a lot of ideas you want to test.
I also like the distinction between testing an idea and building a full product. If the infrastructure takes days before you can put something in front of a user, it changes which ideas are worth testing in the first place.
The question of how much to build before getting feedback is probably one of those things that gets easier with experience, but never completely disappears.
It definitely is really tricky because at the end of the day theres potentially a lot of customization.
For example, I have a predesigned design system for my templates. Thats something everyone is going to want to stand out on so it needs to be built in a way that its easily swappable.
Something actually less clear from my templates though is the decision on which services to actually use. I really tried to build it in an agnostic way so it doesn't matter if you want to use sentry vs datadog for example. But I also needed to learn how to spin up my idea with the least amount of cost possible
Even though I built is as agnostic as possible, the services I suggest contribute to the idea of spinning up your idea as fast and cheap as possible, even though I don't really call this out anywhere. SMPT, analytics, hosting, etc. Getting your idea live does cost something, and im going to help you get it there as cheap as possible.
As far as how much to build before getting feedback the way I looked at it was, "what solves my problem now." I have a backlog of ideas that I personally didn't need, so until I have a good amount of feedback, they'll stay in the backlog
You’ve got two fairly different motivations behind these templates: helping experienced engineers get past the shipping/infrastructure wall, and giving Rails developers an easier entry into Go.
From the people who've shown interest so far, are you seeing one of those reasons consistently pull harder than the other?
I haven't seen too much traffic yet, but based on the analytics both demos have been looked at relatively evenly.
If you ask me, I would expect the rails version to be the more popular one, simply because in my experience Go isn't as prevalent for this use case. I would expect that one to be more interesting to an engineer who is interested in Go vs someone looking to ship a SaaS product.
I ran into a very specific use case that did not fit within the limitations of ruby/rails, that Go did have an answer for, which is what pushed me in that direction.
Anyway, its a little early for me to derive any real conclusions since I launched this just last week and im just starting to see traffic trickle in.
I will say that not only is the shipping/infrastructure wall a problem for me, but because I've personally shipped very little in the past, I run into another issue at the marketing/SEO part. I simply have little experience on that front, having a template gets my ideas out there, so I can start building that muscle.
That’s helpful context. The interesting part is that the template seems to be solving two different gaps — shipping faster and helping engineers build the muscles around getting products in front of users.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?