Budgeting as an indie developer

One of the most direct changes after I started building products myself: I have to pay for every expense myself.

AI tools, coding agents, APIs, domains, hosting, databases — each one looks inexpensive. But as a project goes on, subscriptions and usage slowly pile up, and you discover there are quite a few things to pay for.

At a company, I rarely looked closely at how much a tool cost per month, or how much a feature cost each time it ran. Now these questions all land on me.

The budget is limited, of course, but the question isn’t only about saving money.

Some tools really do let one person do what they otherwise couldn’t, and are worth investing in; some expenses look like they increase capability but actually just add allowance, steps and complexity.

So what I care about more now is:

which money is worth spending, and which only makes the product and my way of working more expensive?

First, sort out where the money goes

The costs of indie development fall roughly into four kinds.

Work tools

For example general AI, coding agents, and tools for design, research and project management.

These are usually paid monthly or yearly. The key question isn’t “is this tool good,” but whether it has entered your real workflow.

A tool having lots of features doesn’t mean you actually need them. Several tools all being able to write code, look things up and edit documents doesn’t mean each one needs a premium plan.

Product infrastructure

For example domains, hosting, databases, storage, authentication, email, analytics and monitoring.

Early in development, many services have free tiers. But free doesn’t mean you can ignore them.

At the very least, know in advance:

• where the free tier ends;
• how you’re charged once you exceed it;
• which costs scale with the number of users;
• which scale with frequency of use;
• what’s most likely to get expensive first as users grow.

The cost of running the product

AI products have a kind of expense that’s less obvious in ordinary software: every time a user uses it, the product may have to keep paying.

Models, search, scraping, voice, images and data APIs are usually charged by usage.

Say a job-search tool needs to generate a job-fit analysis. Behind it, it may read the posting, extract requirements, read the user’s history, compare the fit, generate an explanation, then do a citation check.

The user ran one task; the system may already have called many services.

So you can’t only look at what one API call costs. What you need to know more is:

what does it cost the product, on average, for a user to get one usable result?

Failures and retries count too. Model output that doesn’t pass, API timeouts, users clicking twice, agents trying again and again — all of these generate real costs.

The cost of experiments

Comparing models, tuning prompts, running evals and trying new tools all cost money.

An experiment not making it into the final product doesn’t mean it was wasted. It may help confirm:

• a certain model isn’t suitable;
• the more expensive option isn’t noticeably better;
• adding another check isn’t worth it;
• a certain workflow is too complex;
• this problem shouldn’t keep being patched with prompts.

But experiments need a question, a deadline, and a conclusion.

If you just keep rerunning things, feeling “a bit more tweaking and it’ll be better,” money easily goes into endless adjustment.

Spending more doesn’t naturally bring better results

AI products easily create certain intuitions:

• the stronger the model, the better;
• the more context, the more comprehensive;
• more rounds are more reliable;
• one more agent in the division of labor is more professional;
• one more check is safer.

These may hold, but they need verifying.

Longer context can also bring more noise; multiple agents may duplicate analysis; an extra check may just restate the same kind of error; and a premium plan may only give an inefficient workflow more allowance.

With each added cost, ask:

• What exactly does it improve?
• Can the improvement be observed or tested?
• Is this gain worth paying for long term?
• Is there a simpler way to get close to the same result?

“More capable” isn’t proof that an investment works.

Different tasks don’t need the same cost approach

Let’s keep using the AI job-search tool as the example.

Automatically scanning jobs runs often and may process a lot of information at once, but each individual posting has limited value.

You can first filter with ordinary rules like location, job title and experience requirements, then do a first pass with a cheaper model. Only postings more likely to fit go into deep analysis.

Job-fit analysis happens less often but affects whether the user applies. Here you can use fuller context, a stronger model and stricter checks.

Résumé editing usually takes several rounds. Confirmed career history can be saved; when the user changes only one item, there’s no need to reread and regenerate the whole résumé.

Budget control isn’t choosing the cheapest option everywhere, but:

saving the more expensive capabilities for the tasks that really matter.

Some cost problems are really product problems

A high API bill doesn’t necessarily mean the model is too expensive.

It may also mean:

• a flow contains too many unnecessary steps;
• the same information is processed again every time;
• clear-cut conditions are also handed to the model to judge;
• agents have no limits on stopping and retrying;
• expensive operations run automatically even when users don’t need them;
• the product does too much background work in order to seem smarter.

At that point, just switching to a cheaper model may treat the symptom, not the cause.

More effective might be to:

• not use a model for what clear rules can handle;
• pass only the context the current task needs;
• cache confirmed data and intermediate results;
• set step, retry and budget limits for agents;
• offer a preview first, and let users decide whether to run the full analysis;
• not rerun the whole flow for a local change.

Cost in turn helps you judge how complex a feature really needs to be.

Before spending, I first ask a few questions

You don’t need an elaborate approval process for every small expense, but you can at least think through:

• Does it serve the most important project right now?
• Does it solve a problem that has already happened, or one that might be useful someday?
• Can existing tools do the same job?
• What concrete change will this investment bring?
• Is it needed long term, or only for a month?
• If it’s an experiment, when does it end, and how will I judge the result?
• If it’s a product feature, how much will it keep costing each time a user uses it?
• What result has to appear before it’s worth investing more?

Being careful with money doesn’t mean buying nothing.

Sometimes saving a few dozen dollars costs you more time; sometimes upgrading a tool really does remove a persistent bottleneck.

But “investing in productivity” can’t become the justification for every expense either.

For indie developers, the more practical goal isn’t spending the least, but knowing:

why this money is worth spending, and when it no longer is.