Building a fintech MVP is different from building a regular SaaS MVP. The compliance layer alone adds complexity that most startup advice skips entirely. Here’s what I learned building Y-tech’s MVP solo, and what I’d do differently.
The stack: React Native (cross-platform, mobile-first), AWS (scalability, EU data residency), PostgreSQL for transactional data, and an event-driven architecture from day one. That last one was the right call — it made the audit trail almost fall out of the design for free.
What I’d change: I spent too long on infrastructure choices that don’t matter yet. Blockchain anchoring for transaction integrity is in the plan for the production bank — it’s the right answer when you’re handling real money at scale. But I caught myself designing for that world before I’d proven the flows in this one. The MVP didn’t need it, and thinking about it cost me time I should have spent on onboarding.
Compliance surprised me most. I knew fintech was regulated. I underestimated how early the compliance thinking has to start — not at licensing time, but at architecture time.
KYC/AML shapes your onboarding flow. GDPR shapes your data architecture. PSD2 shapes your API design. Skip these at the start and you’re refactoring everything later.
The upside: building compliance-first made the architecture cleaner. Immutable audit logs, consent management, data minimisation — these are good engineering habits regardless of regulation.
I almost got the ordering wrong. Early on I wanted to build NeuroOffice (our AI business suite) first, because it’s the most interesting part. I didn’t. I forced myself to prove the core banking flows first — account creation, transfers, card management, notifications. Boring, essential, correct.
NeuroOffice only matters if the banking foundation is trustworthy. Order matters.
What “MVP” actually means in fintech. In most SaaS, MVP is the smallest thing that delivers core value. In fintech, MVP is the smallest thing that delivers core value AND passes a security review AND handles edge cases that could cause real financial harm AND has audit trails for every state change.
That’s not optional complexity. That’s the job.
Something I wish I’d understood sooner: the Bank of Lithuania runs a regulatory sandbox — a programme where selected fintechs test innovations in a live environment with real users, under the regulator’s supervision, for up to 6 months. It’s not a shortcut around licensing; it’s a structured way to test with the regulator in the room.
I haven’t gone through it. But reading the selection criteria early would have shaped my design decisions, because it tells you exactly what a regulator wants to see. That’s free information most founders never look at.
Where we are now: MVP built. The flows work - registration, virtual transfers, card freeze/unfreeze. The AI layer is genuinely live: eight NeuroOffice agents running on real models, with testers actively using them.
What we don’t have is live banking infrastructure. No real money, none of the actual banking security stack. That comes with the licence and the funding. The MVP proves the product. The licence makes it real.
I’d rather say that plainly than dress up a prototype as something it isn’t.
Happy to answer questions on any of the technical decisions — especially the compliance architecture. That took the most learning.
—
Andrew, founder of Y-tech Bank. ytechbank.com
Top comments (0)