An indie developer's monthly expenses

If you asked me right now how much I spent building products last month, I might have to go through my bank card, the App Store, email receipts and several service dashboards to slowly piece it together.

The costs are scattered in different places:

• tools on monthly or yearly subscriptions;
• usage-based bills for APIs and cloud services;
• accounts upgraded temporarily;
• domains, templates and one-off purchases;
• services I’ve forgotten about that are still auto-renewing.

When I pay each one, I usually know why.

But a month later, looking back, I may no longer be able to say what exactly it supported, or whether I still need it next month.

So besides judging before spending, I think indie developers need a fixed routine:

review work expenses once a month.

It isn’t simple bookkeeping, nor a mass cancellation of subscriptions, but checking: where did this month’s spending go, what did it get back, and how will I adjust next month?

Step one: find all the real expenses

First put all costs related to indie development in one place:

• AI and development tools;
• APIs and third-party services;
• hosting, databases and storage;
• domains, email, analytics and monitoring;
• one-off purchases;
• experiments and temporary upgrades.

Annual tools can be converted into a monthly cost.

Otherwise, they only look expensive in the month you pay, and seem completely free the rest of the year.

Also watch out for:

• automatic charges after free trials end;
• scattered subscriptions in the App Store or Google Play;
• payments in different currencies;
• tools you rarely use but that are still renewing;
• costs on general accounts that are actually for a particular project.

This step answers only one thing:

what does keeping my current way of working actually cost per month?

Step two: assign expenses to specific projects

The total only shows how much was spent, not whether it was spent sensibly.

Each expense should ideally map to:

• which project;
• which stage;
• which specific piece of work;
• what result it produced.

A very simple table will do:

Expense	Project or purpose	Result this month	Decision for next month
Coding agent	Main project development	Finished the phase’s features, but hit the limit several times	Consider upgrading
Model API	Output-quality evals	Found the main failure modes	Keep the budget
UI tool	Trying page designs	Didn’t make it into the real product	Cancel
Database	Product infrastructure	Current usage is very low	Check whether it can be downgraded
Backup AI tool	Used when the main tool is limited	Used only once this month	Keep the free plan

Two situations often show up here.

One is a tool that’s great to use but isn’t serving the most important work right now.

The other is a tool used very often, while the project doesn’t visibly move forward.

Calling a coding agent every day doesn’t mean the development investment is necessarily effective. It may have completed important features, or it may just be endlessly redoing and rewriting.

“Used a lot” only shows consumption, not return.

Step three: see what the money got back

Before an early product has revenue, you can’t judge expenses only by “how much money it made back.”

A piece of spending can bring three kinds of return.

Output

For example:

• finishing a feature or a phase;
• making a demo that can be tested;
• launching a version;
• completing a round of user validation;
• getting material ready to deliver;
• completing work one person couldn’t have done alone.

“Improved efficiency” is too vague. Better to pin down what was actually completed.

Learning

Some experiments weren’t kept, but helped rule out wrong directions:

• a certain model isn’t suitable;
• a certain need isn’t worth pursuing;
• the more expensive option wasn’t better;
• a workflow is too complex;
• the problem can’t be solved by more prompt tweaking.

As long as the conclusion changed the next step, the experiment was worth paying for.

If you just tried something, felt it was “OK,” and neither adopted nor stopped it, it’s hard to say what you got.

Reduced risk

Some expenses don’t directly produce features, but can prevent bigger problems:

• backups;
• monitoring;
• error alerts;
• security checks;
• a test environment;
• API usage caps;
• data recovery.

Even if these weren’t triggered this month, they shouldn’t necessarily be canceled. It depends on whether the risk they guard against is real, and whether there’s a reliable alternative.

If an expense brought no output, learning or reduced risk, you need to think seriously about why you’d continue it.

Step four: review not only tools, but projects too

A monthly review easily turns into clearing out subscriptions.

But sometimes what really needs to stop isn’t a tool, but the way you’re investing in a project.

You might find that:

