The Platform Engineering Approach to VC

--

Photo by Ricardo Gomez Angel on Unsplash

In his blog post, The Full Stack Venture Capitalist, Roberto outlines the 3 types of venture firm when it comes to the application of a technology strategy to their organisation. These different types of organisational design need to be aligned to the firm’s investment strategy and require different technology approaches:

Types of Organisational Design mapped to their Technology Approaches

For a Full Stack VC like InReach Ventures, having data and technology at the centre of your strategy and organisation means you have to re-think how you ‘do’ VC from the ground up — even your organisational structure and culture. You can’t approach this as a data problem, but rather it forces you to employ a Platform Engineering Approach.

What is the Platform Engineering Approach?

Platform Engineering enables product developers / data scientists / etc to spend time on what delivers value to the business. Building an automatically managed platform that allows them to do what they need to in a self-service manner, without having to worry about security / scaling / etc.

This isn’t as simple as signing up to a cloud provider or choosing Kubernetes, nor does it mean that Platform Engineering is completely separated from application development. At its core, Platform Engineering requires a deep understanding of the building blocks of the business, and the principals on which they should be architected — only then can you provide them as services to your developers / data scientists.

So translating this to InReach as a Full Stack VC, the Platform Engineering Approach requires rethinking the venture capital value chain to have data and technology at its core, across the logical architectural layers of: Data, Intelligence and Workflow.

Logical framework for full-stack VC (source: InReach Ventures)

Below I outline how this approach directs the the architectural principals for each layer:

Live Data Platform

The Platform Engineering Approach applied to the Data layer maximises the capabilities of the platform through coverage, depth and freshness. For InReach and our platform: DIG, this can only be achieved through being a Live Data Platform that is architected for extensibility (adding any data-source is trivial) and constantly automatically growing (updates happen every second with no human intervention).

The European startup ecosystem is fragmented; companies and founders can pop up all over the continent. For later stage VC firms looking to harness data to support their investment process, getting a subscription to Pitchbook, Crunchbase or Dealroom (special shout-out to Dealroom 👋) is more than enough. For InReach, investing in early-stage founders, the goal is to find the next Spotify before anyone else has heard of them — at this stage the fragmentation carries on to deal-sourcing through data.

DIG’s Data layer is where the rubber hits the road, data engineering-wise. It gathers information from over 400 different data sources of all different shapes and sizes, tracking constant updates for millions of companies and founders. To give you an idea, we currently store almost 40TB just of startup’s websites from over the years. Without giving too much away, below you can see how the hundreds of data-sources contribute to discovery of deal-flow at InReach:

Data source contribution to origination of deal-flow

The constantly scoring, extensible, Intelligence Layer

The Platform Engineering Approach applied to DIG’s Intelligence layer is about architecting around the principals of:

Constant scoring, constantly learning

This is needed for the alignment of the Data and Intelligence layers. There’s no point having a Live Data Platform if it takes a month to re-score the updated data. As important is the concept of constant learning and creating a virtuous cycle between the Data, Intelligence and Workflow layers to constantly improve the training data and models.

Extensibility and composability

In the same way that it needs to be trivial to add data-sources to the Data layer, so the Intelligence layer has to be architected in such a way that new algorithms, models and AI technologies can easily be plugged-in and provide meaningful results quickly. Rather than having one monolithic ML model to find great European startups, DIG is built around the concept of combining different models, using different techniques and technologies, all for discovery.

We also feel this Platform Engineering approach to the Intelligence layer is directionally sound. The trend towards larger and larger language models is pushing us to tackle data science as an engineering discipline. As LLMs become more accessible, affordable, and perform well on a wide range of zero-shot learning tasks, the challenges of the Intelligence layer shift from traditional data science (model creation and evaluation) to purely engineering and implementation tasks.

Automating the Workflow Layer

Across the VC value-chain, applying the Platform Engineering Approach to the Workflow layer means looking at what is traditionally done at each stage and re-thinking it how to Productise and Automate them. Again, for an early-stage European VC like InReach, the focus is still going to be on Discovery.

Building on the Live Data Platform and the constant scoring of the Intelligence layer, the goal for the Workflow layer has to be to build an automatic, self-populating CRM. Reaching out to and engaging with entrepreneurs from across Europe is the last piece needed to be able to achieve DIG’s stated goal of: talking to the next Spotify before anyone else knows they exist

Conclusion

Being a Full Stack VC necessitates taking a Platform Engineering approach to the logical architectural layers of Data, Intelligence and Workflow, applied to each stage of the VC value-chain.

At InReach we are obsessed about finding the next Spotify before anyone else. For this reason, DIG’s focus since the beginning has been one: discovery. As a result, InReach’s Platform Engineering Approach is key to solving this key strategic challenge. This is done through the architectural themes of live, constant and automatic, and extensible and integrable.

--

--