I had a great mentor at IBM who taught me that when evaluating startups to plug into the IBM machine, you had to look for platforms that could solve enterprise problems for today as well as tomorrow. Over the years of doing this, I’ve noticed a pattern. Smart founders, solid engineering teams, real customer problems - all let down by key strategic decisions in the early days that compound into years of lost opportunity by year three.
In my last post, I talked about the difference between building spikes and building wedges and how companies with sharp initial products but no underlying platform hit architectural ceilings they can't break through. Today, I want to get specific about three decisions I've watched multiple infrastructure startups make that looked smart in the moment but cost them dearly as time went on.
These aren't cautionary tales about bad companies. These are examples of rational short-term thinking that creates long-term constraints. And they're worth examining because, at ContextOS, we looked hard at each of these patterns and deliberately designed around them.
A well-funded competitor in the developer platform space made what seemed like a safe bet in 2017: they built their platform on top of AWS's Firecracker microVMs and Docker containers.
At the time, this was cutting-edge infrastructure. Firecracker was fresh from AWS's serverless team, the same technology powering Lambda and Fargate. Docker was the industry standard for containerization. Both were open source, battle-tested, and familiar to developers. Building on this stack meant getting to market fast with proven technology that every engineer understood.
Fast forward to 2026, and that architecture is showing its age.
Here's what most developers don't think about when they see "deploy Docker containers to our platform": those containers are running inside Firecracker microVMs, which are themselves running on bare metal. That's two layers of virtualization between the application code and the actual CPU.
Each layer adds overhead. Container runtime overhead. Hypervisor overhead. Memory allocation overhead. Network address translation at the VM layer, then again at the container layer. Storage I/O passing through the VM filesystem, then the container filesystem, then finally reaching the application.
For a platform company, this architecture makes optimization nearly impossible. You can't tune what you don't control. The performance ceiling is set by AWS's design decisions from 2018, optimized for Lambda's use case of short-lived functions, not for long-running application servers.
And here's the trap: they can't easily migrate off this architecture because their customers' workloads are already integrated with it. Every deployment pattern, every scaling behavior, every performance characteristic is tied to how Firecracker and Docker work together. Rebuilding would mean disrupting every existing customer.
The technology wasn't wrong in 2017. But technology built for serverless functions in 2017 constrains a platform business in 2026. Picking a technology darling today pigeon holes your product as technology evolves.
The real cost: Architectural decisions that saved six months in 2017 now block meaningful platform improvements in 2026. Nine years later, they're still running production workloads on infrastructure designed for a different problem.
Another developer-focused infrastructure company took a different shortcut: they started by building on top of AWS and Google Cloud Platform.
The reasoning was sound. Why spend engineering time building and operating infrastructure when you're trying to validate product-market fit? Use AWS ECS or GCP Cloud Run, focus on the developer experience layer, and get to market fast. If it works, you can always move to your own infrastructure later.
They shipped in months, not years. They got customers. They raised capital. The developer experience they built was genuinely good. By all the metrics investors and advisors tell founders to optimize for, they were winning.
Then the math caught up with them.
When you're a platform company building on another platform, you're paying retail prices for infrastructure and trying to sell it with your own markup. Your customer pays for the cloud provider's margin plus your margin. Meanwhile, competitors running on bare metal are paying wholesale costs, typically 70-80% less than cloud retail pricing.
At a small scale, you can absorb this. On a meaningful scale, it's unsustainable. Your gross margins can't support the business model. You're selling infrastructure but don't control the infrastructure economics.
So this company announced they were migrating to their own bare metal infrastructure. Not because they wanted to. Because their cost structure made it impossible to build a real business on cloud infrastructure where they controlled what they needed to control.
Here's what that migration looks like in practice:
Year 1: Build on AWS/GCP, ship fast, validate product
Year 2: Grow customers, realize margin problem
Year 3: Announce migration to bare metal
Years 4-6: Execute migration while maintaining both infrastructures
Year 7: Finally complete migration
That's seven years from founding to having the right infrastructure architecture. During years 4-6, they're paying for both cloud infrastructure and their own bare metal, operating two completely different stacks, with their engineering team split between migration work and feature development.
The competitors who started on bare metal are shipping features and expanding into adjacent markets. This company is burning engineering time and capital fixing an infrastructure decision they made for speed in year one.
The real cost: An architecture choice that saved 12 months in 2020 is now costing 3-4 years of opportunity in 2024-2027. Every dollar spent maintaining dual infrastructure is a dollar not invested in product differentiation. Every engineer working on the migration isn't building the features customers are asking for. To look at it another way, raise your Series A on the quick sizzle and spend your Series B to fix the problem.
The third pattern is less common but particularly instructive: a startup founded by some of the most respected engineers in the infrastructure world decided to build everything from scratch. Not just the software platform but the hardware too.
Custom server boards. Purpose-built network switches. Firmware written in Rust. A complete operating system and control plane. Integrated rack-scale systems delivered to customer data centers. True vertical integration, built from first principles.
This isn't a critique of their technical decisions, the engineering is genuinely impressive. The firmware architecture is innovative. The hardware-software integration is exactly what on-premise infrastructure should be. The team executing this is as good as it gets in systems engineering.
The problem is scope and time.
Building an infrastructure company is already hard. You need to solve orchestration, networking, storage, security, observability, and developer experience. Each of these is a multi-year engineering effort on its own.
Now add hardware to that list. Server board design. Thermal engineering. Power distribution. Supply chain management. Manufacturing processes. Quality control. Logistics. Field service. The engineering disciplines barely overlap. The timelines are measured differently. Hardware bugs can't be fixed with a software patch.
The result: five years from founding to general availability. Five years to validate that customers actually want integrated hardware-software systems. Five years where software-only competitors are iterating, learning from customers, expanding into adjacent markets, and building revenue.
Every dollar spent on Printed Circuit Board design is a dollar not spent on software differentiation. Every engineer debugging thermal issues isn't improving the orchestration layer. Every week waiting for component shipments is a week not shipping features.
There's an alternative path that would have reduced risk substantially: build the software platform first on commodity hardware. Prove the orchestration, control plane, and management layer works. Get customers running on their existing Dell, HPE, or Supermicro servers. Validate product-market fit. Generate revenue.
Then, once you've proven the software business, introduce optimized hardware as a premium offering. Customers can choose: run on commodity hardware or pay extra for the integrated experience. The hardware becomes a margin enhancer, not a dependency.
The real cost: Attempting hardware and software simultaneously doubles complexity, quadruples timeline, and constrains business model flexibility. Even with exceptional talent and patient capital, the opportunity cost is massive. Five years to general availability means five years of learning, iteration, and revenue that didn't happen.
Here's what these three examples have in common:
When we started building ContextOS, we had the benefit of seeing these patterns play out. We knew the mistakes to avoid.
On architecture: We didn't take the Firecracker shortcut. We're running on bare metal from day one, no virtualization layers, no container overhead. Direct process execution, native networking, native filesystem access. The performance ceiling isn't set by someone else's 2018 design decisions. We have extreme flexibility and can adjust to the evolving technology landscape.
On infrastructure: We didn't start on AWS. The ContextOS cloud is running on our own bare metal infrastructure. Yes, it took longer to build. But we're not paying cloud retail markups, we're not dependent on another platform's roadmap, and we're not facing a multi-year migration to fix our cost structure.
On scope: We focused on what we are good at: Infrastructure Software. We're a software company. We benefit from the massive R&D budgets of Dell, HPE, AMD, and Intel. When DDR5 gets faster or PCIe Gen 6 arrives, we upgrade. We don't design motherboards. We design software that makes distributed computing simple.
The trade-off we accepted: a little longer initial build. We're a few months from starting to shipping our first production platform, it will have taken us 18 months from formation to launch. That's longer than building on Firecracker would have taken. Longer than launching on AWS. Shorter than designing custom hardware.
But here's what we get for that investment:
Here's what I want technical leaders and investors to think about when they see "fast to market" as a primary metric:
Fast to what?
Fast to the first customer? Fast to product-market fit? Fast to sustainable unit economics? Fast to a platform that can expand into adjacent markets?
Because the companies that optimize for "fast to first customer" often spend years recovering from the shortcuts they took. The companies that take the time to build the right foundation spend the next five years moving faster than anyone else.
I've been in the infrastructure industry for over two decades. I've seen the shortcuts that seem smart. I've watched the bill come due later. I'm tired of seeing good companies burn years of opportunity fixing architectural decisions they made under pressure to ship fast.
We're building ContextOS the way we wish someone had built the platforms we inherited. We looked at what went wrong, at competitors, at the companies we worked for, at the technologies we've had to maintain and we designed around those patterns from day one.
Eighteen months to build it right. Then a decade to leverage that foundation.
That's the bet we're making. And given what I've watched happen to the alternatives, it's the only bet that makes sense.
Want to see what a platform built from first principles looks like? ContextOS is entering public beta in Q1 2026. Sign up here to be among the first to deploy infrastructure that actually disappears.