Indy Van Canegem

Hi Vercel 👋

I build AI products and software platforms from idea to production. This is a longer, weirder version of a cover letter.

Who am I?

I'm Indy, a developer based in Belgium. I already know what you're thinking: Belgium to San Francisco, that's a real timezone gap. It is a bit of a stretch, but I'm not going to let that stop me. Belgium is the capital of Europe, so havig someone here could be a real asset for Vercel. Let me show you anyway:

Psst, that's forty lines of Intl.DateTimeFormat and a setInterval. No dependencies, no build step, because apparently I can't help myself.

Nine hours apart isn't nothing, but it's manageable. I already run my own consultancy on the side, which means shifting my schedule around someone else's day is not new territory for me. I'm also happy to sort out whatever the correct legal setup would be, I've been freelancing through my own company for over a year, so contracting isn't an unfamiliar shape.

For context: I currently work full-time as a Staff Engineer for an AI consultancy firm called Faktion, and I'm not actively job-hunting. But this posting was specific enough, and close enough to what I already do, that I figured a normal application wouldn't do it justice.

My story

My path has mostly been a series of "move to the tech that actually solves the problem" decisions. I started on ERP tooling in C# and .NET at a small shop called XERXES — track-and-trace, timesheets, the kind of internal software nobody sees but everybody depends on. While consulting, I worked for Belfius Bank. I was port of the 'Component team'. We build reuable components using web components spec that are reused for multiple apps (Banking app, REBEL investment banking app, main website, etc.). After that I joined Metamaze in 2021, an early-stage startup building an intelligent document-processing platform using traditional machine learning models.

I was there close to day one: architecture, implementation, monitoring, and the unglamorous operational glue that decides whether a startup survives contact with real customers. Metamaze was named Start-up of the Year in Belgium in 2022, and got acquired by Duco in 2024. Metamaze was a spin-off from Faktion.

From there I moved to Faktion, an AI solutions & advisory shop, where I've spent the last two years mostly building AI. I went from Senior Full Stack Developer to Staff Engineer in under 16 months, and most of that time has gone into shipping generative-AI and agentic systems — 10+ of them at this point — wired into real data and real businesses, not demos for a slide deck. Alongside that I run Reacture, my own software & AI engineering consultancy.

Why me?

I like experimenting with tools that make other developers' lives less annoying. At both Faktion and Reacture, I've ended up being the person who introduces the thing nobody asked for but everybody ends up using. A few examples:

Component registries, before it was cool to have opinions about registries

I built component registries inspired by shadcn/ui — registry.reacture.io as demo and Faktion's internal registry.faktion.com — specifically so teams stop copy-pasting buttons between projects and start sharing them instead. Given that shadcn's registry format basically became the industry's component-distribution mechanism (and v0 leans on the same idea), this is territory I already have opinions about:

// installing a component from a private registry,
// same mental model as shadcn/ui — just pointed at your own catalog
npx shadcn add https://registry.reacture.io/r/data-table.json

I'm picky about component APIs the same way — explicit over magic. I'd rather see <Badge variant={cva(...variants)}> than five boolean props and a className escape hatch that quietly turns the component into someone else's problem.

Next.js and TanStack Start — knowing more than one platform

Professionally I've shipped on both Next.js and TanStack Start. I'm not precious about either. Knowing multiple platforms is an advantage: you steal the better techniques, leave the worst parts behind, and end up with clearer instincts for what actually belongs in a design versus what a framework is just making you do. That cross-pollination is how I prefer to build — borrow what works, omit what doesn't, and keep the product in charge instead of the framework.

Agents you can actually trust, not just ones that sound confident

Most of my last two years has gone into agentic and generative-AI systems, and the part I care most about is the part nobody puts in a demo: evaluation. I've built AI evaluation tooling, wired agents up to OpenTelemetry for tracing so we can see what an agent actually did instead of just what it claims it did, and used pgvector for retrieval instead of trusting a vector store as a black box.

const result = await runEval(agent, {
  cases: goldenSet,
  // score correctness, not vibes
  scorers: [correctness, groundedness, latency],
  trace: "otel",
});

An agent that can't be traced and can't be scored is just a chatbot with better marketing.

Mastra — and what Vercel DX could steal from it

I've got a lot of production mileage with Mastra. Enough that I think it currently supersedes everything else in the TypeScript agent ecosystem. That's not a slight at the AI SDK — it's a note that the DX bar for agents has moved, and Vercel is in a uniquely good position to absorb the parts that actually work in production.

At Reacture I've been building an SDK around Mastra specifically to make that production path less painful:

