Forem: José

Building a SaaS with Claude Code: Why Experience and Framework Choice Matter

José — Thu, 08 Jan 2026 11:37:20 +0000

There's a lot of hype around AI coding assistants. "Just describe what you want and ship it!" The reality is more nuanced.

I recently built MatGoat, a management platform for martial art academies as a side project, using Claude Code as my primary development partner. It worked really well. But I want to be honest about why it worked.

The Two Factors That Made This Work

1. Software Engineering Experience

I've been writing code professionally for over 15 years. This matters more than people admit when discussing AI-assisted development.

When Claude suggests a solution, I can immediately evaluate it. Is this the right pattern? Will this scale? Are there edge cases it's missing? Does this follow the conventions of the codebase?

AI assistants are excellent at generating code. They're less reliable at knowing when that code is appropriate for your specific context. That judgment comes from experience.

I wasn't "vibe coding" in the sense of blindly accepting suggestions. I was having a technical conversation with a very knowledgeable collaborator, one where I understood enough to guide the direction and catch mistakes.

2. Choosing Rails

This might be the most underrated factor. Rails has been around since 2004. There are twenty years of blog posts, documentation, Stack Overflow answers, and open-source code in the training data of every major LLM.

When I ask Claude to implement something in Rails, it draws from this massive corpus of well-established patterns. The suggestions are almost always idiomatic. The generated code follows conventions that experienced Rails developers would recognize and approve.

Compare this to asking an AI to help with a newer framework or a custom architecture. The AI has less to draw from, and the suggestions become more generic or less reliable.

Rails gave Claude the context it needed to be genuinely helpful.

How the Development Actually Worked

My workflow wasn't "describe feature, accept code, ship." It was more like:

Architecture discussions. I'd describe a problem and ask Claude to outline approaches. We'd discuss tradeoffs. I'd make the final call based on my understanding of the system.

Scaffolding acceleration. Once I decided on an approach, Claude could generate the boilerplate quickly. Models, migrations, controllers, views, tests. This saved hours of typing while I stayed focused on the design.

Code review in reverse. I'd review what Claude wrote the same way I'd review a junior developer's PR. Most of it was solid. Some needed adjustment. Occasionally I'd rewrite a section myself because I had specific requirements Claude couldn't infer.

Debugging collaboration. When something broke, I'd share the error and context. Claude would suggest causes. I'd evaluate which made sense given my knowledge of the system.

The Stack

Claude helped me settle on a straightforward architecture:

Rails 8.1 with Hotwire for the frontend.
PostgreSQL for the database.
Solid Queue for background jobs (no Redis dependency).
Kamal for deployment.

Nothing exotic. Battle-tested tools with extensive documentation. This predictability made Claude's suggestions more reliable throughout the project.

What I Built

MatGoat now runs in production, handling:

Multi-tenant academy management.
Class scheduling with real-time availability.
Student progression tracking (belts and grades).
Video content delivery.
Attendance history and semester rankings.
Payment processing with Stripe.

Deployments are one command. Monthly hosting costs less than a Netflix subscription.

How it went

Where Claude worked well:

Generating idiomatic Rails code quickly.
Remembering context across a long coding session.
Explaining unfamiliar APIs or patterns when I asked.
Writing tests that matched the style of existing specs.
Kamal and deployment configuration.

Where I still needed to lead and change things:

Business logic that required domain knowledge.
Performance-critical sections that needed careful thought.
Security considerations and edge cases.
Architectural decisions with long-term implications.

The Takeaway

AI-assisted development isn't magic. It's leverage.

If you have the experience to evaluate suggestions and guide the process, tools like Claude Code can significantly accelerate your work. If you're newer to development, treat it as a learning partner rather than an oracle.

Also, if you're choosing a stack for an AI-assisted project, consider framework maturity. The AI is only as good as the patterns it learned from.

How I Built a Full-Featured SaaS with Rails 8 and Deploy It with One Command

José — Thu, 08 Jan 2026 09:34:18 +0000

When I set out to build MatGoat, a management platform for martial arts academies, I had one goal: keep it simple.

No Kubernetes. No microservices. No complex CI/CD pipelines. Just a Rails monolith that I could deploy with a single command.

Here's how I did it.

The Stack

Rails 8.1 with Hotwire (Turbo + Stimulus)
PostgreSQL for the database
Kamal 2 for deployment
Hetzner Cloud for hosting (~€20/month)
Solid Queue for background jobs
Tailwind CSS for styling

That's it. No webpack. No Node.js build step. No Redis cluster. No separate job server infrastructure.

Why Rails 8 Changes Everything

Rails 8 introduced what I call the "Solid trifecta":

Solid Queue - Database-backed job processing
Solid Cache - Database-backed caching
Solid Cable - Database-backed Action Cable

This means I don't need Redis for most use cases. My background jobs, caching, and real-time updates all run on the same PostgreSQL database that handles my application data.

One less service to manage. One less thing to break.

Deployment in One Command

Here's the entire deployment process:

  kamal deploy

That's it. That's the actual command. Kamal handles:

Building the Docker image
Pushing it to the registry
Rolling out the new version with zero downtime
Running database migrations
Managing SSL certificates via Let's Encrypt

My deploy.yml is about 100 lines. It defines my web server, job worker, PostgreSQL database, Redis (for Action Cable in production), and automated database backups to S3.

The Architecture That Scales Down

Most architecture articles focus on scaling up. But for indie developers and small teams, scaling down is more valuable.

https://matgoat.com runs on Hetzner. The entire infrastructure costs less than a Netflix subscription each month. Yet it handles:

Multi-tenant academy management.
Real-time class registrations via WebSockets.
Video content delivery.
Student progress tracking.
Automated class scheduling.

When (if) I need to scale, I add another server to the servers array in my Kamal config. That's it.

What I Don't Have

No container orchestration platform.
No managed database service.
No separate CDN configuration.
No infrastructure-as-code beyond the Kamal config.

And I don't miss any of it.

The Maintenance Story

Every day, I run:

kamal deploy

If something goes wrong:

kamal rollback

Need to check logs?

kamal logs

Need a Rails console?

kamal console

The mental overhead is minimal. I spend my time building features, not fighting infrastructure.

The Takeaway

You don't need a complex architecture to build a real product. Rails 8 with Kamal gives you:

Simplicity: One language, one framework, one deployment tool
Speed: Deploy in minutes, not hours
Cost efficiency: Run everything on a single VPS
Maintainability: Less moving parts means fewer things that break

If you're an indie developer or a small team, consider whether you really need that Kubernetes cluster. Sometimes the boring solution is the right one.