I built a home for a delusional cat who runs a startup. Here’s the stack.
I made a web comic about startup life. Seen through the eyes of a delusional cat with enormous confidence and a catastrophic understanding of cause and effect.
There’s an AI-generated comic I started called Startup Cat. His name is actually Startup Katt. Nobody calls him that. That’s the joke, and at this point the joke is load-bearing.
He needed somewhere to live. Not a Substack, not a LinkedIn carousel I post and lose to the algorithm. An actual website I own, where every strip has its own URL and the whole back catalogue is browsable. So I built one: startupkatt.com. Here’s exactly how, stack and all.
The stack is boring on purpose
Laravel for the app
Forge for deployment
DigitalOcean for hosting
Devin (the IDE formerly known as Windsurf) for the actual building
Claude Code wired in as the brain doing the coding
beehiiv for the subscriber list, called over its API
Three of those five are old-school. Laravel, Forge, a DigitalOcean droplet. That’s pretty much a stack people were running in 2018. I used it anyway, because I’m fastest in Laravel and a comic site does not need a reinvented wheel. The boring part of the stack is the part that lets me spend my novelty budget where it matters: on the comic engine and on how I build.
Forge sits on top of the DigitalOcean droplet and handles the unglamorous stuff like provisioning, SSL, deploy hooks, queue workers. I push to main, Forge pulls and deploys. No CI theatre, no Kubernetes, no apology. It’s a comic about a cat. It ships when I push. It doesn’t need to be fancy.
The fun part: how I actually build it
This is where it stops being 2018.
My editor/IDE is Devin. Which is hat used to be Windsurf. But Devin’s own model isn’t doing the heavy lifting. I install the Claude Code extension inside it and let Claude be the LLM doing the vibe coding. So the loop is: Devin is the cockpit, Claude is the engine. I describe what I want in plain English, Claude reads the repo, writes the Laravel, and I review.
The reason I bother routing through Claude instead of just using the built-in model: I want the thing that’s good at understanding a whole Laravel project at once and not fighting me on conventions. Pointing it at my .claude folder and a couple of skills, then saying “build the comic browser,” gets me a working controller faster than I’d type the boilerplate myself. I have a bunch of skills (in .md files) that I have developed over time and use on every new project I make.
Once you’re done with that, you can pull your own repo into it. No need to remember any git commands. Claude and Devin can just do the entire thing for you.
The comic engine, and why it’s sneakier than it looks
The visible product is simple: land on the page, see today’s strip, click forward and back through every strip ever. One comic at a time, like the newspaper page it’s pretending to be.
The clever bit is the publishing model. I don’t schedule comics. I forward-fill them.
I drop image files into a folder. The system reads them by recency and assigns each one a release date going forward from now. Add two strips today and the system rolls one out tomorrow and one the day after — the file with the earliest timestamp gets the earliest slot. So I can batch a week of comics in one sitting, drop them in, and walk away. The site drip-feeds them on a schedule I never had to manually set. Build the pipeline once, never touch the calendar again.
Every strip gets its own route and its own page (like https://startupkatt.com/comic/seed-round) rather than one Single Page App (SPA) hiding everything behind JavaScript. That’s a deliberate choice, and it’s the SEO/AEO play:
SEO: every comic is a real, crawlable, indexable page with its own title, alt text, and meta. A hundred strips is a hundred doors into the site, not one.
AEO: when an answer engine wants to cite a specific Startup Katt strip, there’s a clean canonical URL pointing at exactly that one. No “scroll to find it.” The page is the citation.
For a comic, this is the whole game. I never bolt marketing layers on after creating projects. I build the growth loops into my projects from day 1.
Turning readers into subscribers
Getting found is half of it. The other half is making sure a reader who shows up once can come back without remembering to. That’s what beehiiv is for.
I run the subscriber list on beehiiv, but I don’t send people off to a beehiiv-hosted form. The signup lives right on the comic page, and when someone subscribes I make the call to beehiiv over its API from the Laravel backend. Email goes in, beehiiv handles the list, the confirmation, the sending. The reader never leaves Startup Katt’s house.
The nice part of doing it API-side instead of with an embed: I own the form, the styling, and the placement. I can drop a “get the next strip in your inbox” prompt directly under a comic, fire it at beehiiv on submit, and keep the whole experience on my own routes. Same philosophy as the rest of the build, the boring infrastructure (list management, deliverability) is somebody else’s problem, and the part the reader actually touches is mine.
What I’d tell anyone who wants to set something up like this
Pick the boring stack for the boring parts. Or at least a stack you’re the most comfortable with. Don’t go new and flashy just because all the other kids are doing it. Laravel + Forge + DigitalOcean is unsexy and it just works. Save your weird ideas for the product, not the plumbing.
Treat the model as a teammate, not a wizard. Devin as the cockpit, Claude as the engine, me reviewing every diff. Don’t use too much of your brain - just get Claude and Devin to do everything. And I mean everything.
Bake distribution into the architecture. One route per comic wasn’t a nice-to-have I added later. It’s the reason the site is findable at all. SEO and AEO live in the routing table, not the marketing plan. Do the same for site analytics too.
Own the form, rent the infrastructure. beehiiv runs the list; I run the signup. API calls keep the reader on my pages and the deliverability headaches on someone else’s.
Old-school stack, new-school build loop.
Bonus tip. I didn’t do this because it was such a small project. But if I was making something bigger, I’d start with a full product strategy, then use Claude Design to design a site which appeals to my ICP etc. I’d add things like motion design/interaction design to make the site much more interesting on the eyes.