What to self-host when your team shrinks and costs rise

Why this gets harder with a smaller team

A smaller team rarely gets a smaller job. The product still needs updates, customers still send support requests, and someone still has to watch uptime, billing, backups, and security. If your team drops from eight people to three, the work does not shrink the same way.

That is why the question of what to host yourself gets harder after cuts or a hiring freeze. You want to cut spend and reduce vendor risk, but you also have less time, less attention, and fewer people who can jump in when something breaks.

Old SaaS bills make this worse. Teams often keep paying for tools they picked when the company was bigger, moving faster, or trying every new service that looked useful. Months later, the stack still carries those costs even if half the seats sit unused and two tools do the same job.

The waste is not only in the bill. Every extra vendor adds another login, another invoice, another policy page, and another place where an outage can start. When a small team depends on many outside services, small failures stack up fast. One vendor has an auth issue, another changes pricing, and a third removes a feature your workflow quietly depended on.

A tiny team can run serious systems if it chooses carefully. Oleg Sotnikov has shown that a worldwide production platform can stay lean with the right architecture and low cloud spend. The challenge is not hosting software yourself. The challenge is choosing the few systems that cut cost and risk without creating a second operations job.

Rushed moves usually create that second job. A team sees a big monthly bill, hosts three tools itself in one week, and feels smart until the updates, disk alerts, permission bugs, and backup checks start landing at 10 p.m. Then the savings stop feeling like savings.

Small teams do better when they treat self hosting like budget surgery, not a cleanup sprint. One careful move can lower spend for years. One sloppy move can turn every weekend into on call time.

What makes a tool worth hosting yourself

A good candidate saves money in a boring, predictable way. If the bill hurts every month and the tool mostly does the same job every day, it is often a better pick than something fast moving or customer facing.

The best picks usually have stable habits. They store data in a format you can back up, restore, and test without drama. They do not need daily tuning. One person can own updates during normal work hours, follow a simple checklist, and move on.

A tool is usually a good fit when the subscription cost is obvious every month, the product changes slowly, backups and restores are easy to test, one person can patch it and check logs without losing half a day, and a short outage would be annoying rather than dangerous.

That last point matters more than most teams admit. If the tool goes down for 30 minutes, what happens? If the answer is "people wait a bit and continue later," hosting it yourself is still on the table. If the answer is "we cannot ship, charge, or pay people," keep it hosted for now.

This is why internal systems often make more sense than customer facing systems. A team wiki, error tracking, build runners, or internal dashboards can be good fits. Teams often do well with self hosted GitLab, Sentry, Grafana, and similar tools when they already know how to run backups and basic monitoring. Oleg Sotnikov has used that kind of setup in production with lean teams. It is a useful model: own the stable parts that repay the effort month after month.

If you are deciding what to move, pick the boring tool with the annoying bill, not the glamorous one. Boring pays back faster.

Systems that often make sense first

Start with tools that do the same job every day, fail in obvious ways, and have a simple recovery path. A smaller team can run a few of these well. It usually struggles when it tries to replace every hosted tool at once.

Code repos and build runners are often near the top for product teams. They are part of daily work, the cost adds up fast, and the workflow is usually clear. A self hosted repo with local or cloud runners can cut user fees and build minute charges without changing how developers work. This is one of the setups Oleg Sotnikov runs in practice with self hosted GitLab and CI/CD runners. It works because the team controls access, logs, and deployment steps in one place.

Internal docs are another easy win when the content is stable. Team guides, runbooks, onboarding notes, and architecture pages do not need fancy social features. They need search, version history, and backups. If ten people read the wiki and two people edit it, you can usually host it yourself without much drama.

Error tracking and basic monitoring also make good early moves. These tools help you keep the rest of the stack healthy, and they tend to age well. A simple setup with Sentry for errors and Grafana with Prometheus or Loki for metrics and logs gives a small team enough visibility without a pile of separate SaaS bills. Oleg uses that stack at serious scale, but a small product team can start much smaller and still get clear alerts.

Simple file sync and backup jobs fit this pattern too. Nightly database dumps, asset backups, and scheduled sync jobs are boring by design. That is good. If a job runs at 2 a.m., writes a log, and sends one alert on failure, one person can own it.

Routine automation on a fixed schedule is often safer than live workflow automation. Think invoice exports, weekly reports, cleanup jobs, or batch imports. When a process runs on a clock instead of reacting to every user action, it is easier to test and easier to fix.

A good first candidate has few surprises, clear logs, and a restore process your team can explain from memory.

What to leave hosted for now

