What infrastructure should a small company own first?

Why this choice gets expensive fast

When people ask what infrastructure a small company should own, the cost problem usually starts before anyone notices it. A service looks cheap at first, the setup takes an afternoon, and the first bill feels harmless. Six months later, usage grows, limits appear, and the monthly spend no longer matches the original plan.

This happens because many managed tools charge for the parts that grow fastest. Storage creeps up. Build minutes run out. Log volume spikes after one noisy release. A team that expected to spend a few hundred dollars a month can end up paying several times that, even without a big jump in revenue.

That low starting price is what makes the choice tricky. It feels safer to avoid owning anything early, but some services are easy to adopt and expensive to keep. Once your app, data, alerts, backups, and internal habits depend on one vendor, the bill stops being a simple line item. It starts shaping product, hiring, and support decisions.

Moving later often costs more than planning earlier. Data has to move. Scripts break. The team has to learn a new setup while still shipping features and helping customers. If the service touches production, even a careful migration can burn days of support time and create stress nobody planned for.

Cash flow feels this first. A rising infrastructure bill can delay a hire, shrink the testing budget, or force the founder to keep doing ops work instead of sales or product work. Support feels it too. Time spent chasing limits, overages, or surprise usage patterns is time not spent fixing customer problems.

A small company does not need to own everything. It should look closely at the systems that run every day, grow with usage, and punish pricing swings. Those are often the first places where ownership saves money and gives the team a calmer month.

What it means to own infrastructure

Founders often hear "own infrastructure" and picture servers. That is only part of it. You own infrastructure when your team sets it up, changes it, watches it, fixes it, and carries the risk when it fails.

A simple test helps. If your team can log in and change how a system runs day to day, that system is part of your infrastructure. If you can set access rules, tune performance, add capacity, inspect logs, run backups, and restore data, you own that layer in practical terms.

Count the systems your team actually operates, not just the ones you pay for. The list often includes compute, databases, storage, queues, caches, monitoring, logs, secrets, backups, and scheduled jobs. Small teams forget about monitoring and backups all the time, but those systems still need setup, testing, and cleanup.

Ownership also comes with routine work. Someone has to patch the system, rotate secrets, check alerts, test restores, and decide what happens during an outage. If nobody on your team does those jobs, you do not really own that part, even if the invoice comes to you.

It also helps to separate infrastructure from business software you simply subscribe to. Your payroll tool, CRM, accounting app, and support desk may matter a lot, but they are usually services you use, not infrastructure you run. You manage users and billing there. You do not manage the database engine, storage layer, or recovery process behind the product.

Some tools sit in the middle. A managed database may still count as infrastructure if your team controls schema changes, access, retention, backup checks, and scaling choices. The vendor runs the lower layers, but your team still operates the service in daily work.

Write this down in plain language. For each system, note what your team controls without opening a support ticket, what the vendor controls, and who gets paged when it breaks. That list is usually more useful than a tidy diagram because it shows where ownership is real and where it only feels real.

Start with work that never stops

Start with the parts of your stack that run all day and barely take a break. Those workloads give you the clearest numbers on cost, staff time, and failure risk.

Good first candidates usually have steady demand. They use about the same CPU, memory, disk, and network every week, so you can size servers with less guesswork. A production database, internal CI runners, logging, monitoring, and a core app backend often fit this pattern better than batch imports or one-off campaign projects.

A simple rule works well: if the service runs every day, has predictable load, and your team touches it often, ownership is easier to justify. A database that serves your app around the clock, build runners used on every merge, monitoring dashboards checked every week, and storage that grows steadily are all better candidates than something that wakes up once a quarter.

These systems also teach the right habits. When people already know how to back up a database, rotate logs, watch disk use, or restart a service safely, they make fewer expensive mistakes. Familiar systems are a better place to start than something nobody wants to babysit at 2 a.m.

That is one reason experienced operators often keep daily tools close. Oleg Sotnikov, for example, runs self-hosted CI/CD, observability, and production systems in client environments because those tools get used constantly and repay careful tuning month after month.

Leave bursty work for later. A once-a-quarter analytics job, a Black Friday traffic spike, or an experimental AI feature can stay on managed services longer. Those workloads are harder to size, and cloud pricing can still make sense when usage jumps around.

Own the boring, constant parts first. They are easier to measure, easier to learn, and usually cheaper to run well over time.

Look for pricing that swings against you

