Signals from the field.

Last time, I wrote about how we automated our LP reporting. I also said KYC/AML was next. “More on this soon,” I wrote, using soon in the way VCs tend to use it when talking about anything without a term sheet deadline.

Turns out, soon is now.

Compliance is no joke

If LP reporting was leg day, KYC/AML is probably the stretching afterwards. Nobody particularly enjoys it, nobody talks about it at demo day, but ignoring it isn’t really an option.

And yet, I suspect quite a few funds still handle parts of it in ways they would find slightly embarrassing if one of their portfolio companies did the same.

Ruth and I run a regulated fund. This comes with all the things you’d expect: identifying UBOs, PEP and sanctions screening, adverse media checks, CRS/FATCA, collecting documentation, periodic reviews and, most importantly, being able to demonstrate afterwards what you actually did.

None of this seems particularly difficult in isolation (not everyone will agree). However it takes a lot of time and the challenge is doing it consistently.

Our old process was a fairly familiar combination of email, Excel and PDFs. Ask someone for a copy of their ID. Save it. Update the spreadsheet. Check whether something is missing. Run the relevant checks. Set a reminder somewhere for documents that expire. Repeat.

Ruth who is our fund’s Anti-Money Laundering Compliance Officer (AMLco) did the hard work and made the actual compliance calls, I just had to review and acknowledge (4-eyes principle). It worked. But it was exactly the kind of process that we keep telling founders they should automate.

FundOps, an AMLco’s wet dream

So FundOps - which started life internally as “the Quarterly LP reporting thing” - has gradually become something much bigger.

Customer onboarding now happens through the same portal we use for reporting. An LP receives a magic link and uploads the documents we need there. No additional account or password.

The system extracts the relevant information from those documents and keeps track of things such as expiry dates. Screening is integrated into the workflow as well: sanctions, PEP and adverse media checks are launched during onboarding and again when we rescreen. CRS/FATCA is part of the same process instead of living in a separate PDF/email/spreadsheet universe

It also turned out there was no particularly good reason to limit this to LPs. We now use the same compliance stack as part of our portfolio onboarding due diligence: screening the company, founders, UBOs and directors, as well as VC funds and business angels. Same checks, same workflow, same audit trail. Different side of the cap table.

Across both LP onboarding and portfolio onboarding, we now have an even better record of what happened.

That last part matters.

AI can extract a passport. It can match names against lists. It can flag something that deserves a closer look. However it doesn’t magically make the compliance judgment but provides us with analysis, insights and recommendations. Ruth is our AMLco, and the actual decision still sits with her.

The second red pill

Building the LP reporting system taught me that AI dramatically reduces the distance between thinking someone should build this and actually building it yourself.

KYC taught me something slightly different.

The interesting use cases aren’t necessarily the shiny ones.

There are hundreds of processes inside a company that nobody would ever have bothered building software for. The problem wasn’t important enough to hire engineers for. Buying another SaaS product felt excessive (our case). So the process survived in the natural habitat of neglected business operations: Excel, email and inside somebody’s head.

AI changes the economics of fixing those processes.

KYC is a good example. I didn’t wake up one morning with a burning ambition to build compliance software. I just got increasingly annoyed that information we already had was being copied between systems, that checks had to be initiated manually and that we were maintaining spreadsheets to remember when other spreadsheets needed updating.

Once building software becomes cheap enough, those annoyances become worth fixing.

And the result isn’t just saving some time.

A few LPs have already gone through the new document flow. And what I like most is that it feels like part of the fund rather than an administrative process bolted onto it after the fact.

For a small fund, that matters. We’re never going to win by having a bigger operations team. But there’s no reason we can’t have the same or even better infrastructure.

And yes, we expect the same from our founders

We now use software we largely built ourselves to screen founders, before investing in them and subsequently telling them to automate more of their own operations. At least we’re consistent.

Quite a few of the companies we invest in will eventually encounter their own version of this. Maybe it’s export-control documentation, quality management, security reviews, customer onboarding or some wonderfully obscure industry-specific process involving PDFs and a government portal last updated in 2009.

Historically, there were basically two options: hire people to deal with it and/or buy software.

There is increasingly a third: build the narrow piece of infrastructure you actually need. That doesn’t mean every startup should start building its own operations stack.

But the threshold for build versus buy has moved dramatically.

We didn’t build FundOps because we want to become a compliance software company. We built it because it was becoming increasingly difficult to tell founders to automate repetitive processes while we were still doing ours manually.

The Excel psychopath in me has apparently metastasised into a compliance-automation psychopath.

