The AI Tools I Actually Use to Build Apps

Why a small stack works better

Most advice about AI tools for building apps tells you to try everything. That is exactly what slows people down.

I've started projects and abandoned them — not because the idea was bad or the tools were broken, but because I couldn't keep track of what I had built, where I had built it, or which tool I had used for which decision. Once the stack went beyond three tools, it stopped feeling like building and started feeling like administration.

I've also had to restart builds — not because they couldn't be finished, but because I realised too late that the approach I had taken wouldn't hold up or would take more effort to maintain than the thing was worth. That is a different kind of waste, and it is just as discouraging.

Three tools became the working limit. Enough to build real things. Not so many that nothing gets finished. If you are trying to figure out which AI tools to use to build apps, the right answer is almost certainly fewer than you think.

ChatGPT for planning and clarity

I use ChatGPT at the very start of a build — not to build the app, but to get the idea clear enough that building it becomes straightforward.

A rough idea is almost always too vague to act on directly. I use ChatGPT to work through it: who is this for, what does it actually do, why would someone use it, how should it behave. That conversation turns a vague direction into something concrete enough to prompt properly. From there I ask it to break the idea into parts — what to build first, what comes after, how the basic structure should hold together.

The limitation is that ChatGPT does not handle ongoing builds well once things become complex. Each session tends to feel like a fresh start. That is fine for thinking and structuring — it is not the right place to actually construct something. I treat it as a starting point and move on quickly.

Claude for Building

Claude is where I build the app. If you prompt it properly, you can work through a project in sections — building one part, testing it, then moving to the next. That gives you a level of control that most tools do not offer. Instead of generating everything at once and then untangling what came out, you build incrementally and know what you have at every stage.

It is also much better than ChatGPT at continuing a project across sessions. You do not feel like you are restarting every time. You can build on what already exists, which is essential once a project has any real complexity.

The main constraint is credits. It is easy to burn through them if you go off track mid-build, try too many variations, or change direction without having a clear plan first. That is exactly why I use ChatGPT to think before switching to Claude to build — a clear brief before you start makes the credits go much further and produces better results.

Replit for Launching

Replit is where the project goes live. I use it when an app needs a database, backend functionality, or needs to run online rather than just locally in a browser.

The important detail is that I do not start in Replit. I build as much of the project as possible using ChatGPT and Claude first, then move it across. Replit can read existing code and help complete what is missing — which means you are not rebuilding inside the platform, you are finishing inside it. That saves significant time and credits.

It is not always smooth. Error messages can be unclear, GitHub updates do not always sync reliably, and occasionally a project needs to be re-uploaded or duplicated to get things working. It works — but it requires patience and a certain willingness to debug without always knowing exactly why something broke.

How the stack works together

The tools matter less than the order in which you use them. The workflow is what makes the stack actually function:

1. Break the idea down in ChatGPT. Start with what the app does, who it is for, and why it matters. Get it to split the idea into concrete build steps — what comes first, what comes after, how the structure should look.
2. Build incrementally. Do not try to generate the entire app at once. Build one part, test it, then move to the next. This applies in both ChatGPT and Claude.
3. Switch to Claude once the structure is clear. When the project becomes more defined, Claude handles the actual construction better. Use it to build out features step by step, improve structure, and continue the project across sessions.
4. Move to Replit to launch. Once the core app works, push it to GitHub and bring it into Replit. Use Replit to connect databases, fix deployment issues, and run the app online.

The workflow is not rigid — some builds skip Replit entirely if they run in the browser. But the principle holds: think first, build second, launch third. Jumping ahead is where most builds get stuck.

If you are still unsure which tool to start with for your specific situation, read how to choose the right AI tool.

Why I don't use more tools

Using more AI tools sounds like it should produce better results. In practice it usually produces more unfinished projects.

I have made this mistake. Starting something in one tool, moving to another because it looked better, losing track of what was built where, and eventually abandoning the whole thing without finishing. The problem was not the tools — it was that there were too many of them and no clear system for using them together.

If you are currently using five or more tools and not finishing things, the answer is almost certainly not to add another one. Simplify instead. Ask yourself where you have actually completed something, which tool made it easier to keep going, and where you stopped halfway. Use those answers as your filter — not marketing materials, not feature comparisons, not what other people are using.

The goal is not an impressive stack. It is a finished product. Even a build that does not fully work teaches you more than a dozen builds abandoned at the halfway point — because finishing forces you through the whole process: idea, build, test, launch. Skipping the end means skipping the part where the real learning happens.

A Real Example

One of the apps I built using this stack is a spending tracker. The idea was straightforward: a tool to show where money was going and whether spending was drifting upward, without connecting to any bank account or storing data anywhere external.

I started by structuring the idea in ChatGPT — who it was for, what it needed to do, what it should not do. Then I used Claude to build it section by section, testing each part before moving forward. I focused on functionality first and only improved the design once the core logic worked. The result is a tool that runs entirely in the browser, requires no setup, and stores everything locally.

The full breakdown of that build — what was built, what was cut, and why — is here: Spending Tracker Case Study. For more examples of the same approach applied to different problems, see all real builds.

Where this stack breaks

This setup works well for small to medium apps. It starts to break down in specific situations: when you need complex backend systems with significant infrastructure, when you try to build everything in a single session rather than incrementally, or when you rely on the AI output without testing each section before moving forward.

The stack is also not suited to large team projects or anything with serious production requirements. It is a solo or small-team workflow for building focused tools that solve one specific problem. For that scope, it works well. For anything beyond it, you will hit limits quickly.

Start with a small stack

You do not need more tools. You need a workflow that lets you finish what you start. Pick the tools where you have actually completed something before, keep the stack small enough that you can hold the whole system in your head, and focus on getting one build to the end rather than starting three.