Startup infrastructure costs that stay low while you ship

Why bills rise before the product is ready

Early teams rarely run out of ideas. They run into subscriptions.

The pattern looks harmless. Two founders pick a cloud host, then add auth, analytics, email, monitoring, feature flags, session replay, task tracking, design tools, a managed database, and a backup service "just in case." Product work moves slowly, but the card gets charged every month.

That is how infrastructure spend gets out of hand before the product has a clear shape. Teams buy tools faster than they ship features because buying feels like progress. Starting a trial takes ten minutes. Deciding what users actually need can take two weeks.

Small fees are the real trap. A $19 tool, a $49 add on, and a few $99 plans do not look serious on their own. Put them together and you get a fixed monthly bill long before revenue shows up. Once those tools slip into the workflow, people stop questioning them.

The damage is not just financial. Too many services create extra work every week. Someone has to connect them, manage permissions, fix broken webhooks, clean up duplicate alerts, and explain which tool owns which job. A tiny team ends up doing operations work instead of product work.

A simple example makes the point. A startup with two founders might use one service for auth, one for database hosting, one for logs, one for error tracking, one for email, and one for file storage before the first serious customer call. None of those choices is unreasonable. The problem is the pile.

Bills rise even faster when nobody owns the spend. Founders often split decisions by habit. One person buys dev tools. The other buys marketing and support tools. Nobody sees the full monthly total, and nobody removes overlap. Runway disappears in quiet, boring chunks.

Oleg Sotnikov has written and worked a lot around this problem. His main point is simple: cost control starts with architecture and ownership, not coupon codes. If one person reviews every new tool and asks, "What does this replace?" the bill usually drops fast.

Where hosted services save time

Hosted tools make sense when setup work steals hours from product work. If you spend days fixing email delivery or reading backup docs, you are not talking to users or shipping features. In many cases, a hosted service lowers total cost because it removes hidden labor, not because the monthly fee is small.

A small team should stay picky. Use hosted tools for the parts that are easy to get wrong and annoying to babysit. That usually means the systems around your product, not the product itself.

For most early teams, a managed database, email delivery, payments, auth, and error tracking are sensible first buys. Each one solves a problem that tends to get messy fast.

The managed database point is worth saying plainly. If nobody on the team can restore a backup under pressure, do not run your own database yet. A hosted Postgres plan may cost more than a self managed VM on paper, but one failed recovery can cost far more.

The same logic applies to email, payments, and auth. These systems have sharp edges. They also come with abuse controls, security rules, and edge cases most founders do not want to learn at midnight.

The common mistake is not using hosted services. It is buying premium plans too early. Teams pay for seats, request limits, and extra environments they never touch. Start with the lowest plan that covers real traffic. Upgrade only when usage, support load, or risk gives you a clear reason.

Picture two founders building a B2B SaaS tool. They can launch faster with a managed database, hosted auth, Stripe for billing, and a basic email service. That stack may cost a bit more each month than doing everything themselves, but it can save a week or two of setup and a lot of small failures later.

That trade is often smart. Oleg Sotnikov tends to push small teams toward work that helps the product and away from side quests they will have to maintain forever.

What to self host first

The first things to self host should be the parts you use every day and can explain in one sentence. For many startups, that means the app itself, a background worker, and a database backup routine you actually trust. Put those on a small, boring setup before you chase clever infrastructure.

A single server, or at most a tiny pair of servers, can carry a lot more than founders expect. One machine can run the web app and worker with Docker Compose. It is plain, cheap, and easy to fix at 2 a.m. when something breaks.

Start with the workhorse

If your product sends emails, processes jobs, imports files, or runs AI tasks in the background, the worker matters as much as the app. Keep both close together early on. Fewer moving parts means fewer surprise bills and fewer places for jobs to get stuck.

Source control and CI come next only if they fit the way your team works. If your team lives in Git and deploys often, keeping code, pipelines, and runners close to your normal workflow can save money and reduce friction. Oleg Sotnikov often uses self hosted GitLab runners and lean CI for this reason. The team can see what runs, what fails, and what each build costs.

Logs and dashboards are different. Teams love the idea of full observability, then ignore it for weeks. Self host logs, metrics, and dashboards only when someone checks them often enough to catch issues early. If nobody looks at the graphs, a fancy stack is just another chore.

A simple rule helps before you self host anything. One person should agree to maintain it. Backups should be tested, not assumed. Updates should fit into a normal week. And the team should use the tool often enough for the effort to make sense. If a service fails that test, buy it for now.

A good early setup is boring on purpose: app, worker, database, backups, and simple CI. That gives you control where it matters and keeps the monthly bill calm while the product is still finding its shape.

