Why I built goilerplate: the JavaScript fatigue answer for Go founders

I have shipped SaaS products in PHP, Rails, Next.js, Remix, SvelteKit, and Nuxt over the years. Almost every time, the same thing happened.

Week one is magic. Around week six I am fighting hydration mismatches, debating server actions, and chasing some new bundler breaking change. By week twelve I have a half-built product, a node_modules folder the size of a small Linux distro, and zero paying customers.

goilerplate is the boilerplate I wish I had on day one. It runs on Go, templ, HTMX, and TailwindCSS. It is boring and fast on purpose, and it actually ships.

If you are tired of the JavaScript treadmill, keep reading.

The problem with modern SaaS stacks

The 2025 indie SaaS stack looks roughly like this.

Next.js or Remix or SvelteKit on the frontend.
A Node.js runtime on the backend, sometimes the same process, sometimes a separate one.
tRPC, or oRPC, or REST, or GraphQL to wire the two halves together.
Prisma or Drizzle to talk to Postgres.
Better-auth or NextAuth or Clerk for authentication.
shadcn/ui or Mantine for the UI.
Tailwind for styling.
Stripe or LemonSqueezy or Polar for payments.
Resend or Postmark for email.
Vercel or Fly.io or Railway to deploy.

That is twelve moving parts before you have written a single line of business logic. Every one of them has its own release cadence, its own breaking changes, its own footguns, and its own Discord where you are told the bug is your fault. Plus the supply chain risk that comes with 800 to 2000 npm packages on top.

I am not saying that stack is bad. People ship great products with it every day. I am saying it is a lot, and most of that complexity exists to paper over the fact that you are running JavaScript on two different runtimes and trying to pretend it is one.

What I actually wanted

When I sat down to design goilerplate, I wrote down what I wanted from a starter.

One language, one process, one binary. Compile, copy, run.
No build step for the backend. go run main.go, done.
HTML on the server. Templates. Forms. Redirects. Old-school works.
A modern UI without a SPA. Tailwind for styling, templUI components for the look and feel, HTMX for interactivity.
Type safety in the templates. templ gives me compile-time errors when I rename a struct field.
Auth, payments, email, blog, docs, legal pages, all wired up.
I own the code. No SaaS subscription, no opaque library, no “framework magic” I cannot grep through.

That is goilerplate.

Why Go

Go gets a bad rap in the indie hacker scene because the “fancy” SaaS demos are usually written in TypeScript. But the second you put your product in front of users, Go starts paying you back.

Single binary deploys. One artifact, many deploy targets. Docker image, Coolify, Dokploy, Fly.io, or plain systemd on a VPS. No node_modules, no npm install on the server, no version drift between dev and prod.
Memory and CPU profile that fits on a $5 VPS. Your Stripe webhook traffic does not need an autoscaling Kubernetes cluster.
A standard library that already does most of what npm packages do. HTTP server, JSON, crypto, templating, all in the stdlib.
A type system that catches bugs before you deploy. No any, no “is this a Promise?”, no runtime surprises.
Tooling that does not break. go build, go test, go fmt. Same commands in 2014. Same commands in 2026.

Go is what you reach for when you want to ship a product, not when you want to learn a new framework.

Why templ over html/template

Go has a built-in templating language, html/template. It is fine. It works. But it has two problems if you are coming from React or Vue.

Templates are strings. Typos and renames blow up at runtime.
Composition is awkward. You end up with {{ template "x" . }} calls everywhere.

templ fixes both. Templates are written in .templ files, compiled to Go code, and type-checked. You write something that looks like JSX and you get full IDE support, refactoring, and compile-time errors.

templ BlogCard(post *models.BlogPost) {
    <article class="rounded-lg border p-6">
        <h2 class="text-xl font-bold">{ post.Title }</h2>
        <time datetime={ post.Date.Format("2006-01-02") }>
            { post.Date.Format("Jan 2, 2006") }
        </time>
        <p>{ post.Description }</p>
    </article>
}

That compiles to Go. If you rename Title to Headline on the BlogPost struct, this file fails to build. No more “I deployed and the blog renders an empty title” incidents.

How templUI happened (and why goilerplate uses it)

Worth a small detour, because the story explains a lot of the rest.

I am the founder and maintainer of templUI. It started exactly the way these things start. I was a Go developer looking for an honest way out of the JavaScript framework treadmill for my webapps. I found templ, and within a weekend I felt at home in a way I had not felt on a frontend in years. The one piece missing was a component library. So I started building one for my own projects.

