Self-hosting cost after the free tier ends: what to count

Why this decision gets expensive fast

A free plan often hides the hardest part of the bill. You see a license price of zero, or close to it, and the tool feels cheap. Then the limit changes, the free tier shrinks, or your team simply grows past it.

That is usually when the real self-hosting cost shows up. Before, the vendor handled the work. Now your team does.

The trigger is rarely dramatic. A product adds seat limits, cuts storage, caps monthly usage, or locks basic features behind a paid plan. A small SaaS team can cross that line in one normal quarter just by hiring two people, keeping more logs, or serving more customers.

At first glance, moving in-house can look obvious. If the hosted plan costs $800 a month and a cloud VM costs $120, the savings seem easy to spot. They usually are not real savings.

Someone has to install the tool, move the data, set access rules, monitor disk space, handle updates, and fix breakage after version changes. Each task looks small on its own. Together they add up fast. A few hours a week can wipe out the license savings before anyone notices.

This gets worse when the team doing the move is already busy. An engineer pulled into maintenance work is not shipping product work, fixing customer issues, or improving onboarding. The line item moved off the software budget and landed on payroll.

Write down the reason for the move before you touch a server. If the reason is cost, state the monthly target. If the reason is control, name the exact control you need. If the reason is compliance, spell out the rule. A vague goal like "own our stack" usually turns into expensive side quests.

Teams that make good self-hosting decisions start with one plain question: what problem are we trying to solve, and what will this move cost in work every month after setup is done?

Where the money actually goes

Most teams compare the vendor bill to a server invoice and stop there. That misses half the spend, and it makes self-hosting look cheaper than it will feel by month three.

Start with the bill you already pay today. Use the real monthly average from the last six to twelve months, not the cheapest plan shown on a pricing page. Include extra seats, overage fees, premium features, and any add-ons that quietly became normal.

Then price the new home for the workload. That usually means compute, storage, backups, bandwidth, load balancers, snapshots, and a bit of spare capacity so one busy day does not knock the service over. Do not forget growth. A database that fits on a small disk now may need much more space once logs, attachments, and retention rules pile up.

A basic cost sheet should cover the current subscription bill, servers or containers, storage and backups, outbound bandwidth, and the services around the app such as monitoring, alerting, security, and support.

Those last items deserve their own line, not a footnote. If you self-host, you still need uptime checks, logs, error tracking, metrics, alerting, secrets management, vulnerability scans, and sometimes a WAF or DDoS protection. Some teams can piece together part of this with open-source tools, but those tools still need time and hardware.

Paid support matters more than people expect. If the database corrupts itself after an upgrade at 2 a.m., do you want a forum thread or a support contract with a response target? Many companies buy support only after the first ugly incident, which is the most expensive time to learn they needed it.

If you want a number that holds up in real life, treat every service around the app as part of the bill. The app is only one line item. The rest is what keeps it alive.

Count the work nobody budgets

The license bill is easy to see. The labor bill is where self-hosting usually goes sideways.

Most teams count server prices and stop there. They forget the first month of setup, the steady drip of upgrades, and the hours lost when a deploy breaks at 9:40 p.m. Those hours are real costs, even if nobody sends an invoice for them.

For a small SaaS team, a simple first-month estimate often lands somewhere in the 26 to 50 hour range. That includes installing and securing the service, wiring up backups and monitoring, setting up users and access rules, writing basic docs, and fixing the surprises that show up after the first real traffic hits. If your infrastructure habits are weak, the number climbs fast.

After launch, the work keeps showing up in small chunks. A patch needs testing. A minor version upgrade changes a setting. A certificate expires. A deploy passes in staging and fails in production. None of this sounds dramatic on its own, but it can easily eat 6 to 15 hours a month.

Support work belongs in the same spreadsheet too. Someone still has to answer questions, fix access issues, check failed jobs, and clean up the odd problem after launch. That work is easy to ignore because it arrives in fragments, but it still takes time.

Build a simple monthly comparison

A one-month snapshot lies to you. Use 12 months, even if the numbers are rough, because the expensive parts often show up later: upgrades, storage growth, backup retention, and the weekend problem nobody planned for.

Set up two plain columns in a sheet. One is "stay hosted." The other is "self-host." Keep it boring and direct. Fancy finance models usually hide the cost instead of making it clearer.

For the hosted side, include the obvious bill plus the extras people forget: subscription or usage fees, support plan changes after the free tier ends, overage charges for storage, seats, or API calls, and any migration work needed even if you stay with the vendor.

For the self-host side, count cash and time in the same table. Add servers, storage, bandwidth, backup space, monitoring, logging, upgrade labor, on-call time, incident response, and restore drills.