Spending rules for a small team

Small teams do better with a hard limit than with "we'll keep an eye on it." Pick one monthly cap that covers cloud, SaaS tools, monitoring, email, design, and everything else that hits the company card. When the cap is real, people ask better questions before they add another service.

Use a short approval rule for new spending. Before anyone buys a tool, they should write a quick cost note: what problem it fixes, what cheaper option they tried, the full monthly cost, and when the team will review it. That takes five minutes and blocks a lot of lazy spending.

Every paid tool also needs one owner. That person decides why the team has it, who uses it, and when to cancel it. Without an owner, old seats pile up, trial plans turn into annual plans, and nobody notices.

Review bills once a month on the same day each time. Keep it short. Open the invoice list and look for the usual waste: idle servers left over from tests, storage and backups nobody needs, paid seats for people who never signed in, duplicate tools, and larger plans bought "for later."

Match spending to the next product milestone, not to some future version of the company. If your next goal is 100 active users and a stable beta, do not pay for a setup built for 100,000 users. Startups usually burn cash because they buy comfort early: extra databases, expensive observability, premium support, and bigger machines than the workload needs.

Oleg's work with lean, AI augmented teams shows the same pattern. Low spend does not come from wishful thinking. It comes from right sizing infrastructure, cutting duplicate services, and making every bill easy to defend.

Raise the budget only when the next milestone forces it. Until then, keep the stack boring, the rules clear, and each monthly charge easy to explain.

Build a simple stack in four steps

Most early teams do not need a platform map. They need a short stack that ships code, stores data, and tells them when something breaks.

Build for the next six months, not the next funding round. If your product has a few hundred users, do not design for millions.

First, write down the jobs the product must do soon: run the app, store user data, send emails, process payments, and capture errors. If a tool does not help with one of those jobs in the near term, leave it out.

Next, pick the fewest services that cover those jobs. One app host, one database, one place for logs or errors, and one email provider are enough for many products. If one service can do two jobs well, that is usually better than combining three smaller tools.

Then keep the setup narrow. Use one way to deploy, one place to read logs, and one database engine. Small teams move faster when everyone knows where releases happen and where failures show up. A mixed setup with Docker on one service, serverless on another, and two databases looks flexible at first. It gets messy fast.

Finally, write exit rules before you need them. Note what would make you replace each service: a bill limit, weak support, missing features, or performance trouble. Do the same for bigger moves. Delay extra regions, queues, replicas, and clusters until traffic or uptime needs force the change.

A two founder team can run for quite a while on one repo, one CI path, one app host, PostgreSQL, basic error tracking, and daily backups. It is not fancy. That is the point.

A realistic setup for two founders

Two founders can launch a SaaS with less than most people think. One small app server and one database are often enough for the first paying customers, especially if the product does one job well and the team keeps scope tight.

A common setup is simple: the app runs in Docker on a single VPS, and the data lives in one managed PostgreSQL database. That gives the team a clear deploy flow, backups, and an obvious place to look when something breaks. No separate cache, no search cluster, no message bus, and no extra staging stack unless users actually force the need.

They might still buy a few hosted tools on day one because building those parts is a poor use of founder time. Email delivery handles sign ups, password resets, and product messages. Payments stop billing, tax, and receipts from turning into a side project. Error tracking helps bugs show up fast instead of hiding in logs. Basic analytics can make sense if the team needs to understand activation and churn.

That mix keeps the stack lean without turning it into a science project. The expensive mistake is not paying for a few hosted services. It is paying for ten of them because each one solves a tiny edge case.

If a founder wants to add a new tool, it should replace manual work they already feel every week. If the pain is still rare, they can wait. A shared inbox can wait. A feature flag service can wait. A workflow tool can wait. Early products usually need fewer moving parts, not more.

Once a month, the founders should review every bill together. The meeting should take 20 minutes, not two hours. Ask plain questions: Did we use this? Did it save time? Would we notice if we removed it this week?

This is also the time to decide whether to move something in house. The rule is simple: do it only when the bill is clearly higher than the time it takes to run the service well. Oleg Sotnikov often pushes teams toward this tradeoff because cheap infrastructure is not about using free tools. It is about keeping the stack small enough that two founders can still understand every part of it.

Mistakes that burn cash

A lot of wasted spend comes from buying comfort too early. Bigger plans, more tools, and more automation can make a team feel safer. Then the bill grows faster than the product.

One common mistake is paying for enterprise tiers when traffic is still small. A startup with a few hundred users does not need the same setup as a company with millions of requests a day. Founders often buy the plan they hope to need in a year, not the one they need this month.

