October 2025
Why We Invest in Infrastructure
On technical depth, unit economics, and the systems that compound.
Most venture investors optimize for growth. They want companies that can scale from zero to a hundred million in revenue as quickly as possible, ideally with minimal capital. This makes sense for consumer and enterprise software, where network effects and sales efficiency can create exponential growth curves. But infrastructure doesn't work that way.
Infrastructure scales differently. It grows with the success of the companies built on top of it. Stripe didn't grow because they had a viral product. They grew because thousands of companies chose to build their payment systems on Stripe's infrastructure. Twilio didn't grow because of aggressive sales. They grew because developers kept choosing their APIs for communications. The growth came from being essential, not from being fast.
This creates a different investment thesis. In infrastructure, you're not betting on growth hacks or sales efficiency. You're betting on technical depth, operational excellence, and the compounding value of systems that work reliably at scale. These qualities take time to build and even longer to evaluate. You can't assess them from a pitch deck or a thirty-minute demo. You have to look at the code, understand the architecture, model the unit economics, and see how the system performs under load.
Technical Depth as Moat
In consumer software, moats come from network effects. In enterprise software, they come from switching costs and sales relationships. In infrastructure, they come from operational knowledge. The longer you run a system in production, the more you learn about edge cases, failure modes, and optimization opportunities. This knowledge compounds over time and becomes nearly impossible for competitors to replicate quickly.
Consider a payment processing system. On the surface, it seems straightforward. Accept payment information, validate it, send it to the card network, return a response. But in production, you encounter thousands of edge cases. What happens when a bank's API goes down mid-transaction? How do you handle partial authorizations? What about international cards with different validation rules? How do you optimize routing to minimize fees while maximizing approval rates?
Each of these problems has solutions, but discovering them requires running millions of transactions and learning from failures. A new competitor can copy your API design and your pricing model, but they can't copy the operational knowledge you've accumulated over years of production experience. This is why infrastructure companies that achieve product-market fit tend to be durable. The moat isn't the technology. It's the knowledge embedded in how the technology runs.
When we evaluate infrastructure companies, we look for evidence of this operational depth. How do they handle failures? What's their approach to monitoring and observability? How do they think about reliability versus feature velocity? The best founders can articulate specific trade-offs they've made and why. They don't just know their system works. They know why it works and what would break it.
Unit Economics That Actually Work
Infrastructure businesses live or die on unit economics. Unlike consumer or enterprise software, where you can grow first and figure out monetization later, infrastructure companies need profitable unit economics from the start. Every API call, every transaction, every request has a cost. If your revenue per unit doesn't exceed your cost per unit, growth makes the problem worse, not better.
This seems obvious, but it's surprisingly easy to get wrong. A payment API might charge 2.9% plus thirty cents per transaction, which sounds profitable until you model the actual costs. Card network fees, fraud prevention, compliance overhead, infrastructure costs, support burden. By the time you account for everything, your margins might be razor-thin or even negative on small transactions. The only way to make it work is through volume, optimization, and operational efficiency.
We spend significant time modeling unit economics with founders. Not just the current state, but how they evolve at scale. What happens when you process ten times more volume? Do your costs scale linearly, or can you achieve economies of scale? What about customer acquisition costs? In infrastructure, CAC is often high because you're selling to technical buyers who do extensive evaluation. Can you afford that CAC given your revenue per customer?
The best infrastructure founders think about these questions constantly. They know their cost structure in detail. They can explain which costs are fixed and which are variable. They have a clear path to improving margins over time through operational efficiency, better pricing, or economies of scale. They don't just assume unit economics will work out. They've modeled it, tested it, and proven it.
The Compounding Nature of Infrastructure
Infrastructure businesses compound in ways that other software businesses don't. Every customer you add makes your system more valuable, not just because of revenue, but because of the operational knowledge you gain. Every edge case you handle makes your system more robust. Every optimization you implement improves margins for all existing customers. This compounding creates increasing returns over time.
Consider AWS. When they launched in 2006, they were a basic infrastructure provider. But every customer they added taught them something new about how to run infrastructure at scale. Every failure taught them how to build more resilient systems. Every optimization they made for one customer benefited all customers. Twenty years later, AWS isn't just bigger than competitors. They're fundamentally better because of the operational knowledge they've accumulated.
This compounding effect means infrastructure businesses can have long runways of growth even without explosive early traction. A payment API that processes a million transactions per month might not seem impressive compared to a consumer app with a million users. But if those transactions are profitable, if the system is reliable, and if the company is learning and improving, that foundation can support decades of growth.
We look for this compounding dynamic when we invest. Is the company getting better over time? Are they learning from production experience? Are they reinvesting in reliability and performance? The best infrastructure companies have a flywheel where operational excellence leads to customer trust, which leads to more volume, which leads to more learning, which leads to better operational excellence.
Why We Work Before We Invest
Evaluating infrastructure companies requires depth that traditional due diligence can't provide. You can't assess technical architecture from a pitch deck. You can't evaluate unit economics from a financial model that hasn't been stress-tested. You can't judge operational maturity from reference calls. You need to work with the founder, see the code, understand the trade-offs, and model the economics yourself.
This is why we do deep diligence before we invest. When we evaluate a founder's pricing strategy or architecture, we see things no pitch meeting reveals. We see how they think about technical debt. We see how they prioritize reliability versus features. We see whether they can take feedback and act on it quickly. These observations matter more than any background check or reference call.
By the time we invest, we've already done extensive evaluation. We know the codebase. We know the unit economics. We know the team. The investment decision becomes obvious, not because we're smarter than other investors, but because we have more context. We've evaluated them thoroughly. We've seen their approach to building infrastructure that scales.
This approach also benefits founders. They get to work with us before taking our capital. They see if we actually understand their business, if we can add value beyond money, if they want us as partners for the next five years. Most founders meet their investors during fundraising, when everyone is on their best behavior. We skip that performance. We work together first, and if it works, we invest.
What We Look For
When we evaluate infrastructure companies, we look for technical founders who understand systems deeply. Founders who have built and scaled infrastructure before, who know what breaks at 10x, who think in terms of reliability and performance rather than features and growth hacks. These founders don't chase hype cycles. They build systems that work, then make them work better, then make them work at scale.
We look for businesses with clear paths to product-market fit. In infrastructure, this means developers or companies actively choosing your system over alternatives, not because of sales pressure or marketing, but because it solves their problem better. It means customers who stick around, who increase usage over time, who refer other customers. Product-market fit in infrastructure is quieter than in consumer, but it's also more durable.
We look for unit economics that work at current scale and improve over time. This doesn't mean you need to be profitable on day one, but it means you need a clear path to profitability that doesn't depend on magical thinking. It means understanding your cost structure in detail and having a plan to improve margins through operational efficiency, better pricing, or economies of scale.
Most importantly, we look for systems that compound. Infrastructure that gets better the longer it runs. Companies that learn from production experience and reinvest that knowledge into reliability and performance. Founders who think in decades rather than quarters, who prioritize building something that lasts over building something that grows fast.
The Long Game
Infrastructure is a long game. It takes years to build systems that work reliably at scale. It takes even longer to accumulate the operational knowledge that creates defensibility. But once you have it, you have something durable. Something that compounds. Something that becomes essential to the companies built on top of it.
This is why we invest in infrastructure. Not because it grows the fastest or generates the most headlines, but because it creates lasting value. The companies that win in infrastructure aren't the ones that move fastest. They're the ones that build best. The ones that prioritize reliability over features, that invest in operational excellence, that think in decades rather than quarters.
These are the companies we want to fund. The ones building the next layer of infrastructure. The ones that will power the digital economy for the next decade. The ones that, when they work, you never think about, and when they fail, everything stops.
Jarred Taylor
If you're building infrastructure and want to work together, let's talk.