People ask what tools I use far more than they ask about strategy, so here is the honest stack, the things I actually open every day to ship as a team of one. Tools change constantly, but the categories do not, so I have organized this by the job each one does rather than by brand. Steal the structure, swap the specifics for whatever is best when you read this.

AI coding: the engine

This is the heart of the whole operation. I lean on an AI coding assistant that can read my entire project, not just a single file, so it understands context and can make changes across the codebase, run commands, and check its own work. A tool that only sees one file at a time is a glorified autocomplete. One that understands the whole repo is a collaborator.

But the tool matters less than the skill of using it. Small slices, clear outcomes, and reading every diff will beat a fancier tool used carelessly every single time. A great assistant with lazy prompting still ships bugs, fast. If you take one thing from this list, make it that. The details are in what vibe coding actually is.

Frameworks I reach for

The rule here is boring on purpose. Boring means well-documented, which means the AI has seen a million examples and gets it right, and means Stack Overflow already has the fix when something breaks.

  • Mobile: a cross-platform framework so one codebase ships to both iOS and Android. As a solo developer, maintaining two separate native apps is a non-starter. One codebase, two stores.
  • Web tools: whatever is mature and conventional. I avoid the framework that came out last month, no matter how exciting, because the AI does not know it well yet and neither do I.
  • Static sites (like this blog): Hugo. Markdown in, fast static HTML out, free to host, and nothing to patch at two in the morning. Perfect for content and for app splash pages.

Hosting and infrastructure

The guiding principle: the best infrastructure for a solo developer is the infrastructure you never have to think about.

  • Static hosting: a CDN-backed static host (Vercel, Cloudflare Pages, Netlify all have generous free tiers). My blog and every app splash page live here for free.
  • DNS and CDN: Cloudflare. Cheap, fast, and the dashboard does not fight me.
  • Backend, only when needed: a managed backend-as-a-service so I am not running and patching servers. Many of my apps need no backend at all, which is the cheapest and most reliable backend there is.

A lot of my apps run entirely on-device, which means there is no server to scale, no database to secure, and no monthly bill that grows with users. That is not an accident. It is a deliberate choice that keeps a one-person operation sane.

The splash-page pattern

Every app gets a subdomain with a single static page that does two things:

  • detects mobile and routes straight to the App Store or Google Play, and
  • shows a description, screenshots, and a help or FAQ section on desktop.

One link works everywhere, it costs nothing to host, and it doubles as the app’s SEO landing page. I drop that one link in any post or thread and it just does the right thing for whoever clicks it.

The glue that holds it together

This is the unglamorous layer that makes the rest survivable.

  • Git, committed constantly. This is my undo button for vibe coding. When a prompt makes things worse, and it will, I roll back in seconds instead of losing an afternoon. Frequent small commits are not optional in this style of building.
  • A project context file. A short doc of stack, conventions, and “do not do this” rules that I feed the assistant at the start of a session. It stops the AI from reintroducing the same mistakes and re-explaining the project every time.
  • A plain notes file for the backlog. Half of shipping is deciding what not to build this week. A running list keeps the good ideas from derailing the current one.
  • Analytics that respect privacy. Just enough to know which articles get read and which apps get used, without turning my users into a product.

What I deliberately do not use

  • Heavy project management tools. For one person, a Kanban board with seven columns is procrastination with a nice UI. A text file and a short memory work better.
  • Bleeding-edge frameworks. I want the AI to know the answer and the internet to have the fix. Popular and slightly boring beats new and shiny every time.
  • Anything that needs a server I have to babysit, unless there is genuinely no way around it. Every running service is a thing that can break while I sleep.

A word on choosing tools

Notice that almost none of this is about picking the single best tool. It is about picking tools that get out of your way and that you can replace without drama. I deliberately avoid anything that locks me in: a proprietary format I cannot export, a host I cannot leave, a framework only one company truly understands. The reason is simple. As a solo builder, my scarcest resource is attention, and every tool that demands ongoing care is a tax on it. So I optimize for boring, swappable, and well-documented over clever and trendy, every time. The best tool is usually the one you stop having to think about the day after you adopt it, and the worst is the impressive one that quietly becomes a part-time job to maintain.

The takeaway

The stack matters far less than the loop: describe, generate, read, run, commit, repeat. Pick boring, well-documented tools so your assistant is fluent in them, host on free static tiers until you have real traction, and keep your operation small enough that one person can hold the whole thing in their head. That last constraint is the real secret. Every tool I choose is chosen to protect it. When you can fit the entire system in your mind, you move fast and you sleep at night, and as a solo builder those two things are the whole game.