Skip to content
Faidhi Fahmi.Contact
All selected works
ProductTechnicalTeam leadershipGrowth

Building an insurance platform, and the team that shipped it

Organisation
iLyF · Easy, Instant Insurances
Role
Co-founder & Chief Product Officer · Product & Technical Delivery Lead
Period
Sep 2022 – present · Malaysia

Co-founded iLyF and led product, engineering, and growth for a motor insurance app, with a distributed team across three countries.

At a glance

Situation
We started iLyF to make motor insurance in Malaysia an in-app purchase, from quote and payment through to road tax delivery. It began as an idea and a small team, not a working funnel.
Stakes
Every link in the chain had to hold at once: ad, quote, checkout, fulfilment and renewal. One weak link and the unit economics collapse quietly.
My role
Co-founder and Chief Product Officer. Owned the architecture, insurer integrations, growth engine and analytics, stayed hands-on in the technical calls, and ran a 10–15 person team across three countries.
Constraints
Regulated product, five insurer APIs outside our control, distributed team, startup budget and timelines.
What changed
  • 200K–250K installs and 150K–200K registered vehicles in 30 months
  • Monthly GWP grew ~8×. Net return on ad spend crossed 1.0 in Q4 2024
  • A delivery rhythm that held for three years and 50-odd releases
Read this if
You are building a complex, regulated product and need one accountable lead across product, engineering and growth.
app installations in 30 months
200K–250Kapp installations in 30 months
registered vehicles
150K–200Kregistered vehicles
growth in monthly gross written premium
~8×growth in monthly gross written premium
annual gross written premium
RM2M–3Mannual gross written premium
return on ad spend, through Q4 2024
0.5 → 1.65return on ad spend, through Q4 2024
across 3 countries
10–15 peopleacross 3 countries

How the system actually worked

The five systems behind one appOne app sits on top of four systems: an insurer integration layer normalising five providers into one contract; quote and checkout, returning under two seconds at peak; fulfilment, which physically delivers a road tax sticker; and growth and renewal, which acquires customers and then wins their second year at 60, 30, 7 and 1 days before expiry. All four rest on a fifth layer drawn as a foundation: instrumentation, executive dashboards and release governance.One appquote, pay, insured, road tax deliveredInsurerintegration layerFive providers,one normalised contractQuote andcheckoutUnder two seconds at peak,payment, cover noteFulfilmentRoad tax deliveredto the doorGrowth andrenewalAcquisition, then renewalat 60/30/7/1 daysInstrumentation · executive dashboards · release governancethe layer that kept the other four honest

Scroll the figure sideways to read it, or turn your phone.

The five systems behind one app. The dotted band underneath, covering instrumentation, executive dashboards and release governance, is what kept the other four honest.
How the team actually ranA delivery cycle drawn as a loop. One written priority per cycle leads to a spec with acceptance criteria, then build, then a QA and UAT gate. Work that fails the gate returns to build, and the return path is part of the design, not an exception. Work that passes is demonstrated against real production-shaped data rather than mockups, then released. Ten to fifteen people across three countries sustained this bi-weekly to monthly for three years and roughly fifty releases.One writtenpriorityper cycle1Spec withacceptancecriteria2BuildQA / UAT gate3Demo againstreal datanever mockupspasses4fails the gate → back to build10–15 people across 3 countries · bi-weekly to monthlysustained for three years and roughly fifty releases

Scroll the figure sideways to read it, or turn your phone.

  1. One written priority per cycle. Not a ranked list; one, written down, so that “what are we doing” is never a matter of recollection.
  2. Acceptance criteria in the spec, so “done” is not a matter of opinion between a developer and a reviewer.
  3. The gate is allowed to refuse. Work that fails goes back to build, and that return path is the reason the gate is worth having at all.
  4. Demos run against real production-shaped data. A demo on seed data hides exactly the problems you need to find.
How the team actually ran. Three countries, one written priority per cycle, and a QA/UAT gate that could send work back to build. Sustained bi-weekly to monthly for three years.

Stack & practices

  • AWS
  • MySQL
  • Node
  • React
  • Segment
  • Mixpanel
  • Sentry
  • Agile delivery
  • QA/UAT governance

Got a problem shaped like this one?

A short conversation is usually enough to see if there's a fit.

Email meRead another case study