Madalin Stefirca took on the role of CTO at Maxcode two years ago. Since then, the technology landscape has shifted faster than ever, with AI moving from promise to boardroom priority, regulatory pressure intensifying, and a market that often acts first and thinks later.
Madalin’s approach is different: not slower, but more deliberate. Grounded in the belief that, in a regulated environment, you can’t build on assumptions, on hype or on the shortest path to a demo. That compliance isn’t something you bolt on afterwards. And that integrity isn’t a value you pay lip service to on a website – it’s something you demonstrate every day, and especially in the choices you make when things get difficult.
After two years at the helm, it’s time for a conversation with him: about what he’s learned, what he would no longer build, and why he believes, for many companies, the real day of reckoning is still to come.
You’ve been CTO at Maxcode for two years now. What has been the biggest change in your own approach to building technology in a regulated environment?
The biggest shift is that I stopped treating compliance as a constraint and started treating it as design input. Early on, regulation felt like something you addressed after you’d built the software. Now, it shapes architecture decisions from day one. Data residency, audit trails and access control shouldn’t be features you try to fit in later. Especially in fintech, the cost of getting this wrong isn’t just a bug report; it’s a regulatory finding or a client losing their operating license. That changes how seriously you should take it.
If you compare your current mindset with your early days as CTO, what do you understand now that you didn’t fully see back then?
Initially, I underestimated how much of this work is organizational, not technical. The technical problems are solvable. Other problems are harder to tackle. For example, who owns a decision when it sits between business and engineering? How do you maintain standards under delivery pressure? And how do you build a team that actually internalizes quality rather than performing it? In the early days, I thought only about systems. Now, I think at least as much about people and processes.
Everyone talks about trust in fintech, yet very few actually build for it. What does “building for trust” mean in practice?
It means making the system’s behavior predictable and explainable – not just to engineers, but also to the people operating it and the regulators auditing it. It means your error handling is as well-designed as your happy flow. It means when something goes wrong – and something always goes wrong! – the client isn’t surprised, because you already told them what to expect. Trust is built in the moments of failure, not the moments of success. If your communication is honest, especially during incidents, and your recovery is clean, that builds more trust than six months of smooth operation.
When it comes to integrity, where do you see things going wrong in the industry today?
Pressure to increase the speed to market is quietly eroding documentation, testing discipline, and even quality. Companies promise timelines they know are unrealistic because the commercial pressure to win the deal is stronger than their professional discipline to tell the truth. Then the project overruns, quality suffers, and both sides rationalize it. The other factor that harms integrity is technical debt that gets hidden behind good demos. A system can look very capable in a proof of concept, but be completely unfit for production scale or regulatory scrutiny.
Have you ever said “no” because something didn’t feel right from a trust or integrity perspective, even though it was technically possible?
Yes. The clearest cases were around data – specifically what you could do with data versus what you should do with it. Technically, you can aggregate behavioral signals in ways that are commercially interesting but would make a regulator uncomfortable or end users reject if they knew. We’ve pushed back on that. Other recurring cases have been shortcuts in testing or validations under deadline pressure. It’s technically possible to ship without, but it’s not something we are willing to do.
There’s a lot of buzz in the market right now around new technologies, especially AI. What do you think is real, and what is just hot air?
The productivity gains in software development are real. I’m running a controlled internal experiment on this, and it’s clear that AI-assisted coding, documentation, and code review genuinely compress timelines when the engineer using it knows what they’re doing. What’s largely hot air: autonomous AI agents replacing complex judgment in regulated processes. The demos look impressive. But the production behavior under edge cases and adversarial inputs is a different story. Another exaggeration is the idea that AI removes the need for deep domain expertise. It doesn’t. It amplifies whoever is holding it.
Still on the topic of AI, how do you balance innovation with responsibility in a regulated environment?
We draw a clear line between AI that informs and AI that decides. If AI is helping a human make a better decision, we embrace it. If AI is making the decision itself, we slow down and apply much tighter scrutiny. The reason is simple: regulators need to know who is accountable for every outcome. “The model recommended it” is not an answer they accept. So we make sure there is always a human in the loop for anything consequential, and we document that explicitly.
What wouldn’t you use AI for, even if it were technically possible?
I wouldn’t use it without a documented human review step for final approval or rejection decisions in credit, compliance screening, or fraud flagging – not because AI can’t produce good output, but because the accountability framework isn’t there yet for it to be an acceptable audit trail. Nor would I use it without expert review for generating client-facing legal or compliance language. In that context, the risk of a confident error is too high.
Many companies boast about their speed of innovation, but you seem to prefer understanding things deeply before building. Why is that so important to you?
Because most failed projects I’ve seen failed not due to a lack of ambition but due to a lack of understanding of the problem. The wrong thing is built, confidently. Especially in regulated environments, the cost of rework is not just time; it’s re-certification, re-validation, client re-onboarding. Gaining a deep upfront understanding is cheaper than correcting later. The goal is to solve the client’s problem reliably. That sometimes requires a novel approach; more often, it doesn’t.
What is one thing the industry currently overestimates?
How quickly AI will take over complex decision-making in regulated industries. The technology is indeed moving fast, but the rules, the liability frameworks, and the institutional trust needed to actually use it at that level are not. There is a significant gap between what AI can do in a lab and what you can responsibly deploy in a compliant, auditable environment. Most vendors selling AI into regulated markets have never had to operate inside one, and it shows.
And what is underestimated?
The compounding cost of technical debt accumulated during the current growth phase. To keep up with the fast pace of change, many players are cutting corners on documentation, testing, and architecture to capture market position. That debt is accumulating across the industry simultaneously. When the pressure comes — from regulators, from scale, from security incidents — a significant portion of what has been built will not hold up. The cleanup costs will be substantial, and the companies that built with discipline will have a durable advantage.
What does Maxcode’s slogan, ‘next level tech’, mean to you in practice?
Next level tech means we’re genuinely excited about what’s new and we move fast to adopt it — but we’re also ruthlessly critical about what actually works in production versus what just looks good in a pitch. The foundation still has to be there: correctness at the edges, maintainability, graceful degradation. Without that, adopting new things fast just means failing faster. But once that foundation holds, next level means constantly asking what changes the economics of delivery — what genuinely compresses the time between a business problem and a working solution. We’re not skeptics and we’re not hype-followers. We’re the team that tries things early, cuts what doesn’t deliver, and doubles down on what does.
Ultimately, clients need to trust that what you build actually works, and keeps working. How do you ensure that level of reliability?
A system has to have a clear setup before it can be maintained. That is not optional. Testing has to be real and enforced, not just a theoretical goal. We document how to handle failures before they happen, not after. And we only promise what the architecture can actually deliver. We treat reliability as something you engineer, not something you commit to in a pitch.
When a client chooses Maxcode, what can they confidently expect from you?
That we understand the regulated environment they operate in, not just the technical stack. That we’ll tell them when something is a bad idea, not just when it’s a hard one. And that the engineers working on their product are senior enough to make sound consequential decisions, not just execute tickets. A lot of companies sell capacity. We sell joint informed decisions.