Ruth finds this mildly concerning …

From a persistent engineering problem to a scalable “deep-tech” company: that is the core of the investment case behind BIMproFIT.

The decision came down to: a large and tangible problem, genuinely difficult technology, early market validation, an unusually strong founding team, and the potential to build a much broader platform for engineering automation.

Solving a problem the industry has lived with for decades

The building industry has already undergone significant digitalisation. BIM and software such as Revit have transformed how buildings are designed and modelled. Yet one critical part of the process remains largely manual: the engineering decisions themselves.

When designing HVAC ductwork, engineers still spend significant time determining routes, dimensions and configurations manually. The resulting design then needs to be modelled, checked for clashes and repeatedly modified whenever the building changes.

That can require approximately 140 hours of work for a small office building, with around 70 hours spent on ductwork layout and sizing alone which our reference calls confirmed during due diligence.

BIMproFIT is not a technology looking for a problem. It addresses a clearly identifiable and economically significant inefficiency.

Moving beyond drawing automation

This is what makes BIMproFIT different.

Existing BIM plugins make it easier for engineers to draw, model and check systems. But the fundamental question “what is the best engineering solution?” remains largely in the hands of the engineer.

BIMproFIT aims to automate that layer.

Its technology automatically generates HVAC layouts, sizes ducts and optimises the solution for factors such as cost, energy consumption and spatial constraints. The result is then integrated directly into the Revit environment.

The system can generate an optimised design in less than a minute. Pilot projects produced collision-free solutions and demonstrated at least 10% CAPEX savings and 6% energy savings compared with the manual baseline.

This isn't about making an existing workflow slightly faster. BIMproFIT is automating an engineering decision that has traditionally required human expertise and extensive iteration.

Difficult technology creates a meaningful moat

The company's core optimisation engine originates from two PhD research programmes at the University of Antwerp. The underlying problem is genuinely complex: routing and sizing need to be optimised simultaneously while respecting airflow, pressure losses, dimensions, regulations, costs and spatial constraints.

That gives BIMproFIT three potential sources of defensibility: the depth of the underlying algorithms, the accumulation of real-world project data, and the integration of the technology directly into the existing engineering workflow.

A competitor can't simply replicate the interface, they'd need to solve the same optimisation problem, build the same engineering knowledge, and validate it against real projects.

The market was already sending signals

BIMproFIT also had something many pre-revenue companies lack: strong early market pull. The company had received unsolicited inbound interest from firms asking for demonstrations and commercial discussions. A main contractor was already confirmed as a first paying customer ahead of the planned beta launch, and some potential customers had even expressed interest in investing in the company themselves.

Our own reference calls confirmed this: the market wasn’t merely saying “this sounds interesting”; potential customers were already demonstrating a willingness to test and adopt the technology.

The right team for the problem

Challenging technology only becomes investable when the team can turn it into a business. BIMproFIT’s founding team combines two complementary profiles.

CEO and co-founder Sandy Jorens combines a PhD background with hands-on experience inside engineering firms and HVAC contractors; precisely the organisations BIMproFIT is targeting. She understands both the technical pain point and the commercial environment the product needs to be adopted into.

CTO and co-founder Zakarya Kabbara developed the core optimisation engine during his own PhD and pairs that with knowledge of HVAC engineering, software architecture and cloud infrastructure.

The two founders have worked together for several years; technology expertise, engineering expertise and direct customer knowledge, in one founding team.

Why now?

Three structural forces are converging. First, BIM adoption is expanding, growing the installed base of digital building models and Revit users. Second, labour shortages and rising material and engineering costs are making design efficiency increasingly important. Third, the optimisation technology required to solve these problems has only recently matured enough for practical deployment.

The technology is becoming possible at precisely the moment the economic need for it is increasing.

From HVAC automation to a broader platform

Perhaps the most important part of the thesis is that BIMproFIT isn’t positioning itself as a single-purpose HVAC tool. The company starts with ductwork design, but its architecture is built to expand the same optimisation engine into other MEP disciplines: piping, plumbing, electrical systems and fire suppression.

That materially increases the platform’s potential value: a customer that starts with HVAC could eventually adopt multiple BIMproFIT modules, increasing revenue per customer without requiring an entirely new customer base for every application. The long-term ambition is bigger than a better HVAC plugin.

BIMproFIT aims to become an automation platform for the engineering of building services.

A calculated bet on commercial scale

The investment wasn’t made because all risk had disappeared. At the time of investment, BIMproFIT was still pre-commercial. The next major milestone is converting existing interest into paying customers and proving that adoption can be repeated across the market.