• every tool is in use;
• every API call has a purpose;
• you’re working steadily every day;
• but the project isn’t getting closer to launch, hasn’t gotten user feedback, and hasn’t resolved its key uncertainties.

Then the question to ask isn’t “which subscription should I cancel,” but:

is this project still worth investing in like this next month?

You can check by project:

• how much it cost in total this month;
• whether the money went mainly to development, experiments or running costs;
• what was completed;
• what new evidence was gained;
• what the most expensive part is;
• what result you hope to get from investing another month;
• if you don’t get it, whether you’ll shrink, pause or stop.

A project constantly generating work doesn’t mean it’s constantly generating value.

Features, documents and call volumes all keep growing, but if you’re not getting closer to users, launch or a clear conclusion, the next phase should change.

Step five: check whether you’re paying for repeated work

Besides overlapping tool features, also check whether the work itself is being done repeatedly.

For example:

• the same question goes to several models by default;
• confirmed information is extracted again and again;
• a lot of background is passed in afresh every time;
• two coding agents analyze the same part of the code;
• a local change regenerates the whole document or product;
• you run it once more by default because you’re not comfortable.

Cross-checking is valuable, of course, but it needs a clear purpose.

Is the second call verifying facts, looking for counterexamples, or just hearing an answer again?

If you can’t say, repeated calls are probably just turning anxiety into cost.

Step six: give every expense a decision

The result of the month-end review shouldn’t just be a log.

Each expense should ideally move into a clear status:

Keep

It steadily supports important work, and the current plan fits.

Upgrade

A clear, recurring and important bottleneck has appeared, and upgrading directly solves it.

Downgrade

The tool is valuable, but current usage doesn’t need the current plan.

Cancel

It hasn’t entered your real workflow, heavily duplicates other tools, or doesn’t serve the current focus for now.

Cap

The service is still needed, but its usage-based costs need a budget, alerts or usage rules.

Watch for one more month

There isn’t enough information yet, but write down what you’ll look at next month; it can’t stay “later” forever.

The project itself can get a decision too:

• continue;
• shrink the scope;
• pause development;
• validate first;
• stop after finishing this phase.

Step seven: set next month’s budget

A review can’t only explain the past.

Finally, decide how you’ll invest next month:

• which fixed subscriptions continue;
• budget caps for APIs and cloud services;
• how much to set aside for experiments;
• which project gets budget first;
• which services to cancel or downgrade;
• what result has to appear before you can invest more;
• what result, if it doesn’t appear, pauses the next round of spending.

That way, next month’s budget isn’t this month’s bill copied automatically, but rearranged based on this month’s results.

A simple template is enough

At the end of each month, you can record the following.

This month at a glance

• Fixed subscriptions:
• Usage-based calls:
• Infrastructure:
• One-off spending:
• Experiments:
• Total:
• Change from last month:

By project

• Project:
• Spending this month:
• Work completed:
• Validation or conclusions gained:
• Biggest cost:
• Decision for next month:

By tool and service

• Name:
• Amount:
• Work it supported:
• Output, learning or reduced risk it brought:
• Whether it duplicates other tools or work:
• Decision for next month:

Anomaly check

• Which costs grew noticeably?
• Were there failed retries or wasted calls?
• Are there services you forgot to cancel?
• Are you buying ahead for capabilities you’ll only need later?
• Are you using a higher plan to cover up a workflow problem?

Plan for next month

• Fixed budget:
• API cap:
• Experiment budget:
• Priority project:
• Items to cancel or downgrade:
• Conditions for investing more:

A monthly review isn’t about proving every dollar was spent correctly.

Indie development requires trial and error, and you can’t know in advance whether every tool and direction will work.

Its more practical use is making sure money, once spent, doesn’t simply vanish without a trace.

At the end of the month you should at least know:

• where the money went;
• what it got back;
• which investments should continue;
• which need to stop in time;
• where you plan to put the budget next month.

And what you ultimately need to judge isn’t just whether a certain tool is worth renewing.

It’s:

is the way I’m building products right now still worth investing in like this?