Some systems look expensive on a monthly bill, but they get ugly fast when you move them in house. This is where most teams should start drawing lines: services where a small mistake can block paychecks, lose mail, or create legal trouble.

Email and calendars sit near the top of that list. Running your own mail server sounds cheap until you deal with spam filtering, sender reputation, device sync, and missed messages. If one person on the team spends even two hours a week babysitting mail, the savings usually disappear.

Payroll, accounting, and tax tools belong in the same bucket. These products change because laws change, not because your team wants new features. A hosted service earns its fee when it files forms on time, updates tax rules, and keeps an audit trail without extra work from you.

Customer payments are another common trap. Taking cards, handling chargebacks, and stopping fraud is its own job. A bug in your app can annoy users, but a bug in payment flow can freeze cash coming in on Friday afternoon.

Strict legal or compliance duties also push tools toward hosted vendors. If a system touches regulated records, employment data, or formal reporting, you need clear controls and steady upkeep. Small teams rarely save money by rebuilding that discipline from scratch.

One rule avoids a lot of pain: if nobody on your team can explain how a tool works today, do not host it yourself next month. First map the users, the data, the failure points, and the backup plan. Unknown systems turn into weekend chores because every problem starts with guesswork.

For most small teams, that means leaving email, calendars, payroll, bookkeeping, tax filing, payment processing, fraud checks, and heavily regulated systems where they are. The same goes for any tool your team cannot describe clearly.

Even teams that run their own code, CI, logs, and internal apps often leave these areas alone. That split is usually sensible. Put your energy where control cuts cost and risk at the same time, not where one bad configuration creates a bigger bill than the subscription did.

How to decide in one afternoon

If you are stuck on what to host yourself, start with your own bills, not a list of trendy tools. A smaller team has less spare time, so each move needs a plain reason: cut spend, lower vendor risk, or gain control over data.

Open a sheet and put every paid tool on one line. Add the monthly cost, yearly cost, and renewal date. Then write down two names for each tool: who uses it most, and who fixes it when it breaks. That second name matters. A cheap tool can still cost a lot if only one tired engineer understands it.

A fast scoring method

Give each tool a score from 1 to 5 for cost savings, how many people depend on it each week, how much hands on care it needs, how easy it is to export and restore the data, and how painful a one day outage would be.

Tools with high cost, simple backups, and low care needs usually rise to the top. Tools with messy restore steps or serious outage pain should stay where they are until your team has more time.

Do one practical check before you get excited. Export the data. Then ask whether one person can restore it on a test machine in under an hour. If not, your team does not really control that system yet.

A small product team usually sees a clear pattern once everything sits in one table. Chat may be cheap but used by everyone. Billing may be too risky to touch. Error tracking or CI runners may cost enough to matter while only one or two people need to look after them. That makes them better first candidates.

Existing skills change the math. If your team already knows tools like GitLab, Sentry, Grafana, or a simple Docker setup, the setup effort drops. Familiar tools create fewer surprises, and fewer surprises mean fewer weekend chores.

Stop after one decision. Pick a single move you can finish in 30 days, name one owner, and define success in plain terms: save $300 a month, keep backups working, and avoid extra support work.

A simple example from a small product team

A four person product team drops to two engineers after a funding cut. The team still ships, but every monthly bill starts to hurt. They do not try to host everything themselves. That would eat their weekends fast.

They leave three systems hosted: email, billing, and customer support. Email is hard to run well, billing needs trust and compliance, and support tools matter most when customers are upset. Saving a bit of money there is rarely worth the risk.

Instead, they move the tools closest to daily engineering work into one setup: source code, CI jobs, monitoring, and error alerts. This change cuts several separate SaaS bills into one predictable server cost. It also puts releases, logs, and alerts in the same place, which saves time when something breaks.

A setup like this can stay pretty small. One repo server, one CI runner, and one monitoring stack often do the job for a lean team. Oleg Sotnikov has used this kind of approach in production, pairing self hosted development and observability tools with tight cost control instead of spreading work across many paid services.

The team adds two boring habits that make the whole plan safer. They run nightly backups and check that the backup files actually exist. They also write a one page rollback note that says which snapshot to restore, where secrets live, how to pause deployments, how to switch traffic back to the old container, and where to check logs after recovery.

Because the setup stays narrow, upkeep stays narrow too. One engineer spends about an hour a week on updates, backup checks, and cleaning old CI artifacts. That is a fair trade if the team drops a few recurring subscriptions and keeps control of its code and build pipeline.

The lesson is plain: host the tools your team touches every day, but only if you can keep the stack small enough that one tired engineer can still manage it on a Tuesday afternoon.

Mistakes that create weekend chores