A low starting price can hide the worst kind of cost: the kind that jumps when your business is finally growing. Managed services often look cheap at small scale, then turn into a monthly surprise when billing depends on requests, seats, events, or stored data.

Per-request pricing can punish success. If your app gets more traffic, every API call, job run, or database read adds up. Per-seat pricing hurts in a different way. A team might grow from 8 people to 25, and suddenly a tool that seemed minor becomes a real expense.

Per-event billing is one of the easiest traps to miss. Logs, alerts, tracing, and error tracking often seem harmless at first. Then one noisy release, one bug loop, or one new customer multiplies event volume in a day.

The extra charges matter just as much as the headline price. A service may look fine until you add backups, data transfer, long-term log storage, or restore fees. Many small teams check the main plan and skip the rest. That mistake gets expensive fast.

A quick stress test helps:

• What happens if usage doubles in six months?
• Which line item grows the fastest?
• Which fee depends on behavior you cannot fully control?
• Which bill would hurt if it tripled next quarter?

If one answer makes you uneasy, look harder at that part of the stack.

A small software company might happily pay for a managed database because the cost grows in a fairly predictable way. The same company may want to own logging, backups, or build runners because those bills can swing hard with traffic, failed jobs, or a burst of deploys. That is often the smarter split.

Owning infrastructure does not mean owning everything. It means taking control of the parts where pricing risk is higher than operating risk. If a sudden bill jump would force you to freeze hiring, cut product work, or explain a mess to customers, that part is a good candidate to bring in-house.

Use a simple step-by-step test

Start with the workloads you can measure, not the ones people like to argue about. A short worksheet beats a strong opinion every time.

Write down every workload you pay for each month. Include source control, CI runners, databases, backups, monitoring, logs, internal tools, file storage, and anything your team uses every week. Next to each one, add the real monthly bill, including overages, support, and extra seats.

Then split the list in two groups: steady and spiky. A database that runs all day and changes little from month to month is easier to price. A workload that jumps during launches, imports, or heavy traffic is harder to own because you have to plan for the worst month, not the average one.

Use the same five checks for every workload:

1. Record the normal monthly cost and the highest bill from the last few months.
2. Mark whether usage stays flat or jumps without much warning.
3. Estimate how many staff hours it takes to run, patch, back up, and watch it.
4. Compare the full cost over one year and over three years, not just this month.
5. Pick one low-risk workload you could move first without putting customers in danger.

That labor estimate matters more than many teams think. A managed service may look expensive until you count the engineer time needed to run the same thing yourself. The reverse is also true: a cheap entry price can turn ugly once storage grows, logs pile up, or vendor pricing changes.

A small software company might test this with CI runners first. The workload is steady, the risk is limited, and the team can measure build time, downtime, and monthly spend in a few weeks. Oleg Sotnikov has used this kind of thinking with self-hosted GitLab, Sentry, Grafana, Prometheus, and Loki, but the method works just as well for a team of five.

Move one workload, measure the result for 30 to 60 days, and write down what changed. If costs stay lower and the team can handle the work, move the next steady workload. If the move creates more work than it saves, stop there.

A realistic example from a small software company

Picture a software company with 10 people. It sells a subscription web app and has four moving parts behind the scenes: the app itself, a database, file storage for uploads, and email for password resets, invoices, and account notices.

At first, the team uses managed services for almost everything because setup is fast. That works fine while traffic is small. A few months later, the bill starts climbing faster than customer growth, and some charges change month to month for no clear reason.

They decide to keep email with a vendor. Email delivery needs daily care when things go wrong. Spam rules change, bounces pile up, and sender reputation can slip fast. For a small team, that work is a distraction, so paying a specialist is worth it.

The team chooses to own the app servers and the database. Their usage is steady on most days, and they can predict traffic well enough to rent a few fixed servers. That makes costs easier to plan. It also gives them more control over backups, updates, and failover instead of paying extra every time usage edges up.

They treat file storage as a middle ground. Uploads grow slowly, so they keep storage simple and avoid building a custom system around it. The goal is not to own every piece. The goal is to own the parts where predictable use makes ownership cheaper.

The next problem is logs and monitoring. Their managed logging bill looks small at first, then event charges start to sting once the team adds more debug data and longer retention. They move logs and dashboards in-house on a modest server. The setup takes some work, but the monthly cost stops jumping around.

After 60 days, they review three numbers:

• Total monthly spend
• Uptime and incident count
• Hours the team spends on support and maintenance

