Do you need the most expensive AI to build your app?

The question usually arrives in one of two ways. Your plan runs out partway through the week and the tool asks you to upgrade or wait. Or you watch someone build a working screen with a model that costs a fraction of yours, and you wonder what you have been paying for.

For most founders the answer is that you do not need the strongest model for every part of a build. A large share of the work in any app is small and routine: changing a label, adding a field to a form, writing a test for something that already works. A cheaper model commonly does that work well enough that you would not see the difference in the result. A smaller share of the work is hard, and on that share the stronger model often earns its price.

So the useful question is which model fits which task, and the rest of this page is about answering it for your own project. It also covers the part that is easy to skip when a tool is free, which is where your code and your chats go after you paste them in.

A closed model stays with the company that made it. You reach it through that company's own app, or through a partner the company has licensed, and the company sets the price. Claude, ChatGPT and Gemini are examples of this kind at the time of writing.

An open model is one whose maker has published the model itself, so that anyone with enough computing power can run a copy. That means many hosting companies can offer the same model, and they compete with each other on price and speed. It is the main reason open models tend to cost less to use, and why some tools can offer them free up to a point. DeepSeek and Kimi are examples of this kind at the time of writing. The names will change over the years, and the two categories are likely to stay.

On quality, the general picture has been steady for a while even as the individual models change. Open models have become good enough for a large share of everyday coding. On the hardest problems they still commonly trail the top closed models. We are describing a pattern here and leaving out scores on purpose, because published rankings move from month to month and say little about how a model will behave inside your particular app.

One more point about the word open. It describes how the model is distributed. It tells you nothing about what a given app does with the text you type into it, which depends on the company running that app. An open model run by a host with careful privacy terms and the same model inside a free chat app with loose ones are different arrangements for your data.

A free AI tool is paid for somehow. Sometimes the free tier exists to bring you to a paid plan, and that is all there is to it. In other cases the payment is your data. Some free tools store your chats and use them to train later models, and some store them on servers in another country, where different laws decide who can ask to see them. Neither is hidden as a rule. It is written in the privacy terms, which most people accept without opening.

For a founder this matters more than it does for someone asking a chatbot for a recipe. What you paste while building is your source code, sometimes a sample of your customer records so the model can see the shape of the data, and sometimes a secret such as a password or an access key that happened to be in the file. If the tool keeps and trains on what you send, all of that has left your control. Paid plans differ on this too, so the check applies whichever tool you choose.

Before you paste anything real into a tool, find its privacy terms and look for the answers to the questions below. If you cannot find an answer, treat it as the less favourable one. And whatever the terms say, keep customer data and secrets out of the chat: use made-up records to show the shape of your data, and remove keys and passwords from a file before you share it.

Free tiers also have usage limits. The amounts vary between tools and change without much notice, so we will not quote any. Plan for them by keeping your project in a state where you can stop at any moment without losing work, and by knowing which model you would move to if the free one cuts off in the middle of a task.

Much of what you see about new models is a demonstration: a short video in which a model builds a game or a dashboard from a single request. Some of those videos are honest enthusiasm and some are promotion, and from the outside you often cannot tell which. Even an honest one shows a model starting from an empty project, which is the easiest condition a model ever works in. Your project is past that stage. It has existing code, decisions made weeks ago, and parts that depend on each other.

The only test that tells you much is a small one on your own app. Pick a task you already understand well enough to judge, give the same request to the model you use now and the one you are considering, and compare what comes back. Do this on a copy of the project or a separate branch so that nothing is lost if the result is poor.

A new model arrives knowing nothing about your project. It reads what it is shown and infers the rest. In a tidy codebase it infers correctly, because the patterns are consistent and it copies them. In a tangled one it guesses, and its guesses commonly differ from the previous model's, so you end up with two styles of doing the same thing in one app. That is how switching models makes a project worse, and it has little to do with which model is better.

Two habits make a switch safer. The first is version control, which means every working state of the project is saved and you can go back to any of them. Most AI builders can connect a project to a code host that does this, and it is worth setting up before you change anything else. With it, a bad afternoon with a new model costs you the afternoon. Without it, the same afternoon can cost you the working app.

The second is a short written description of the project that you give to any model at the start of a session: what the app does, how the data is organised, which libraries it uses, and the conventions you want followed. It takes a page. A model that has read it behaves far more like the one before it, and you will also find it useful the day you hand the project to a person.

The price of a model is what you pay per request. The cost of a task is that price multiplied by the number of requests, plus your own hours, plus whatever damage has to be repaired afterwards. On routine work the cheaper model wins on all of those. On a hard bug it can lose badly, because a model that does not understand the cause keeps producing confident changes that each move the problem somewhere else.

You can recognise this while it is happening. The same error returns after a fix. The model suggests something it already tried. Each change is larger than the last, and files that had nothing to do with the bug start being edited. When you see two of these, stop, restore the last version that worked, and take the problem to the stronger model with a plain account of what was attempted. Continuing with the cheaper one at that point costs more than the stronger model would have.

If the stronger model loops on the same problem too, the model has stopped being the limiting factor. The cause is usually in the structure of the project: data kept in more than one place, a sign-in flow assembled from several attempts, or a piece nobody fully understands any more. A person who reads the whole codebase can find that, and no change of model will. Our Diagnostic is a fixed-price written plan that does this reading and sets out what to repair and in what order, with the fee credited to the build if you go ahead with us. Your repo and accounts stay yours throughout.