Principles that matter across everything: building for clarity and conviction, what makes VC infrastructure different, and parting advice for practitioners.
This book covered how to build technology for venture capital funds: what systems matter, when to build versus buy, how to avoid common mistakes, and how to work effectively within VC organizations.We started by understanding venture capital itself. You can’t build good tools for investors without understanding how funds work, what they optimize for, and how different fund strategies require different technology. A 50Mpre−seedfundanda500M growth fund have fundamentally different needs. Build for the fund you have, not the fund you imagine.We covered the VC tech stack: CRM and deal flow management, fund operations, research platforms, sourcing tools, portfolio support, fundraising, and external presence. For each category, we looked at when to buy, when to build, and when to skip entirely. Not every fund needs every system. Start with what creates immediate value (usually CRM and fund ops), prove yourself with small wins, then decide what comes next.We went deep on technical foundations: data providers, data modeling, entity resolution, data quality, data warehousing, knowledge graphs, integrations, security, and emerging trends. These are the building blocks you need regardless of what you’re building. Get companies-versus-deals modeling right. Accept that data is messy. Use dbt for transformations. Connect AI tools to your internal data. Choose boring technology that works.But beyond specific tools and techniques, this book was about principles that matter when building for venture capital.
The best VC technology is invisible. GPs don’t think about your CRM or your data warehouse. They think about companies, markets, and investment decisions. Your infrastructure either helps them think more clearly and move faster, or it gets in their way.Your value doesn’t come from using cutting-edge frameworks or building sophisticated architectures. It comes from reducing friction, surfacing insights, and helping your fund deploy capital more effectively. Sometimes that means building a custom research platform because your fund’s thesis-driven approach requires it. More often it means configuring Attio well, loading clean data into a warehouse, and answering questions quickly when GPs ask them.Technology is leverage, not the end goal. A simple tool that GPs actually use beats a sophisticated system that sits unused. A well-maintained CRM with clean data beats a custom-built deal flow tracker that’s always broken. An analyst who can pull portfolio metrics in five minutes beats automated dashboards that show the wrong numbers.This means saying no to projects that sound impressive but don’t create value. Don’t build AI features for the sake of having AI. Don’t build knowledge graphs because they’re intellectually interesting. Don’t rewrite working systems because the code isn’t elegant. Build what helps your fund invest better, and skip the rest.
The best VC infrastructure creates clarity: about what companies you’re tracking, what your pipeline looks like, how your portfolio is performing, what your thesis implies you should focus on. And it builds conviction: by giving GPs complete information, showing relevant context, and making it easy to act on insights.This requires understanding how investors actually work. They don’t make decisions based on dashboards. They make decisions based on conversations with founders, pattern recognition from past investments, conviction about markets and opportunities. Your tools should support this process, not try to replace it.That means:Making information accessible, not prescriptive. Show GPs data about a company, but don’t try to score or rank companies algorithmically. They need context to form conviction, not automated recommendations that flatten nuance.Reducing cognitive load, not adding it. Every tool you build should make something easier (finding companies, tracking conversations, analyzing markets). If it requires learning new interfaces, remembering new processes, or switching contexts constantly, it’s making their job harder, not easier.Enabling speed, not slowing it down. When a GP wants to take a meeting, learn about a company, or make a decision, technology should accelerate that process. Slow tools that require data entry, complex workflows, or waiting for reports are friction, not leverage.This is why good VC technology is often simple: a well-organized CRM, clean data you can query quickly, tools that integrate with existing workflows rather than creating new ones. Sophistication for its own sake makes things worse.
Building technology for VC funds is different from building products for consumers or tools for enterprises. Understanding these differences helps you make better decisions about what to build and how.Small user bases with high context. You’re building for 5-30 people, and you probably work directly with most of them. This means you can build features that assume deep context, skip extensive documentation, and fix issues within minutes when they break. You don’t need to scale to thousands of users or support people you’ve never met. Use this to your advantage.Data quality over data volume. VC funds track thousands or tens of thousands of companies, not millions. The challenge isn’t scale, it’s quality: getting accurate information, resolving entities across sources, handling uncertainty and staleness. Focus on making data trustworthy, not on handling massive scale you’ll never hit.Judgment-based workflows, not automated processes. Investment decisions require human judgment about markets, teams, and opportunities. Your tools should inform judgment, not try to automate it. This is fundamentally different from building operations software where the goal is often to reduce human involvement.Relationships matter more than transactions. VC is about long-term relationships with founders, co-investors, and LPs. Your infrastructure should make it easier to maintain context across years, understand networks and connections, and help your fund be a better partner. This is different from transactional software where interactions are discrete events.Sensitivity and trust. You’re handling information about LPs, portfolio companies, and investment strategy that’s highly sensitive. Security and discretion matter. Build systems that respect this, even when it adds friction.These differences mean you can’t just copy patterns from consumer tech or enterprise SaaS. You need to build for the specific context of venture capital.
Start by listening, not building. Spend your first weeks understanding your fund: how GPs think, what problems they actually have, what tools they already use. Build context before you build software. The best first projects are often small: fixing something broken, automating something tedious, making existing data easier to access.Prove value incrementally. Don’t propose a six-month project to build a research platform from scratch. Build something small that works in two weeks. Get GPs using it. Learn what matters. Build trust. Then take on something bigger. Your budget and scope grow as you demonstrate value.Learn the domain, not just the technology. Read investment memos. Sit in on IC meetings. Understand what makes companies successful or fail. This domain knowledge makes you exponentially more valuable than just being a good engineer. You’ll understand what data matters, what questions GPs are trying to answer, and what tools will actually help.Know when to say no. Not every feature request makes sense. Not every tool should be built. Part of your job is understanding what creates value and what’s distraction. Saying no respectfully, with good reasoning, builds credibility. Saying yes to everything and failing to deliver destroys it.Document what you build, even for internal tools. You might leave, others might join, or you might forget how something works. A README explaining what a service does, how to run it, and where data comes from saves future you (and future team members) hours of archaeology.Don’t optimize prematurely. Your fund has 100 monthly active users, not 100 million. Build simple systems that work. Use boring technology. Optimize when you have evidence there’s a problem, not because you anticipate scale you’ll never reach.Build relationships with GPs and associates. They’re your users and your advocates. Understanding what they care about, showing them work in progress, and incorporating their feedback makes better products. It also builds support for bigger projects when you need budget or time for something ambitious.Stay technical. It’s easy to drift into pure product or project management. Stay in the code. Keep building. Your value is being able to both understand what needs to exist and actually build it. Maintain that leverage.
VC infrastructure will continue evolving. AI tools will get better at extracting information, analyzing companies, and helping investors move faster. Data vendors will provide richer, more accurate information at cheaper costs. Development tools will make solo developers even more productive. The specific technologies will change, but the fundamentals won’t.Funds will still need to track companies, manage relationships, and make investment decisions. They’ll still need clean data, good tools, and infrastructure that reduces friction rather than creating it. The best VC technology will still be invisible: enabling better decisions without calling attention to itself.Your role is understanding what your fund needs, building tools that help them invest better, and avoiding the trap of building for its own sake. Technology serves the investment process. Keep that as your north star, and you’ll build things that matter.
Building technology for venture capital is rewarding work. You’re helping funds find great companies, support founders, and generate returns. The best part of this job is seeing tools you built actually get used: GPs publishing trends from your research platform, portfolio metrics flowing through your dashboards, data you cleaned informing real investment decisions.But it requires balancing technical sophistication with practical utility, understanding both venture capital and software engineering, and having the judgment to know what to build and what to skip.Technology in venture capital is a craft, not a science. Every fund is different. What worked at Inflection won’t work exactly the same way at your fund. What worked for EQT might not work for you. But the principles remain: understand your context, build for your users, choose simplicity over sophistication, and remember that your value comes from helping investors make better decisions.Good luck building.