Case study · TakeNote

TakeNote.ai

Founding engineer on an Oxford-based AI meeting-intelligence startup. Took the web product from an empty repo to a launched, fully functional v1.

EmptyRepo state at startno code, no schema, no surface

LiveRepo state at launchv1 shipped end-to-end

0Team size2 co-founders, 2 engineers

~0 yrTenure2023 — 2024

Outcome

Took TakeNote.ai from an empty repo to a launched, fully functional web product as a remote founding engineer for an Oxford-based AI startup. Departed before the team raised its next round; the founders pivoted the product into the UK financial-compliance space, where it lives today.

An Oxford-based AI startup, with founders who had real CVs.

TakeNote.ai is an Oxford, UK-based AI meeting-intelligence startup. It was co-founded by Robin Paine — former CTO of the London Stock Exchange and the London Metal Exchange, with a career spanning M&A, programme management, and large-scale technology delivery — and Trung Thanh Tran, an AI researcher and Data Scientist at Pixta Vietnam, working in foundation models, computer vision, and LLMs.

I joined as a founding engineer on the web side, working remotely from Bangladesh alongside Md. Maruf Ahmed — a Software Engineer with a Shopify-app and React/Node.js background. The four of us were the team: two co-founders, two engineers.

Empty repo to launched product.

The brief was straightforward in scope, hard in execution: take the founders' vision for an AI-powered meeting intelligence product and turn it into something a customer could log into and use. There was no codebase. No schema. No deployed surface. There was a vision, two co-founders, and the two of us.

I owned the parts of the stack closest to the user:

The web app shell — routing, layout, theming, state ownership
Auth and the session boundary — including the security and data-residency thinking that an FCA-adjacent product needs from day one
The note-taking surface itself — editor, persistence, sync behaviour
Build and deploy plumbing for the web side

Maruf and I split the engineering load; the co-founders held vision, AI architecture, and customer development. In a four-person company, scope isn't assigned — it's chosen. "Founding engineer" meant exactly what the title implied: there was no one to escalate to.

A v1 product. Live, end-to-end.

We launched. The product worked. Users could sign up, run meetings, get transcripts and summaries — the full loop the founders had specced.

What we didn't hit was first revenue before my departure, and the company didn't raise its next round on the original product positioning. I'm saying that plainly because the alternative — pretending the v1 was a commercial success — wouldn't survive a single recruiter call. What we shipped was a working product. What didn't happen was a market.

The reality of remote founding-engineer work.

I left before the next chapter, for reasons I'll lay out plainly because they're instructive:

The company wanted in-person operation. The founders are in Oxford; I was in Bangladesh. As the product matured the team needed tighter, in-room iteration. Remote founding-engineer work is a real model, but it has limits for an early-stage company.
Equity-related circumstances. I joined an equity-funded UK company on a remote arrangement. As the situation evolved, the equity arrangement and operating model didn't converge in a way that worked for either side.
The next round didn't come together. The team didn't close additional funding on the original product positioning, and the project went into a transition period.

I made the call to step away on good terms before the situation forced one.

The product I built kept going — into a different market.

The site at takenote.ai is live today, but the product has pivoted. It's now positioned specifically for FCA-regulated financial advisers — the UK financial-services compliance niche. The current version touts a 3% Word Error Rate, MiFID II 5-year retention, FCA suitability note structure, and UK data residency on Azure UK South.

That pivot isn't mine to claim. But the foundation we shipped in v1 is what the team had to build on top of. The product I helped take from an empty repo became the chassis for a more focused, more defensible market positioning. That's as good an outcome as a founding engineer who stepped away early can hope for.

Three lessons from being a remote founding engineer.

A founding engineer's job is to ship the v1, not to guarantee the market. I owned the technical execution — empty repo to launched product. I didn't own customer development, fundraising, or pivot strategy. Being clear about which lever you're pulling is the senior version of "I'm a founding engineer." Anyone who claims they own all of it on a four-person team is selling something.
Remote founding-engineer arrangements need more contractual care than they get. Equity, scope, geography, and decision rights all have to be aligned in writing before the first commit, not after the first product. I learned this the harder way at TakeNote, and it's shaped how I'd sign onto an early-stage equity arrangement now.
Stepping away on good terms is a senior skill. When the operating model and the company's needs diverge, the engineer who exits cleanly — code documented, knowledge transferred, no scorched earth — leaves both parties in a better place than the one who hangs on. The TakeNote team kept building after I left. That's the win condition.