• Python ↔ TypeScript streaming — wrappers around the useStream hook so pythonic agents talk to TypeScript frontends without inventing a second protocol.
• Skills, workspaces, and file-based agents — treating agents as composable units you can check into a repo, not as a blob of prompt strings trapped in a dashboard.
• Observability we actually own — spinning up our own ClickHouse and OpenTelemetry collector so traces aren't rented from someone else's SaaS and disappear when the bill gets awkward.

// pythonic agent on the backend, useStream on the frontend —
// same mental model, no custom SSE parser inventing itself every sprint
const { messages, status } = useStream({
  agent: "workspace/triage",
  api: "/api/agents/triage",
});

The takeaway for Vercel isn't "rebuild Mastra." It's that agent DX has a clear shape now: streaming that crosses language boundaries cleanly, file-based definitions you can review in a PR, skills as composition, and observability that ships with the platform instead of being bolted on after the first outage. That's the bar I'd want the AI SDK and Workflows to clear.

The boring infrastructure nobody notices (on purpose)

I also built @reacture-io/iso-locale, a tiny library for countries, languages, dialects, and currencies against ISO standards, with Zod keeping people from inventing their own format by accident:

import { Country } from "@reacture-io/iso-locale";

Country.parse("BE"); // validated, typed, done

None of this is exciting on a resume. It's exactly the kind of thing that quietly makes everyone else's week better, which is the whole point.

Shipping, not just building

I've taken several SaaS products at Faktion from a rough MVP to something that had to survive real customers, and I was there for Metamaze's whole arc — zero to acquisition. I don't hand off code and disappear; I'd rather help decide what to build, how to build it, and how to keep it running once the novelty wears off.

Skills

From my LinkedIn profile, plus the stack I actually ship with day to day.

Category	Skills
Top skills	Full-Stack Development, TypeScript, React
Languages	TypeScript, JavaScript, C# (forgotten by now), Python, Go (very recently learned & applied)
Frameworks & libraries	React, Next.js, TanStack Start, Vue, .NET / Web API, Mastra, Zod, shadcn/ui, Web Components
Architecture	Software architecture, system design, technical scoping, platform design
AI & agents	Generative AI, agentic systems, evaluation tooling, OpenTelemetry, pgvector
Cloud & IaC	Terraform, AWS, Azure, GCP — whichever the client project needs (always project-dependent at Faktion)
Platform & DX	Component registries, SaaS platforms, observability (ClickHouse + OTEL), ISO locale tooling

Soft skills

I like being dropped into messy, half-defined problems — those are usually the interesting ones. I have opinions and I'll argue them, but I'll also change them the moment better information shows up. I prefer boring infrastructure over clever infrastructure, and I optimize for the developer who inherits the codebase after I've moved on.

At Faktion I'm currently the only staff engineer, which means every sales trajectory runs through me — not just technical architecture, but budget discussions, scoping, and the trade-offs that decide whether a deal is viable. That puts me in the room with clients a lot. I'm comfortable in that setting: clear professional communication, no jargon for its own sake, and a bias toward making the technical picture understandable for non-engineers.

Being client-facing doesn't mean saying yes to every ask. When a demand doesn't make sense — timeline, scope, architecture — I push back, and I do it with facts: cost, risk, maintenance burden, what breaks later if we take the shortcut now. Clients tend to respect that more than flexible agreement that falls apart after the contract is signed.

What the future holds

Vercel's current stack — AI SDK 6, Fluid Compute, Sandbox, Workflows, v0 — lines up unusually well with what I've spent the last two years doing. A few things I'd genuinely want to work on:

• Agent DX informed by Mastra — bring the production patterns that already work (streaming across Python/TS, file-based agents, skills, owned OTEL) into the AI SDK and Workflows without making developers reinvent them.
• Agent observability on top of the AI SDK — tracing and evaluation as first-class citizens, not an afterthought bolted on post-launch. ClickHouse + OTEL is what we've already run; I'd love to help make that shape feel native on Vercel.
• Registry tooling that plays well with v0 — I already live in this space; there's room to make private/enterprise registries feel as good as the public shadcn ecosystem.
• Evaluation-driven development for Workflows and Sandbox-based agents — golden sets, regression scoring, the stuff that turns "it worked in my testing" into something a team can trust in production.
• The unglamorous DX work — shared configs, better defaults, fewer footguns — because that's usually what actually moves adoption, not the flashy feature.

After hours

Curious about

Things I keep reading and poking at, independent of what I get paid to do:

Away from the keyboard

Most of my non-work energy goes into training and being outdoors. I'm currently training for my first OCR marathon. I'm a black belt in judo, stay consistent with fitness year-round, I'm a licensed scuba diver, and I'm a fairly fanatic snowboarder whenever there's snow within reach.