If spend drops, uptime stays solid, and support time stays reasonable, they keep the setup. If one area gets worse, they move it back. That is usually the best answer for a small company: own the boring, steady workloads, and leave the fussy ones with a vendor.

Mistakes that waste money

The fastest way to waste money is to own more than your team can actually run. A small company buys servers, sets up databases, adds monitoring, and feels in control for a month. Then one person leaves, alerts pile up, and nobody wants to touch production.

Cheap hardware causes the same kind of trouble. The monthly bill looks great, but the real cost hides in backup jobs, restore tests, disk failures, and time spent patching the box. Teams often save a little on paper and lose far more when something breaks.

Customer data makes this worse. Moving it to a new stack without a rollback plan is a gamble, not a migration. If the import goes wrong, permissions break, or search indexes go stale, you need a clear path back to the old system within hours, not a vague plan in someone's head.

Another common leak is paying twice for too long. Teams keep the old managed service "just in case" and also pay for the new setup, extra storage, and more logging. A short overlap is normal. Six months of overlap usually means the move never had a real owner.

The hidden costs are usually the same: backup storage, monitoring, engineer time for patching and cert renewals, duplicate bills during migration, and downtime when nobody knows the recovery steps.

The ugliest mistake is simple. No one owns alerts after hours. Infrastructure is not just a machine bill. Someone has to answer pages, read graphs, restart jobs, and decide whether a failure can wait until morning. If that person is "whoever notices first," the setup is already too big for the team.

Small companies do better when they start with one or two boring systems they can support well. Email, auth, and payment systems often stay managed longer for a reason. A database, build runners, or internal tools may make more sense to own first if they run every day and the costs stay predictable.

If nobody on your team can back up the system, restore it fast, and handle a 2 a.m. alert, do not move it yet.

Quick checks before you commit

Owning infrastructure looks cheap when you compare one monthly bill to another. The hard part is everything around that bill: setup, patching, monitoring, backups, and the nights when something breaks.

Before you move a workload onto systems you own, ask five plain questions:

• Can one or two people run it without constant alert fatigue?
• Do you know your normal monthly load well enough to size compute, storage, and network use?
• Can you back it up and restore it when people are tired and under pressure?
• Can you leave later without rebuilding the product?
• After staff time, do the savings still matter?

This is where many teams get the math wrong. They compare managed database pricing to a VM price and stop there. They do not count upgrades, disk growth, log cleanup, failed deploys, or the cost of being the only person who can fix production.

Load is another blind spot. If your app runs the same background jobs every day, usage is easier to predict and owning that piece may make sense. If traffic swings wildly or depends on seasonal campaigns, managed services often cost more per month but save you from constant resizing and panic.

Exit matters more than people think. If you cannot move a service back to a managed option in a week or two, your design is too sticky. Keep data formats simple, avoid custom glue where you can, and write down the steps while the setup is still fresh.

This is also why experienced operators tend to like boring setups. Oleg Sotnikov has shown that lean infrastructure can run at serious scale when the architecture is simple, well observed, and sized to real demand. Do not copy someone else's stack. Own only what your team can understand, restore, and replace.

If you cannot measure the workload clearly and recover it quickly, wait.

What to do next

Pick one workload that runs every day and behaves the same way most weeks. Good first candidates are internal Git hosting, monitoring, logging, routine build runners, or a database for a stable product. Avoid the flashy project. Boring systems are easier to price, easier to watch, and easier to judge after a month.

Set a review date 30 days after launch. That deadline keeps the decision honest. At the end of the trial, compare four things: monthly cost, team time, outage count, and how painful support felt. If the owned setup cuts cost without creating new stress, keep it. If it eats time, move it back to a vendor and treat the test as paid research.

Before you switch anything, write down who does each job:

• Updates and security patches
• Backups and restore tests
• Alerts and on-call checks
• Monthly cost tracking

If nobody owns those four items, you do not own infrastructure yet. You own a future problem.

Leave bursty systems with vendors for now. Do the same with narrow tools that need deep specialist care, like advanced search clusters or heavy video pipelines. Vendors may cost more on paper, but they can still be cheaper than hiring around a bad fit.

A sensible split for many small software companies is to self-host CI runners and observability first while keeping email, payments, and large analytics workloads managed. You control the steady spend and leave the tricky edges with vendors.

If you want a practical review before moving anything, Oleg Sotnikov at oleg.is does this kind of Fractional CTO work with startups and small teams. A short outside review can save you from owning the wrong thing too early.