I shipped my first fintech MVP in 2014. It was a card-issuance product for a small Israeli bank — eight months of build, six weeks of regulator delay, and a launch that landed in the local press for two days and then went quiet.
I told myself: next one will be smarter.
Six MVPs later, I was still saying that.
It was MVP #7 — a payments product for a UAE-based investment firm — when the patterns finally clicked. Not because that one shipped well (it shipped fine, on time, modestly successful). It clicked because for the first time I noticed I'd done the same three things on every previous build, and I could see exactly when each one had broken.
This issue is those three patterns.
Pattern 1: The compliance question I always asked too late
For MVPs #1 through #6, my first compliance conversation happened in week 4 — after engineering started, after design finalized, after the founders had presented the demo to a board.
Every single time, the lawyer said something that changed the scope. Sometimes it killed a feature. Once it killed the entire product (a prepaid card flow that turned out to require a license the company didn't hold). Twice it didn't kill anything but added a 3-week delay because we needed a separate KYC vendor.
By MVP #7, I'd shifted the compliance conversation to week zero — before the wireframes, before the kickoff, before anyone had committed to build. And the conversation took 90 minutes.
The 90 minutes saved 3 weeks on average. Sometimes it saved a quarter.
The pattern wasn't "talk to legal earlier." Every PM gets told that. The pattern was what to ask in that 90 minutes:
Which entity holds the license? Whose name appears on the disclosures?
What's the worst-case audit finding if we ship this exactly as scoped?
Which feature, if removed, would let us ship without a new license?
The third question is the one nobody asks. And it's the one that surfaces the cut you can make today instead of in six weeks of legal review.
Pattern 2: The diagram I always drew wrong
For MVPs #1 through #6, my system diagrams were architecture diagrams. Boxes for services, arrows for API calls, a database at the bottom.
What I didn't draw was the money. Or the events. Or the licenses.
This sounds obvious in hindsight. It wasn't, at the time. Most product literature treats system architecture and business architecture as separate concerns — one for engineering, one for finance. In fintech, they're the same diagram, and drawing them separately is what creates the gaps where regulators find issues.
By MVP #7, I'd started drawing what I now call the Money Flow Map (which I wrote about in Issue #1 — go read that if you missed it). Five components: parties, events, rails, licenses, records.
When I overlaid that map on MVP #7, I found a missing license before we wrote a line of code. The fix was a 2-week vendor integration. Had I caught it post-launch, it would have been a 4-month rebuild.
I've drawn the same map for every fintech engagement since. It takes two hours. It usually cuts the feature backlog by 30–40%.
Pattern 3: The "demo first" mistake I kept making
For MVPs #1 through #6, I optimized for the moment the demo runs. The board presentation. The press release. The launch event.
This is a common product instinct, and in software-only categories it works. In fintech it doesn't. In fintech, the moment that matters is the audit, six months in. The demo is a cosmetic event. The audit is the structural one.
By MVP #7, I'd started designing every product around the audit. Specifically:
Every state change writes a record before the user sees the response. No "fire-and-confirm-later" flows.
Every external rail call has a correlation ID and a timestamp the user can verify. If they want to know "when did the money leave?" the answer is in the screen, not in our database alone.
Every disclosure that legal mandates appears in the UI at the moment of the relevant action — not in a footer, not in the FAQ.
Designing for the audit makes the product slightly less elegant on day one. It makes it dramatically more defensible on day 200. And in fintech, day 200 is the day that matters.
What changed for MVPs #8 through #11
After #7, the pattern stuck. The next four MVPs all started with a 90-minute compliance conversation, a Money Flow Map, and an audit-first design review. None of them shipped late. Three of them shipped under budget. One of them — a treasury product for a US scaleup — landed its first $50M in customer balances in 90 days.
I don't think I'm a smarter PM than I was in 2014. I think I just stopped optimizing for the demo and started optimizing for what compounds.
What to do this week
If you're scoping an MVP right now, do these three things in order, before next Monday:
Book the 90-minute compliance call before kickoff. Not as a review. As an input. Bring the three questions above.
Draw the Money Flow Map. Not the architecture diagram — the parties, events, rails, licenses, records map. Two hours. If you can't fill in all five components, that's the conversation you need to have with the team this week.
Audit-test the design. Pick the riskiest user flow in your MVP. Walk it as if a regulator were sitting next to you in six months, asking "when did this happen, who authorized it, what was disclosed?" The questions you can't answer are the ones to fix now.
If you only do one: #2.
If you're staring at a fintech roadmap and aren't sure which patterns from 11 MVPs apply to yours, that's exactly what my 2-week MVP scoping sprints surface — a build-ready spec with a defended cut list, anchored on the Money Flow Map. Book a strategy call: cal.com/barakazuga/strategy-call.
— Barak
The Regulated MVP is a weekly tactical brief for fintech and AI-in-finance product leaders. Every Tuesday.