You checked the subscription price before you launched. It looked fine. Then a usage charge showed up that you did not plan for, a domain renewal hit your card, and one evening you spent three hours untangling a broken form instead of doing anything else. Now the honest question sits in the back of your mind: what does this app actually cost me to keep alive, and is it worth it?
That question is hard to answer because the real cost is not one number on one invoice. It is spread across several places, some of it never shows up as money at all, and the largest line item is usually the one nobody writes down. This post gives you a simple way to see the whole thing. You build a cost model out of three buckets, you fill each bucket with your own numbers, and you end up with a monthly figure you can actually make a decision against.
A quick note on how Kodbe handles numbers here. We do not invent vendor prices, tiers, or "average app costs $X" figures, because those depend entirely on your tools, your traffic, and your setup. Instead, the worksheet in this article gives you the structure; supply the real numbers from your own accounts and total them using the formula shown.
Why the subscription price is not the real cost
The subscription price is the sticker you saw when you signed up. It is real, but it is only the part that was designed to be easy to see. Around it sit costs that are quieter: things that scale with how much your app gets used, things that renew once a year when you have forgotten about them, and things you pay in hours rather than dollars.
Solo owners get caught here for a simple reason. When you were building, you were focused on shipping. The recurring cost of running the thing afterward, the day-2 reality, was a future problem. Now it is the present, and the bill is arriving in pieces from different directions.
The fix is not to panic or to guess. It is to lay out every piece in one place so the total stops being a vague worry and becomes a figure. Three buckets cover almost everything.
Bucket one: hosting and infrastructure
Hosting is where your app physically lives so other people can reach it. Depending on how you built, this might be baked into the tool you used, or it might be a separate service you pay directly.
List everything in this bucket that keeps the app online:
- The platform or hosting plan your app runs on.
- Database or storage if it is billed separately from the platform.
- Bandwidth or "compute" charges, if your provider bills for traffic or processing time.
- Any backup or staging environment you pay to keep around.
If you built on an all-in-one no-code tool, several of these may be bundled into a single monthly fee, which makes this bucket simple. If you are running on more separated infrastructure, this bucket has more lines. It is worth understanding which situation you are in, because the tradeoffs differ. We cover the managed vs built-in hosting tradeoffs in more detail if you are deciding between the two, but for costing purposes you only need to do one thing: open each provider's billing page and write down what you actually pay.
Where hosting surprises people is when a plan has a ceiling. A plan might include a set amount of storage, visitors, or processing, and charge more once you pass it. Note any limit you are near, because that is where this bucket can jump.
Bucket two: tools, add-ons, and per-use services that scale with usage
This is the bucket that quietly grows. Your app probably does not run on the platform alone. It leans on a handful of connected services, and many of them charge based on how much you use them rather than a flat rate.
Common examples for a one-person app:
- Email sending for signups, receipts, or notifications.
- File storage or image handling if it sits outside your main plan.
- An AI or API service your app calls to do its work.
- A payment processor, which typically takes a cut of each transaction.
- Automation tools that connect your app to other services, often billed per task or per run.
The important feature of this bucket is that the cost moves with usage. A flat monthly plan costs the same whether ten people or ten thousand use your app. A usage-based service does not. When more people show up, some of these lines go up on their own, sometimes sharply, sometimes without warning.
How usage-based costs can surprise you
Here is the pattern to watch for, described with a structure rather than fake numbers you would only have to ignore.
Say one of your services is billed per unit of use. A single new user might trigger several of those units: an email, a couple of API calls, a bit of storage. On a slow month you barely notice. Then something drives a burst of traffic, a mention somewhere, a busy launch day, a script hitting your app in a loop, and the number of units multiplies. The bill follows. Because usage-based charges are calculated after the fact, you often see the surprise only when the invoice lands.
To cost this bucket honestly, do two things. First, write down what each usage-based service charged you last month from its real billing page. Second, note the rough rule for each one ("charged per email," "charged per 1,000 calls," "percentage of each payment") so you can reason about what happens if usage goes up. You are not trying to predict the future precisely. You are trying to know which lines are stable and which ones can move.
If you want to keep these costs from drifting out of view over time, folding this review into a routine helps. The day-2 maintenance playbook treats a regular billing check as part of normal upkeep, right alongside backups and updates.
Bucket three: your time, the line item everyone leaves out
Here is the cost that never appears on any invoice, which is exactly why it is the one most often ignored, and often the biggest of the three.
Keeping an app running takes your hours. Not building new things, just keeping the existing thing working. Over a typical month for a solo owner that can include:
- Installing updates and checking nothing broke afterward, the kind of careful work covered in update dependencies without breaking what works.
- Answering a confused user or fixing a broken flow.
- Chasing down why a charge went up or an integration stopped connecting.
- Doing your backups and your monthly checks.
- Cleaning up small messes before they become big ones, the avoidable variety in the maintenance mistakes that get expensive.
To put a number on this bucket, estimate the hours you spend in a normal month on maintenance, not on building. Then pick a value for one hour of your time. This is not a claim about what you earn or will earn, and it is not a promise of any return. It is simply the principle that your hours have worth, and an hour spent maintaining this app is an hour you cannot spend on something else. Even a modest hourly figure, multiplied by real hours, often makes this the largest bucket by a wide margin. That is the whole point of writing it down: an unpaid cost is still a cost.
If you would rather anchor the number to something concrete, you could use what you would pay someone else to do the same maintenance. Either way, the goal is to stop treating your time as free.
Hidden and lumpy costs: domains, renewals, overage, and one-off help
Some costs do not fit a tidy monthly rhythm. They are real, but they arrive in lumps, so they distort the picture if you only look at one month.
Watch for these:
- Annual renewals like your domain name or a yearly plan. A once-a-year charge feels like nothing until it lands.
- Overage charges from the usage limits you noted in buckets one and two.
- One-off help, like paying someone a few hours to fix something you could not, or a consult when you got stuck.
- Certificates, licenses, or add-ons you bought once and forgot.
The clean way to handle lumpy costs is to spread them across the year. Take an annual charge, divide it by twelve, and add that slice to your monthly total. It will not match any single invoice exactly, but it stops a big yearly bill from ambushing you and gives you a truer monthly average.
Putting it together: your real monthly number and what to do with it
Now you assemble the picture. The structure looks like this:
| Bucket | What goes in it | How to fill it |
|---|---|---|
| Hosting and infrastructure | Platform, database, storage, bandwidth, backups | Copy from each provider's billing page |
| Tools and usage-based services | Email, storage, AI/API, payments, automation | Last month's actual charges, plus each one's billing rule |
| Your time | Monthly maintenance hours | Your hours times a value you choose for an hour |
| Lumpy costs (spread) | Domains, renewals, overage, one-off help | Annual charges divided by twelve |
Add the four rows and you have your real monthly cost of ownership. Not the sticker price. The whole thing.
What you do next depends on the number:
- If it is lower than you feared, good. The worry was the fog, and the fog is gone. Keep the app.
- If your time is the big driver, the useful move may be to reduce maintenance hours: automate a chore, simplify a fragile part, or batch your upkeep into a set routine rather than reacting all month.
- If usage-based tools are the driver, watch the limits and consider whether a flat plan would be cheaper at your volume.
- If the total genuinely does not make sense for what the app gives you, that is a clear-eyed reason to change something, not a vague dread. You can now decide, because you have a figure to decide against.
One honest caveat: your number will move, especially the usage-based lines. That is fine. The value of the model is not a permanent answer. It is a habit of looking, so the next surprise is smaller and you see it coming.
In Plain English
What this means: the total cost of keeping a one-person app running is three things added together, hosting and infrastructure, tools and usage-based services, and your own time, plus a slice of the lumpy once-a-year costs. The subscription you noticed at signup is only a piece of it.
Who it helps: a solo founder, indie hacker, or citizen developer who shipped an app and now feels uneasy about what it costs to keep alive, especially after a surprise charge or a long unplanned maintenance evening.
When to use it: any time the "is this worth it?" question shows up, before you renew an annual plan, or once a quarter as a check so no bucket drifts out of sight.
What to do next: gather your real numbers from your own billing pages, estimate your monthly maintenance hours, choose a value for your time, spread your annual costs across twelve months, and add it all up. You will have replaced a money worry with a figure.
Where to go next
You have the model. Plug your own figures into the worksheet above and total the categories with the formula shown. To keep the cost from creeping back up, the monthly maintenance guide folds a billing review into your routine, and the Keep It Running hub collects the rest of the day-2 basics for owning what you built.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.