The technical risk had been substantially reduced through years of research, pilot projects and customer validation, and the market signals were encouraging.

The remaining question was whether the company could turn that technology and early demand into a scalable business. That’s where venture capital comes into play.

Why BIMproFIT fits the imec.istart future fund investment thesis

Ultimately, the investment case can be summarised as follows:

• A painful and measurable problem in a large industry.

• Deep technology that addresses engineering optimisation rather than simply digitising existing manual work.

• Early customer validation and strong inbound commercial interest.

• A defensible technological position built on years of academic research and accumulating project data.

• A founding team combining technical depth with direct industry experience.

• A platform opportunity that can expand from HVAC into the broader MEP engineering stack.

BIMproFIT occupies a currently under-served layer of the BIM ecosystem: the layer between the digital building model and the optimised engineering solution.

We're not simply investing in software that helps engineers draw ducts faster. We're investing in the possibility that a genuinely difficult engineering problem can be automated at scale, and that the technology behind this first application can become the foundation for a much broader platform for automated building-services design.

It's a bet on three things coming together: the technology works, the market is ready, and BIMproFIT has the team and position to turn a strong first application into an international technology platform.

More info: www.bimprofit.com

I’m a freak in the sheets. Spreadsheets. XLOOKUP, dynamic arrays, pivot tables that would make a McKinsey analyst emotional. A genuine psychopath. I’ve made peace with this.

For years it was a superpower. Then one day I looked up and realized: I’m a VC who’s backing technical founders, spend my days telling them to ship fast and automate everything while I’m still manually pulling together numbers, exporting PDFs one by one, cross-referencing bank statements by hand. Every. Single. Quarter.

I was the personal trainer who skipped leg day.

So I built something. With Claude .. or should I say Claude built something with me 🤔

Anyhow, for someone with a legacy developer background, it felt like the dormant part of my brain finally had the right tools again.

The result: portal.imecistartfuturefund.com. Per-LP personalized quarterly reporting. PDF reports generated automatically. Bank transaction reconciliation. Capital call tracking. Invest Europe compliant. Magic link login.

When the first PDF report came out - properly formatted, correctly calculated, looking genuinely professional … I felt pride 🤩. The slightly embarrassing kind you get when something you built actually works.

I may have stared at it longer than necessary.

Real software, real problems

It wasn’t all clean. Magic link authentication - elegant in theory, one-click login, no passwords - broke for a handful of LPs in production. Corporate firewalls and anti-virus software eating one-time tokens. Unglamorous. Annoying.

But here’s the thing: diagnosing the issue with AI took minutes, not days. Implementing the fix even faster. The feedback loop is just different now.

Here’s the actual red pill

It’s not that AI writes code for you (spoiler, it does). It’s that the mental model shifts. “I need someone to build this” becomes “I can just build this.” Once that happens, you start looking at every painful manual process differently.

LP reporting was the obvious first target - medium frequency, high pain, zero strategic value. KYC/AML is next (more on this soon). The list is long.

For imec.istart future fund the goal isn’t to become a software company. It’s to stop bleeding hours on things that add no alpha and spend that time on what actually matters: finding the right founders, helping them through the hard moments, making better bets.

… and we expect the same from our founders

We expect the founders we back to increasingly automate the boring, repetitive parts of their operations such as customer onboarding, compliance workflows, internal reporting so they can move faster with leaner teams. If you’re not building that muscle now, you’re already behind.

The Excel psychopath in me isn’t completely gone (yet). But the gap between “spreadsheet workaround” and “actual product” collapsed. And for a geek who’d quietly missed building things that’s not just useful.

It’s fun again. 🤓

I am not a designer. I have an engineering background, I spent years in consulting and product management, and I now run an early-stage VC fund. None of those things make you good at picking fonts or laying out a homepage.

Our old site was functional in the way that a grey filing cabinet 🗄️ is functional. It held things. Nobody was excited about it. I was not proud of it, and I probably should have fixed it sooner than I did.

So I rebuilt it myself. With Claude Code.

What got me there

Running a small early-stage fund means being ruthless (My co-GP is Ruth, which makes “ruthless” unavailable as a word around the office. We manage.) about where you spend time and money. Paying an agency to build something we couldn’t maintain ourselves never made sense. But neither did living with a site that embarrassed us when a founder Googled us before a first meeting.

What changed my thinking was realising that websites have a new job description 🤖. When a founder researches a potential investor today, it’s not just their eyes scanning your pages. Increasingly it’s an LLM pulling structured context about your focus, your team, your portfolio. If your site doesn’t serve that use case, you’re invisible in a channel that’s only growing. That felt like a problem worth solving properly.