Start with rough numbers, then pressure-test them. What happens if usage doubles in six months? What if one upgrade goes badly and two engineers lose half a day fixing it? What if backups pass quietly for months, then fail when you need a restore?

A small SaaS team can do this in under an hour. Put monthly estimates in first. Then add one or two ugly but realistic events across the year, like a failed upgrade, a storage spike, or a restore drill that takes longer than expected. That usually changes the picture fast.

Do not review the sheet alone. Show it to the people who will actually run the system. Finance can check the spend, but engineers and operators will spot missing work in minutes. If they look at the self-hosting column and laugh, your estimate is still too low.

Add pager risk to the total

A self-hosted service does not stop costing money when the invoice gets smaller. If it wakes someone up at 2 a.m., that belongs in the math too.

Start with one plain question: who carries the phone at night? If the answer is "the founder," "the lead engineer," or "whoever notices Slack first," you already have a real cost. That person loses sleep, loses focus the next day, and often loses a few hours of planned work.

A simple estimate is enough. Count how many after-hours alerts you expect each month, guess how many need real action, put a rough price on each interruption in time and fatigue, and add the cost of any customer-facing downtime.

Be honest about alert volume. A noisy system might fire ten alerts in a month, but only two incidents can still wreck a week if they hit at the wrong time. One database issue on Saturday can erase a planned release, push support tickets into Monday, and drain the person who had to fix it.

Sleep loss has a price even if no one sends an invoice for it. If an engineer loses three hours at night, you rarely get a full workday from them the next morning. They move slower, make worse calls, and postpone other tasks. On a small team, that delay spreads fast.

Downtime adds another layer. Staff may sit idle while one person repairs the system. Customers may hit errors, abandon a task, or send urgent messages that pull more people into the problem. For a SaaS product, one rough evening can affect support, sales, and trust at the same time.

This part of self-hosting cost is easy to hide because it lands in calendars and energy, not in a vendor bill. Count it anyway. If the savings are only a few hundred dollars a month, even one bad night can wipe them out.

Test backups before you trust them

Backups look cheap until you need one. A nightly job that writes files somewhere is not the same as recovery, and this is where self-hosting cost often gets understated.

Start with one plain question: what must still exist after a bad day? For most teams, that means more than the main database.

What you need to save

Back up the parts you cannot rebuild quickly: the production database, user uploads and generated files, app config and environment settings, billing or audit records, and the scripts or notes needed to bring the app back up.

Teams miss this all the time. They back up Postgres, then learn too late that invoices lived in object storage and API keys lived on one old server.

Pick a schedule your team can keep without drama. If data changes all day, a weekly dump is usually too thin. If your app changes slowly, hourly backups may be too much. Match the schedule to the cost of losing data, then check that storage, retention, and copy time fit your budget.

A backup plan is only real after a restore drill. Use a real system, not a thought exercise. Restore the latest backup to a separate machine or test environment, start the app, sign in, and verify that recent records appear where they should.

Do this on a calendar, not when someone remembers. Once a month is a decent start for many small teams. After each drill, write down how long recovery took and what broke.

One small SaaS team learned this the hard way: the backup job ran every night, but nobody noticed it had skipped file attachments for three weeks. The database came back fine. Customer documents did not.

Failed backups need an owner. Put one name on the check, one backup person behind them, and one simple rule for escalation. If a backup fails, who sees the alert that day? Who confirms the rerun worked? Who records the gap?

If those names are missing, the backup plan is wishful thinking, not protection.

A simple example from a small SaaS team

A 12-person team runs one B2B product. They used a hosted tool for source control, CI, error tracking, and internal docs while usage stayed inside a generous free tier. Then the customer base grew, logs increased, build minutes jumped, and the monthly bill moved from about $900 to $2,600.

The team looked at a small server stack instead. On paper, it seemed like an easy win.

Their planned monthly costs looked like this: $540 for three cloud servers, $140 for backup storage and snapshots, $170 for monitoring, email, and extra bandwidth, about $600 for six hours of routine admin work, and $240 for a monthly restore drill involving an engineer and QA. That put the expected total near $1,690.

Against a $2,600 SaaS bill, the saving looks real.

Then normal life hits. In the first quarter after the move, the team had two weekend incidents. One Saturday, a disk filled during a log spike and stopped deployments for four hours. Three weeks later, a failed package upgrade broke the CI runner and blocked releases until Sunday night.

Those two incidents used about 14 hours of engineering time, plus a few hours from support and QA on Monday to check delayed jobs and customer reports. At $100 an hour, the quarter picked up roughly $1,700 in extra labor, or about $567 a month when you spread it out.