Kubernetes is another classic leak. It can solve real problems, but it also adds setup time, maintenance work, and extra services around it. If two founders can ship on a simple app server, a managed database, and basic monitoring, adding a cluster usually slows them down and raises the bill at the same time.

Teams also keep duplicate tools for too long. They start with one logging tool, try another, and never turn the first one off. The same thing happens with email services, feature flags, analytics, and CI. Migration feels annoying, so both stay live. Six months later, nobody remembers why.

Small charges do real damage because they hide in the background. Bandwidth overages after a traffic spike, backups stored forever, long log retention, paid seats for people who no longer use the tool, and free trials that quietly turn into renewals all add up.

A simple rule helps: every tool needs an owner and a review date. If nobody owns it, cancel it. If the team cannot explain why it stays, remove it.

Lean setups often work better than crowded ones. Oleg Sotnikov built and ran global production systems with very low cloud spend by right sizing infrastructure, cutting duplicate services, and keeping the stack tight. It is less glamorous than buying more software, but it usually gives startups more runway.

A realistic example is easy to imagine. Two founders launch a B2B product and choose Kubernetes, two observability tools, three AI services, and enterprise support on day one. They spend thousands before they find product fit. The cheaper version is usually enough at the start: one deploy path, one database, one logging tool, one backup routine, and a calendar reminder to cancel trials before they renew.

Most waste does not come from one bad choice. It comes from five small ones nobody revisits.

A quick check before you add one more tool

Most teams do not get into trouble from one huge bill. They get there by adding small monthly tools that feel harmless. Six weeks later, nobody remembers why half of them are still running, but the card gets charged anyway.

The fix is boring, but it works. Pause before each new purchase and force the tool to earn its place.

Start with the pain. A new service should remove a bottleneck you feel right now, not a problem you might have someday. If deploys already work, you probably do not need another deployment layer. If support volume is tiny, a full support suite can wait.

A tool also needs an owner. One person should handle setup, billing, access, and the monthly check to see if the team still uses it. When nobody owns a tool, it lingers for months because canceling it feels like a chore.

Before saying yes, ask five questions:

• What job does this tool do today?
• Who will set it up and watch the bill?
• What breaks if you remove it next month?
• Can one cheaper tool cover most of the same job?
• Will this help the team ship faster this quarter?

That third question catches more waste than people expect. If nothing serious breaks when you remove a tool, you probably did not need it. If one cheaper service covers most of the same job, that is often the better choice for a small team.

This comes up all the time in infrastructure. A startup may pay for separate tools for logs, alerts, uptime checks, and error tracking, then learn one existing setup already covers most of that. Oleg Sotnikov's advice is consistent here: cut overlap, right size the stack, and keep the parts that save real time.

Say two founders want feature flags, analytics, user feedback, and incident alerts. Before buying four tools, they should ask whether their current product analytics can handle basic flags, whether email can collect early feedback, and whether their existing monitoring already sends enough alerts. That choice can save a few hundred dollars a month without slowing product work.

If a tool does not solve a current headache, put it on a 30 day parking list. If the pain still hurts in a month, buy it then. If not, you just avoided a quiet bill that could have stayed for a year.

What to do next

Open the billing page for every service you pay for and put everything in one sheet. Include servers, databases, monitoring, CI, email, analytics, storage, domains, and the small tools that quietly charge $15 to $99 a month. Most teams do not have a cloud problem. They have a visibility problem.

Add four columns: monthly cost, owner, purpose, and what breaks if you remove it. That last column matters. A staging server nobody uses, a second error tracker, or an old backup tool often survives only because no one asked why it still exists.

A small team can do this in an hour. List every server and paid tool. Group them into must keep, can replace, and can remove. Pick three costs to cut or simplify this week. Then set one monthly calendar reminder to review spend.

Do the cuts while the list is fresh. Cancel duplicate tools first. Then downsize oversized machines, remove idle environments, and merge overlapping services. If two founders save even $400 to $800 a month, that can cover testing devices, contractor time, or a few more weeks of runway.

Be strict about new purchases. If someone wants a new tool, ask two things: what problem does it fix today, and which current cost can it replace? That habit keeps spending tied to real work instead of wish lists.

A common example looks like this: one team pays for a managed database, a hosted queue, two logging tools, and a premium CI plan. After a short review, they keep the database, move logging into one place, cut the queue they barely use, and drop CI seats they do not need. The product does not slow down. The bill just makes more sense.

If your team wants a second opinion, Oleg Sotnikov does this kind of advisory work on oleg.is. He works with startups on architecture, infrastructure, and practical AI adoption, and the review tends to be most useful when you already have the spend list in front of you.

Put the review on the calendar now, not next month. Costs grow quietly.