People starred it. Opened PRs. Asked for more components. I kept shipping. As of May 2026, templUI is past 1600 GitHub stars and climbing, with a steady stream of accessible, copy-paste components for templ + HTMX + Tailwind. It is the open-source UI library I wish had existed the day I switched, and it is growing every week as I ship into it.

goilerplate is what came next. With templ for templates, HTMX for interactivity, and templUI for components, I had the production stack I had been chasing. Every product I started after that reached for the same auth code, the same billing handler, the same SEO scaffolding. So I codified it once and made it the boilerplate.

If you buy goilerplate, you are not betting on someone who picked this stack last year. You are betting on someone who built and maintains a meaningful piece of the stack itself.

Why HTMX over a SPA

HTMX is the dirty little secret of 2026 web development. It lets you do most of what a SPA does, with less code, no build step, and no client-side state to manage.

You want to swap a fragment of HTML when someone clicks a button? Add hx-get="/some/path" hx-target="#thing". Done.

You want to submit a form without a full page reload? Add hx-post and hx-target. Done.

You want a modal, a toast, a sidebar? Use templUI. It is a set of accessible, copy-paste components built for templ, HTMX, and Tailwind. No virtual DOM, no hydration, no 'use client', no React Server Components debate. Just HTML.

The pattern is the same one we used in 2008 to build PHP and Rails apps. The difference is that the components look good now. The longer version of why this stack is back is here.

What is in goilerplate, out of the box

Open the box and you get:

Authentication. Magic links, Google and GitHub OAuth, password reset, email change verification, account deletion. JWT cookies with HttpOnly, Secure, SameSite.
Subscriptions. Polar and Stripe managed payment integrations out of the box with signature verification and idempotency on webhooks. More providers and one-time payments on the roadmap.
A blog. Markdown files with YAML frontmatter, tags, hero images, SEO. You are reading it.
Docs. Same engine as the blog, with sidebar nav, breadcrumbs, table of contents, dark mode, syntax highlighting.
Legal pages. Privacy, Terms, Cookies, all editable in markdown.
Email. Resend integration with transactional templates for welcome, magic link, verification, password reset.
A landing page. Hero, pricing, FAQ, testimonials, about, footer. Edit the markdown and the templ, deploy.
SEO. Sitemap, robots, JSON-LD, OpenGraph, canonical tags, all wired up.
Security headers, CSP with nonces, CSRF middleware. The boring but necessary stuff.
S3-compatible file uploads. Avatar upload flow wired in. Works with AWS S3, Cloudflare R2, Backblaze B2, DigitalOcean Spaces.
Migrations. Goose with up/down SQL files, applied at startup, idempotent.
A dev workflow you will not hate. task dev starts templ, Tailwind, and the Go server with hot reload. Save a file, see the change.

For the hour-by-hour math on what each of these would cost you to build from scratch, with and without AI, see boilerplate saves you 200 hours.

What is not in goilerplate

This is just as important. I deliberately kept things out.

No JavaScript framework. No React, Vue, Svelte. HTMX and a sprinkle of vanilla JS.
No GraphQL. REST handlers and HTML responses. You can add gRPC if you really want.
No microservices. One binary, SQLite by default, Postgres when you outgrow it.
No “AI features.” Drop in your own OpenAI or Anthropic call when you need it.
No Docker Compose forest. A single Dockerfile, a single binary out the other end.

Less is more when you are trying to get to $1k MRR.

Who goilerplate is for

If you are a Go developer who wants to ship a SaaS without learning React, goilerplate is for you.

If you are a JavaScript developer who is curious about Go, goilerplate is a great way to learn. The patterns are familiar, the language is small, the documentation is excellent.

If you are vibe-coding your way to v0.1 with Claude Code or Cursor and want a real foundation under it, here is why a boilerplate still matters in the AI era.

If you are a senior engineer who has been burned by framework churn and just wants to write boring code that prints money, goilerplate is especially for you.

What is next

I am building goilerplate in public. New features, fixes, and blocks land in the repo every week, driven by what I need for my own products and by what customers ask for. Lifetime updates is not a marketing line. It is the same codebase I run for myself, and you get every change I ship. New posts go up every couple of weeks covering the stack, the trade-offs, the wins, and the mistakes. Subscribe to the feed if you want to follow along.

If you would rather skip the blog and just buy the thing, grab a license and start shipping this weekend. The code is yours forever.