I also just wanted to build something. I spent years as an software engineer before consulting, product management and VC ate me. The itch doesn’t go away.

How I built it

I used Claude Code, Anthropic’s agentic coding tool, as my primary collaborator. I directed, it wrote, I reviewed and pushed back, it revised. The workflow is closer to working with a very fast junior developer who never gets tired than it is to typing prompts into a chatbox. You still need to know what you want. You still need to catch mistakes. You still need to make choices on architecture. But the gap between having a clear idea and having working code closes dramatically.

The stack I landed on: (feel free to skip 🤓)

Next.js 14 with the App Router, TypeScript 5 in strict mode, Tailwind CSS for styling with every color and spacing value locked in a config file. This last part matters more than it sounds: when the design system lives in one place, it’s hard to accidentally violate it, which is useful when you’re not a designer and your aesthetic instincts are not always to be trusted.

Content lives in Markdown files. This is the right call and I’ll defend it. Markdown is readable by humans, parseable by machines, version-controllable in Git, and editable without touching a database. In a world where AI agents increasingly read your content as structured input rather than a rendered page, having your source material in clean flat files is quietly powerful. It also means I can update a portfolio entry or add a news item in under two minutes without opening anything except a text editor.

Animations are handled by Framer Motion 11. The App Router flips React’s default so components render on the server unless I explicitly opt into the client. I treated the ‘use client’ directive as a cost to pay only when I genuinely needed browser APIs or interactivity. The result is less JavaScript shipped to the browser than a typical React app, which means a faster, leaner site.

Every icon is a hand-authored SVG component in TypeScript rather than pulled from a library. Two reasons: tree-shaking with large icon packages is messier than it should be, and I wanted every icon to use currentColor so they’re theme-aware at zero additional cost. The technology focus section takes this further: each icon, an attention matrix, an inference graph, scan rings, and others, is individually hand-drawn within a 100x100 viewBox, its own geometry, its own logic. No shared system. Every one built from scratch.

The thing I’m most proud of: Cmd+K ⌨️ (Ctrl+K for Windows users)

Hit it anywhere on the site and a command palette opens. You can navigate the entire site without touching the mouse: search pages, jump to portfolio companies, pull up publications. The underlying library is cmdk, but the fuzzy search logic is custom: a character-density scoring algorithm that ranks results by how tight the matched characters are, not just whether they appear somewhere in the text.Thanks for reading imec.istart future fund Substack! Subscribe for free to receive new posts and support my work.

No Algolia. No external search index. A few dozen lines of TypeScript.

It’s the kind of feature that makes a site feel like a tool 🛠️ rather than a brochure. Which is, increasingly, what I think a fund website should feel like.

What I learned

Building this way doesn’t make you a designer. The site looks like what happens when an engineer with “reasonable” taste points a capable AI at a clear problem and refuses to stop iterating until it feels right. I can live with that description.

What surprised me most was how fast the feedback loop became. Idea to working feature in sometimes minutes. See something that bothers you, fix it before dinner on your phone. That pace changes what’s worth attempting.

This is v1. It won’t stay v1.

(update: it is already v3 in the meantime)

I’m treating the site as a living thing. The whole point of building it this way is that I can move quickly. New portfolio additions, updated thinking, better features.

There are also Easter eggs 🐣. I’ll say nothing more. Go find them.

If you want to follow along as the site evolves, or as we keep writing, subscribing here is the easiest way.

→ Visit our new site

The ESA Rising Stars 2025 list captures a real shift in European space.

We are proud to see VEOWARE SPACE and EDGX recognised alongside an outstanding group of companies. Not as experiments, but as businesses building core infrastructure for the next decade of space activity.

VEOWARE designs and manufactures high-performance attitude control systems, including Control Moment Gyroscopes (CMGs) and reaction wheels. This is deep, mission-critical hardware. When pointing accuracy, agility, and reliability improve at this layer, entire satellite platforms become more capable. This is where durable value is created quietly but decisively.

EDGX operates higher in the stack. As satellites generate more data and latency becomes a constraint, compute moves closer to orbit. EDGX is building space-native edge compute, designed from first principles for radiation, power constraints, and autonomous operation. This is not terrestrial compute repackaged for space.

Different layers. Same momentum.

European space startups are moving from bespoke missions to productized infrastructure with global ambition. That transition is hard, but it is now clearly underway.

Congrats to VEOWARE SPACE, EDGX, and the full ESA Rising Stars 2025 cohort. European space is accelerating, and the foundation is being built now.