Now the monthly picture changes. The planned $1,690 becomes about $2,257. The team still pays less than $2,600, but the gap is small, and one more bad month wipes it out.

The restore drill matters too. It does not feel urgent, so teams often skip it. That is a mistake. A three-hour practice every month is cheaper than learning during an outage that the backup exists but the restore script fails.

Mistakes that make self-hosting look cheap

Self-hosting looks cheap when the spreadsheet compares one old license bill to one new server bill. That is the most flattering version of the math, and it is usually wrong. The real cost shows up after launch, when the system needs care every month.

A common mistake is treating setup as the hard part and upgrades as minor housekeeping. They are not. Every major update can mean reading release notes, testing in a safe environment, checking database changes, planning downtime, and keeping a rollback path ready. A job that looked like "two hours on Friday" can eat most of a day when one package breaks authentication or changes storage behavior.

Teams also assume one person can carry the whole thing. That works until the first late-night alert, a vacation, or a sick day. If only one engineer understands certificates, backups, database recovery, and the app itself, you do not have coverage. You have a single point of failure with a pager.

The usual missing costs are upgrade time, testing and rollbacks, a second person who can respond to incidents, restore drills, and the work needed to keep alerts and logs useful instead of noisy.

Backups create another false sense of safety. A copy sitting in object storage is not proof that recovery will work. You need restore drills into a clean system, with real credentials, real permissions, and enough time to see what breaks. Many teams learn too late that they saved corrupted data, missed one database, or cannot restore fast enough for the business.

Another bad comparison is license cost versus hosting cost only. That leaves out labor, on-call stress, offsite backup space, security patching, and the hours spent babysitting a system that used to come managed. For a small SaaS team, saving $800 a month on licenses can look smart until upgrades eat 10 engineer hours and one weekend incident wipes out the savings.

If you want an honest number, count the machines, the people, and the bad nights. All three belong in the same total.

Quick checks before you approve the move

Approval should wait until someone answers four boring questions with numbers, names, and a test date. That sounds strict, but this is usually the point where self-hosting stops looking cheap.

A free tier can hide work for months. Once limits hit, the bill does not disappear. It often moves from a software invoice to engineer hours, late-night alerts, storage, and recovery work.

Ask who installs updates every month, how long it takes, and who rolls back if the upgrade breaks something. Put a real name on alerts during weekends and holidays, plus a backup person when that person is away. Run a restore drill from a recent backup to a clean machine and write down how long recovery takes. Then compare the removed license fee with the new hosting bill, labor time, monitoring, backup storage, and incident time.

Monthly updates matter more than teams think. Many tools ship security fixes, database changes, and breaking version jumps. If one update takes three hours to plan, apply, check, and document, that is not free. If it takes a full engineer day because something fails, your savings can vanish fast.

Holiday coverage is another reality check. Alerts do not care about vacation plans. If nobody owns the pager on December 26, the system is underfunded, not efficient. A simple rotation with a backup person is usually enough, but it needs to exist before the move.

Backup testing is the bluntest check of all. A backup file is only a promise until someone restores it. Teams often feel safe because backups run every night, then panic when they learn the database dump is incomplete or the app cannot start without a missing secret.

One rough rule works well: if the move saves $500 a month in license fees but adds even 8 to 10 hours of skilled labor, you may have only moved the bill. If you cannot answer these checks clearly, wait a week and get the missing numbers first.

What to do next

Pick the least risky system first. An internal tool, a staging service, or a small customer-facing service with clear limits usually gives you a better read than moving everything at once. If the first move goes badly, you lose a week, not a quarter.

Moving your whole stack at once is how teams talk themselves into a bad setup. Start with one system, write down the current monthly bill, then track the real self-hosting cost after the move. Include labor, alerts, backup checks, and time spent on upgrades. The license line is only part of the bill.

A simple rollout plan works well. Choose one system with low blast radius. Keep the hosted version available for rollback. Assign one person to own upgrades and backup drills. Review costs and incidents after two months.

That review matters. The first weeks often look cheap because nothing major has broken yet, nobody has handled a painful upgrade, and backups have not been tested under stress. By the second month, you usually have enough real data to decide whether the move saves money or just shifts the spend into late nights and slow recovery.

Keep your rollback option longer than feels comfortable. If the self-hosted version starts eating team time, switch back fast and treat that as useful data, not failure. A reversible decision is safer than a brave one.

If the numbers still feel fuzzy, get a second opinion before you approve a wider migration. Oleg Sotnikov at oleg.is helps startups and small teams review architecture trade-offs, rollout plans, and operating costs as a Fractional CTO. A short outside review can stop a cheap-looking move from turning into a full-time maintenance job.