How Much Internet Does a Startup Really Need?

If you build infra-heavy software, a SaaS platform, game backend, API product, or data pipeline, “the Internet” eventually stops being an abstract cloud thing and turns into a line item and a design problem. Early on, you just take whatever bandwidth your data center or cloud provider gives you. At some point, a graph, a bill, or a support ticket makes you wonder: how much Internet do we actually need and are we buying it the right way?

This is a founder-friendly guide to thinking about commits, 95th percentile billing, overbuying vs underbuying, and the moment when “whatever the DC provides” is no longer good enough.

Thinking Like a Network, Not Just a Tenant

As a tenant, your questions are simple: “Is it up?”, “Is it fast enough?”, “What’s the monthly bill?” The provider hides all the messy stuff: how much upstream capacity they have, how they’re billed, how traffic leaves the building.

As your startup grows, you’re no longer just a tenant. You’re effectively:

• Aggregating traffic for thousands of users.
• Running steady, always-on workloads.
• Pushing serious volume to and from the public Internet.

At that point, you benefit from thinking like a small network operator:
“How much capacity do we really use, how are we billed for it, and what shape should our connection to the Internet have?”

What “Commit” Actually Means

When you buy IP transit directly, you don’t just rent a port; you agree on a commit:

• You get a physical port (for example, 1 Gbit, 10 Gbit, 100 Gbit).
• You agree to pay for a minimum traffic level (your commit), often billed using 95th percentile.

So if you have a 10G port and a 1G commit, that means:

• You can burst up to 10G.
• You agree to pay as if you are using at least 1G (measured with 95th percentile).

The key idea: you separate physical headroom (port size) from economic commitment (what you pay for).

For a startup, that’s good news: you don’t need to commit to the full port line rate on day one. You need a realistic commit that matches where you are and where you’ll be soon.

95th Percentile in Plain Language

95th percentile billing sounds scary, but the intuition is simple:

• Your provider samples your traffic usage every 5 minutes over the month.
• They sort all those samples from smallest to largest.
• They discard the top 5% (the biggest spikes) and bill you on the highest remaining value.

In other words: rare, short spikes don’t kill you. Your typical peak is what matters.

For an infra-heavy startup, this means:

• Occasional launch-day surges or backups won’t instantly explode your bill, as long as they’re not constant.
• If your usage slowly climbs and stays high most of the time, your 95th percentile will go up and so will what you pay.

So “how much Internet you need” isn’t about your single biggest spike. It’s about what your traffic looks like most of the time.

Overbuying vs Underbuying: The Real Trade-Off

Founders often default to one of two instincts:

• “Let’s massively overbuy so we can stop thinking about it.”
• “Let’s buy the absolute minimum and hope for the best.”

Both have problems.

Overbuying commit:

• You pay for capacity you don’t actually use yet.
• The finance side will eventually ask why that commit isn’t closer to reality.
• You might delay better decisions (like smarter routing or peering) because “we already pay a lot for this pipe.”

Underbuying commit:

• You might bump your commit too often, renegotiating in panic mode.
• You may hesitate to launch traffic-heavy features because “we’re at the edge.”
• Your provider might not take you as seriously for better pricing and design discussions.

A more useful approach:

• Know your current 95th percentile equivalent (even if it’s from cloud/DC graphs).
• Choose a commit slightly above that (some growth, not heroics).
• Revisit every few months as you add customers and features.

When “Whatever the DC Provides” Stops Being Good Enough

Many startups colocate for the first time and just tick the “Internet access” box on the DC order form. That’s fine early, but there are clear signals it’s time to move to real IP transit from a network-focused provider:

1. You don’t know who actually carries your traffic.
   You have a single line on an invoice: “Bandwidth”. No idea which upstreams, what paths, or how much headroom there is.
2. Latency and jitter feel random.
   Users in some regions complain that things feel slow, but you can’t influence the route without switching the entire service.
3. You’re pushing serious volume.
   Your monthly egress is large enough that even small improvements in cost per Mbit or path quality would matter.
4. You’re thinking about multi-homing or redundancy.
   You want two independent paths to the Internet, but your DC’s “Internet service” is just a single opaque bundle.

At that point, “how much Internet do we need?” becomes “how do we design Internet connectivity as a layer of our product, not a checkbox on a DC order form?”

Rough Capacity Benchmarks for Startups

Every product is different, but a few patterns show up often:

• Early traction stage (tens–hundreds of customers):
  Cloud or bundled DC connectivity is usually fine. Focus more on observability: make sure you can see bandwidth graphs and latency to key regions.
• Growing stage (thousands of active users, steady traffic):
  You likely sit somewhere in the low hundreds of Mbit/s at peak. This is where a small direct transit commit (for example, 100–500 Mbit on a 1–10G port) can start making sense, especially if bandwidth is a big part of your cost.
• Scaling stage (tens of thousands of active users, real-time features, large data flows):
  Your 95th percentile might hit 1G, 2G, 5G, or more. This is prime territory for proper IP transit, multi-homing, and maybe peering. At this point, the quality of your paths and the structure of your commits have a direct impact on gross margin and user experience.

These are not hard rules. The key is that once your bandwidth bill is non-trivial and traffic is steady, it’s worth designing connectivity on purpose.

A Simple Framework for Founders

Here’s a lightweight way to answer “how much Internet do we really need?” in a more precise way:

1. Measure your peak usage.
   Look at bandwidth graphs from your current provider or cloud. Write down what a “normal busy day” looks like.
2. Estimate a 95th percentile equivalent.
   If you don’t have true 95th data, use your regular busy-day peak as a stand-in. Ignore weird one-off spikes.
3. Pick a realistic time horizon.
   Over the next 6–12 months, will traffic likely double, triple, or stay similar? Base this on product and sales reality, not dreams.
4. Propose a commit.
   Take your current “busy” value, add a cushion for expected growth, and that’s your starting commit range. Make sure the port itself has room above that for bursts.
5. Decide if you still want to be “just a tenant.”
   If the numbers are big enough and the product depends on fast, predictable Internet, it might be time to step up to real IP transit and possibly multiple upstreams.

Where a Network-Focused Partner Fits

When you reach the point where Internet connectivity is no longer a rounding error, it helps to work with someone who thinks about this all day:

• Helping translate your traffic graphs into a sane commit and port size.
• Designing a path from “bundled DC Internet” to dedicated IP transit, without breaking existing users.
• Planning for multi-homing and, later, peering when it makes sense, not just because it sounds cool.

Done well, you end up with enough Internet to grow, the right economic model (commit + 95th) so you’re not constantly surprised, and paths that actually match what your users need.

Get a Sanity Check on Your Numbers

If you’re at the stage where your bandwidth bill is big enough to hurt or you’re just not sure what a sane commit and port size would look like for your traffic, you don’t have to guess.

Send a rough snapshot of your current bandwidth graphs and traffic profile to sales@shifthosting.com with the subject “How Much Internet Do We Need?” and you can get a simple, vendor-neutral sanity check on:

• Whether your current capacity matches your real 95th percentile
• What a sensible first (or next) IP transit commit might be