The Claim That Makes Developers Wince
Every tool on my portfolio shares a slightly heretical trait: there's no backend. No Node server humming somewhere, no framework, no build step, no container to babysit, and no team. When I tell technical people this, I get one of two reactions — either "that can't possibly scale" or "wait, how does the AI part even work?"
Both reactions assume that shipping a real, AI-powered web tool requires real infrastructure. For a long time it did. That assumption is now mostly wrong, and the gap between "I have an idea" and "it's live and people are using it" has quietly collapsed for one person working alone. I want to show you exactly how, because the how is more useful than the hype.
This isn't a "look how clever I am" post. It's closer to the opposite: the whole point is that the setup is so boring and small that anyone willing to learn a few pieces can run it. The cleverness is in what I left out.
Why I Refuse to Spin Up Infrastructure
I build around a full-time job and a family. My constraint isn't ambition — it's time and maintenance. The moment a side project needs a server, it stops being a weekend tool and becomes a thing I have to feed: security patches, hosting bills, an environment that breaks the week I don't touch it. Most one-person tools die in that maintenance swamp, not at the idea stage.
So I made a rule. If a tool needs me to run a server to keep it alive, I don't build it that way. That single constraint forces every project into a shape that's cheap to host, nearly impossible to break, and trivial to walk away from for a month. It's the same instinct behind everything I make: strip it down until what's left is the smallest thing that actually delivers the value.
The funny part is that the constraint makes the tools better, not worse. When you can't lean on a backend, you're forced to be honest about what the tool truly needs to do. Most of them need far less than you'd think.
The Whole Stack, in Plain English
Here's the entire architecture behind a typical tool of mine — for example, the Retirement Runway Snapshot. There are only really four moving parts, and a person can hold all of them in their head at once:
- A static HTML page. The whole front end is one hand-written HTML file — the form, the styling, the logic — hosted as a plain file on ordinary web hosting. No framework, no build. It loads instantly and there's nothing to crash.
- A webhook to Make.com. When you submit the form, the page sends your answers to a single Make.com webhook URL. That's the entire "API." Make.com is the no-code automation platform doing the work a backend normally would — but I wire it together visually instead of writing and hosting server code.
- An AI call inside the automation. Make.com hands your inputs to Claude with a carefully written prompt, gets back a plain-English result, and does whatever else is needed — saves a record, sends you an email. The AI is one well-defined step in the flow, not the whole system.
- The result comes back to you. Usually by email, sometimes rendered on a shareable page. No accounts, no dashboard to maintain, no database I have to administer.
That's it. Read it again and notice what's missing: no server I own, no framework, no deploy pipeline, no ops. The "backend" is a visual automation I can edit from a browser on my phone. When something breaks, I'm debugging one flow with named steps — not chasing a stack trace through code I'd have to redeploy.
If you've read about my 16-module Make.com automation, this is the same muscle pointed at a different problem. Once the pattern clicks, every new tool is mostly a matter of deciding what the form asks and what the prompt should — and shouldn't — say.
The Guardrails Are the Real Work
If the plumbing is that simple, where does the actual effort go? Into the guardrails — and this is the part I'd argue matters most, especially when a tool touches anything sensitive like someone's money or their kids.
The prompt is where a tool earns trust or loses it. A language model will happily produce a confident, official-sounding answer to a question it has no business answering. So most of my building time goes into the boring, essential work of telling the AI what it is not allowed to do: don't invent precise numbers, don't give advice, stay in ranges and plain language, point the person toward a real professional. The webhook is also locked down with a secret token so it can't be hammered by anyone who finds the URL.
That's the honest trade of this approach. Wiring four parts together is the easy 20%. The thoughtful 80% is deciding what the tool refuses to do — which is exactly where a careful builder adds value that a generic chatbot never will.
What This Actually Unlocks
The reason I keep talking about this stack isn't the tech — it's what it does to the distance between an idea and a real thing. When shipping doesn't require infrastructure, you stop triaging ideas by how hard they are to host and start picking them by how useful they'd be. "I wish a tool existed that did X" becomes a weekend instead of a quarter.
That shift matters far beyond my side projects. A single capable person — or a lean team wearing a lot of hats — can now stand up real, AI-powered, genuinely useful software without a budget, a server, or an engineering department. That used to be the exclusive territory of companies with resources. It isn't anymore, and I don't think most people have fully felt how big that is yet.
I've built tools this way for my kids' reading practice, for my own writing workflow, and for thinking through retirement. None of them needed a backend. All of them are live. That's the whole argument.
🛠️ See one running in the wild
The Retirement Runway Snapshot is a working example of this exact stack — static page, one webhook, an AI call with strong guardrails. Try it and watch the pattern in action.
Try the Snapshot →If You Want to Try It Yourself
You don't need to be a developer to build this way — I'm proof that you mostly need a willingness to learn four pieces and the discipline to leave the rest out. Start with one tiny tool you personally wish existed. Make the form ask only what it truly needs. Wire one webhook. Write one careful prompt, and spend most of your effort on what it should refuse to do. Ship it ugly and improve it later.
That's how every tool I have started — small, honest, and live before it was polished. If you build something this way, I genuinely want to see it. The best part of working in the open is watching other people take the pattern somewhere I never would have thought to.