• Contact us
  • Docs
  • Login
Watch a demoFree trial
Blog
Blog
BlogProductCase studiesNewsInsights
Blog

Your free credits are leading to a 30-person nightmare

DevOpstechnical debtmigrationinfrastructurecloud application platformcloud
01 May 2026
Greg Qualls
Greg Qualls
Director, Product Marketing
Share

Before I worked in tech, I worked in logistics. I saw  a specific pattern repeat itself at office supply companies over and over, until I could see it coming before the customer did.

The pattern went like this. A small office supply company would sell paper and pens to local businesses. One day a customer asked, "can you deliver a box of paper?" The salesperson said yes, drove the box over in their car after work, and thought nothing of it. The customer told their friend. The friend asked for delivery too. Management, reasonably, added "delivery" as a service offering.

A year later the company owned a box truck and had hired a driver. Two years after that, a small fleet, a maintenance crew, a dispatcher, a safety officer, and a lawyer on retainer for the transportation regulations.

Four years in, they were spending more time and money on the delivery operation than on selling office supplies.

The same pattern, in tech

I thought about that pattern a lot once I was on the tech side and started watching it play out with tech founders.

The version I see most often goes like this. A founder takes free credits from one of the big hyperscalers at the start. Their most technical co-founder sets everything up in an afternoon. The setup works. It keeps working. The company grows past the shape the setup assumed.

A few years later, that same founder has thirty people on staff. Those thirty people spend their time on devops, CI/CD, infrastructure, security reviews, and legal paperwork around cloud contracts. Shipping product happens in whatever attention is left over after all that.

None of that work is something AI is going to take off their plate. You can't prompt your way through a SOC 2 walkthrough or a cloud provider's master services agreement. Those thirty people are thirty people for a reason, and the reason is the platform decision made at four people, not the product.

Why it's hard to see coming

The evaluations that pick the platform happen at the smallest moment in the company's life. Four people, one app, a shared Notion workspace. The team has the most specific possible picture of what they need and the least specific possible picture of what they'll need next year. That's not a failure of judgment. It's the shape of the moment.

Here's the part that's easy to miss. The platform decision you make at four people is making a bet about the shape of the company at forty. It's often being made by whoever was available on a Friday afternoon, based on who had free credits and which framework somebody had just posted a blog about. The bet is often fine. When it isn't, the cost of being wrong is a migration during the busiest year of the company's life.

The founders I watch hit this wall almost never describe it as a single migration. They describe it as another piece. A customer asks for something the platform can't do, so they buy a tool to cover it. An auditor asks for something, so they buy another tool. A CFO asks for consolidation, so they bolt on a reporting layer. Every ask gets a piece bolted onto the jenga tower they've been building since the free-credits afternoon. None of the pieces is wrong, exactly. The tower is the problem. At some point the tower is the thing the company is actually maintaining, and the product is whatever sits on top of it, holding on.

The office supply company, four years in, did not set out to run a trucking operation. They set out to sell pens.

What a platform that graduates with you does differently

The question I try to help teams ask now, when they're early enough for the question to be cheap, is what the platform looks like when the company is five times bigger, not what it looks like today.

On Upsun, a few things that matter at scale are already there at size one. The configuration is YAML from day one, which means the application infrastructure is code, which means it scales the way code scales. Every language commonly used in modern product development runs through the same pipeline. The same .upsun/config.yaml that runs a four-person Next.js project also runs a forty-person Next.js plus Go plus Python plus Ruby project. When a customer asks for deployment in their AWS account, it's a region change. When the compliance team asks for SOC 2, ISO 27001, PCI DSS or HIPAA scope across the whole application, that boundary already exists.

The capability that matters is not any one of those. It's that the shape of the platform doesn't change when the shape of the company changes. The thing the founding team picks in a week at seed stage is the same thing the operations team is still using at Series E. The graduation is smooth because there's nothing to graduate from.

That's not a promise that growth is easy. Growth is never easy. What it is, is a promise that the platform isn't the thing you migrate during growth.

What this feels like a few years in

The customers I know who've been on Upsun for a few years describe the platform as "the thing we don't talk about." Which is, I think, the highest praise a platform decision can earn. It ran in the background while the company doubled and tripled and signed a bigger customer and passed an audit. It didn't require a re-evaluation. It didn't hit a ceiling that required a replatform. It scaled with the company, and the company got to spend its attention on the product.

The office supply companies that survived, by the way, were the ones that partnered with a delivery company instead of building one. They stayed in the business they were in.

A question for earlier-stage teams

If you're picking a platform at seed or Series A, the question to sit with is: what does this platform look like when we're five times bigger?

Five times bigger isn't dramatic. It's two to three years. Five times more customers, five times more code, probably more languages, probably more runtimes, probably a security review from somebody with a clipboard. The question isn't whether the platform you pick today supports five-times-bigger use cases. It's whether the platform has a story for getting there without a migration in the middle or slapping on ten additional integrated technologies.

If the story is "use the same configuration, add what you need," you're in a good spot. If the story is "migrate to our enterprise tier" or "integrate with a different set of tools," that's the seed of a future Thursday spent on something that is not the product.

Get back to selling office supplies

The founders I know untangling their jenga towers now are going to be fine. Products good, customers loyal, nothing on fire. They're just spending a year paying a bill they didn't know they were running up, and cutting the size of the team that maintains the tower in half.

If I were picking a platform today for a project with any chance of becoming a real company, I'd be thinking about the shape of the platform two to three years out more than the shape of it this quarter. The quarterly shape is easy to evaluate. The future shape is the one that matters.

If you're already running the company you started, good. If you look up one day and realize you're running a devops operation that ships apps on the side, it's not too late to go back to “selling office supplies” and let somebody else run the trucks.

Further reading

Stay updated

Subscribe to our monthly newsletter for the latest updates and news.

Your greatest work
is just on the horizon

Free trial