Most self hosting trouble starts with speed. A small team gets tired of SaaS bills, moves three or four systems in one push, and turns a cost project into an operations mess.

The first mistake is stacking migrations. If you move source control, CI, docs, and monitoring in the same month, you lose your baseline. When something breaks, nobody knows which change caused it. A smaller team should move one system, let it run for a week or two, and then decide on the next one.

Backup and restore is the second trap. Teams often check whether a tool can export data, but they never test a real restore. Those are not the same thing. A backup that takes two hours to recover, or needs five manual fixes, will ruin a Saturday fast.

One weak machine creates the next problem. It looks cheap to run everything on one box until that box fills its disk, loses power, or needs a kernel update. Then chat, CI, internal docs, and logs disappear together. Even a lean setup needs some separation, or at least a clear plan for what can go down without stopping the whole team.

Updates cause a lot of pain because people treat them like routine chores instead of small changes with risk. They click upgrade, skim nothing, and hope for the best. Then an auth setting changes, a plugin breaks, or a database migration hangs halfway through.

A few habits prevent a lot of this. Read the release notes before you update. Write down the rollback steps. Test a restore on a spare instance. Keep recent config changes in version control. Schedule updates when the owner is awake and available.

Alerts can be just as bad. Teams set up disk, CPU, SSL, and backup alerts, but nobody owns them. The result is either constant noise or silent failure. An alert without a name next to it is just background stress.

A better rule is simple and effective. Every system needs one clear owner, one restore test, and one reason to exist. If you cannot name all three in a minute, do not move that system yet.

That is usually the line between a smart decision and a homegrown mess. The goal is not to host more. The goal is to host the few things your team can run calmly on an ordinary Tuesday.

Quick checks before you move

Before you decide what to host yourself, test the boring parts first. Cost cuts look good on paper, but the wrong move gives you a cheaper bill and a worse week. A small team needs tools that stay quiet most of the time and recover fast when they do not.

Try a restore before you migrate. Take a recent backup, put it on a spare machine or local VM, and see if you can bring the service back with real data. If the restore fails, takes half a day, or depends on one person remembering odd steps, you are not ready. Backups only count when someone can use them.

Then check upkeep. One person should be able to update the tool, scan logs, and roll back in under 30 minutes. That sounds strict, but it quickly rules out software that turns every patch into a small project. If your only admin needs a Saturday to do upgrades, the monthly saving is probably fake.

A short outage should also be boring. Ask a plain question: can the team keep working for an hour if this tool disappears? A wiki or error tracker can usually wait. Auth, payment systems, and the main production database usually cannot. Start with tools that fail softly before you touch the ones that stop sales or support.

Write down five things on one page: who owns the tool, where backups run and how often, what alert tells you it is down, how to update it, and how to roll it back.

Then do the math honestly. Include setup time, upgrades, storage, monitoring, and the cost of the person who will babysit it. A tool that saves $200 a month but eats four hours of skilled time is not saving money.

Lean teams do better when the stack stays small. Oleg Sotnikov often pushes architecture level cost cuts before adding more moving parts, and that logic fits here too. If you cannot restore the data, update the service fast, survive a short outage, and name a clear owner, leave it hosted for now.

Next steps for a leaner stack

Start small. If you move three systems at once, nobody knows what broke, who owns it, or whether you saved money.

Pick one system with a clear owner. Good first candidates are tools your team uses every day, understands well, and can live without for a short maintenance window. A shared password vault or your source control runner setup may be easier to manage than a customer facing app.

Write one plain page before you move anything. Keep it boring and useful. It should answer four questions: where the data lives, how backups run and how you test a restore, who installs updates and how often, and who gets alerts when the service fails.

That page does more for a small team than a fancy diagram. When someone gets sick or leaves, the work does not disappear with them.

Then give the change 30 days. Track two numbers: real monthly cost and support time. Cost is easy to see. Support time is where bad self hosting choices usually show up. If a tool saves $300 a month but steals six hours of senior time, the math may be worse than it looks.

A simple rule helps: keep the move if it cuts spend, lowers vendor risk, and does not create late night babysitting. If it fails one of those tests, roll it back or keep it hosted.

Messy stacks often need a second pair of eyes. That is especially true when a team has old servers, duplicate SaaS tools, or half finished migrations. If you need that kind of review, Oleg Sotnikov at oleg.is works with startups and small businesses as a fractional CTO on lean infrastructure, AI first development, and practical decisions about what to host yourself and what to leave hosted.

The best next move is usually small. One owner, one system, one short runbook, then a 30 day check. That is enough to make your stack lighter without turning your weekends into ops duty.