Rails For Marketing Sites in the AI Era

A couple of years ago, we rewrote Judoscale’s marketing site from NextJS to Ruby on Rails. I enjoyed the process so much that I made a video sharing how it worked, and Jon wrote a spicy piece arguing that Rails was a perfect fit for mostly-static marketing sites like ours, and that you shouldn’t waste your time with JavaScript frameworks that were all the rage at the time.

A lot has changed since then (duh!), and I wanted to revisit this topic to share my current take. Jon’s gonna chime in later with his take as a bit of a rebuttal. It’s healthy to disagree, but rare to see it in a blog post. Let us know what you think of the format!

Adam’s take

I recently built a new marketing site for my wife’s dietitian practice, which is why this is so top-of-mind for me. The previous site was a Rails app that I built, and she wanted to redesign the site. Of course a redesign does not warrant a rebuild, but we’ll get there. Let’s first take a step back.

When I say “a lot has changed”, obviously I’m talking about AI. If you’re reading this, you’re probably a developer using AI in your daily coding. For me right now in August 2026, AI is writing nearly 100% of my code, whether it’s for personal use or for Judoscale.

Most of the code I write (generate, command-into-existence, whatever) is Ruby. AI is fantastic at writing Ruby, particularly Ruby on Rails. But since I’m not handwriting code anymore, I care a lot less about the languages and frameworks used, especially if I’m not reading the code.

“Whoa, hold up! You’re not reading the code?!”

Well, it depends… For the Judoscale app itself, which is responsible for our customers’ data and keeping their applications online, I am absolutely reading the code. For personal projects and projects that don’t involve customer data, not so much. Let’s take a marketing site like the one you’re reading right now. It’s mostly a blog, some landing pages, a fancy price comparison tool, and documentation. Why bother reading every line of code?

So as I approached redesigning my wife’s website, I knew AI would be generating the code and that I wouldn’t be reading it. All I cared about was the user experience of the site itself. This meant that a redesign and a rebuild were essentially the same amount of effort, and if I’m considering a rebuild, I should reassess the stack.

Since I didn’t care much about the language or framework used, the decision really came down to hosting. A Rails app is a persistent process that needs to be running 24/7. A PaaS like Heroku (or Render, or Railway, etc.) makes it easier, but it’s still something to manage. I’d also need a database to store some of the site content, and asset storage. More things to manage, more things to pay for.

Instead, I went with EmDash CMS hosted on Cloudflare Workers. EmDash is built on Astro, which is what I would’ve used if we didn’t need a CMS. Cloudflare is already sitting in front of the site for DNS and CDN, so hosting the site there feels like a no-brainer. Assets live in Cloudflare R2, and the site content lives in D1 (Cloudflare’s serverless SQL database service).

Not only is everything in one place, but at her scale (and probably most marketing sites), it’s completely free. Cost is really a secondary concern here, though. The big win for me is simplicity. There’s nothing I need to keep up and running, nothing I need to update over time.

And of course AI agents know Astro and Cloudflare very well, so the build and deploy experiences were amazingly smooth. I never read a line of code, and I don’t need to. The site just works.

To be clear, I’m not anti-Rails or anti-PaaS for marketing sites or anything else. They are still amazing tools that I use all the time. But for me, AI has made serverless cool useful again, at least for marketing sites. And that means Cloudflare workers running JavaScript.

Jon’s rebuttal

Alright, hold on; we need to zoom out! If the question is, “Should you use Rails for a marketing site in the AI era?” then I think Adam’s take is “I would vibe code”. As in, he wouldn’t even deliberately decide which stack to use because he moved himself up the engineering ladder (out of ‘engineering’ I would even say 🌶️). I guess that answers the question… “don’t choose a stack at all, just use AI ✨.” But I don’t like that answer. Not always, at least.

My rebuttal has two pillars. Let me start on the simpler one, which Adam actually agrees with (I think). Marketing sites should be dynamic, not static. In our post a few years back, we deliberately chose to use Rails for several reasons, but we didn’t talk much about the static vs. dynamic axiom. In the years since I’ve come to realize: the ask will always come. What you make a truly static site today will be asked for dynamic features. Maybe not tomorrow. Maybe not this year. But next, or the one after, it will. Static sites either die or live long enough need dynamic things. Adam’s AI went with emDash CMS with Cloudflare persistence so it agrees, apparently!

The second pillar of my rebuttal is about reading code… but I think there’s nuance here. Ultimately, I think drawing the line of “should I read the code?” around customer data is a mistake. That’s a very ‘engineer’-shaped definition of important software. If this is a hobby site, or something where you genuinely don’t care how it directs and guides users, then sure: vibe away. Have AI build it in Astro, Rails, PHP… COBOL! I don’t particularly care either. If the output looks great and you’re comfortable throwing the whole thing away if it doesn’t, the implementation really is an implementation detail.

But a marketing site for a business is different. It makes money. Maybe not directly, but most people at a business will understand that how a marketing site directs, informs, catches, and guides users is a direct factor in the money-making process. Even the most die-hard “provide value! don’t just seek to make money!!” folks inevitably understand that user attention is a finite resource and one must play the game (a little).

We engineers tend to reserve our scrutiny for the parts of the system that feel like engineering: databases, background jobs, APIs, authentication, concurrency, performance. We care deeply about their mechanics because we understand how subtle implementation choices can affect the business. But we forget that our sales and marketing teams feel exactly that same way about the mechanics of a boring-old marketing site that doesn’t handle customer data directly.

They care about page speed. They care about analytics firing correctly. They care about attribution surviving a signup flow. They care about canonical URLs, redirects, structured data, accessibility, forms, experiments, conversion funnels, and the fifty tiny details between someone landing on a page and becoming a customer. A marketing site can “work just fine” while quietly missing a few of those steps and churning visitors that were genuinely interested in your product/service.

To clarify: this is still a “software correctness” concern!! The failure mode just isn’t a 500 or Sentry error. And it’s usually harder to track than hard-errors.

So I don’t think “there’s no customer data here” gets us all the way to “therefore I don’t need to read the code.” If the software materially participates in your business, its implementation matters. And if its implementation matters enough to read, suddenly the language and framework aren’t irrelevant anymore.

This isn’t to say you shouldn’t use AI to help you build your marketing site! You should! But you should read everything and consider it thoughtfully. You should bring your full intentionality and engineering prowess to that marketing site.

So… Should you use Rails for a marketing site in the AI era? If Rails is the tool you’re most familiar with, I think you should. But there’s a second question now: Should AI just build my marketing site? And I think the answer is (maybe unsurprisingly): not if you’re a revenue-generating business depending on that marketing site to bring you customers and explain your product/service!

P.S. Sorry Amy — tell Adam to rebuild your marketing site again but care more about conversion this time!! (Kidding, of course)

---