Ehab Qadah leads the engineering team behind Lean Technologies’ credit scoring, fraud, and verification products; the team where a wrong or unauditable decision carries real regulatory weight.
He retired his team’s two-week Scrum sprints once AI coding tools turned them into a bottleneck, then poured the time he saved into the validation layer that proves every decision after the fact.
Fintech Recoded interviews demonstrate how experienced product and technology leaders make difficult decisions in an environment where resources are constantly constrained, market changes are sudden, and deadlines are non-negotiable.
How Lean Technologies keeps credit decisions auditable at AI speed
Ehab Qadah’s team at Lean Technologies ships the products behind some of the region’s largest buy now, pay later platforms, which make the credit and fraud decisions that carry real regulatory consequences.
When AI coding tools turned his old two-week sprint process into a bottleneck, he retired it, then moved his old sprint discipline into the one place it still mattered. The same discipline now proves every decision holds up.
What you'll learn
Why exactly Ehab Qadah killed the two-week Scrum sprint once AI coding tools turned it into a bottleneck
How Lean Technologies keeps credit and fraud decisions auditable while shipping in hours instead of days
Why one engineer can build a full feature end-to-end, but still requires the team assistance to validate the decisions and impact of the feature
About Ehab & Lean Technologies
Proving trust in customers without a credit file
Prem Markowski: You recently worked on a collaboration between Lean and Tamara that used open banking data for credit decisioning.
What was your role in it?
Tamara is one of the largest buy now, pay later companies in the MENA region.
Some of their otherwise creditworthy customers, gig workers, freelancers, people running a side business, don’t have a traditional salary or a credit bureau record to point to.
Obtaining more information about the customers allows the platform to make qualified decisions regarding them.
We worked with Tamara for close to a year to fold open banking data into their decision making, so they could read cash flow directly from a bank account instead of relying only on bureau records.
The collaboration became a public case study, with a 32 percent increase in overall credit approval rates and around 60 percent more approvals among customers who were previously invisible to a credit bureau.
I lead the engineering side of this at Lean, the Lean Lighthouse vertical, overseeing the squads that build the bank connection and consent flow, the income and insight signals, and the verification products underneath it.
You said you focus heavily on risk decisions, and your background traces back to an ML-focused Master’s at Bonn before you moved into engineering for regulated financial products.
How much of what you think about risk actually carried over from your education?
More than I expected, once I actually thought about it.
Machine learning research isn’t only about the algorithm, it’s a probabilistic mindset. A model is never fully right, and you learn to live with precision, recall, and error rates as normal parts of the work.
You design experiments around that uncertainty, testing across multiple models and datasets to prove a result holds up.
The regulated side of my job asks for the same kind of proof, just under a different name.
The discipline of evaluation in academic research becomes the discipline of auditability in professional life.
The sprint that couldn’t keep up with AI
You’ve talked publicly about how AI coding tools are making the traditional two-week Scrum sprint obsolete.
Was there a specific moment that convinced you the old model was holding your team back?
I was never a big fan of Scrum to begin with.
My long-standing complaint was watching teams treat the ceremonies, the estimation, the ticket breakdown, the push for 100 percent sprint completion, as more important than the reason the team existed in the first place, which is solving problems and creating business value.
AI coding tools gave that old complaint a new trigger.
We have a value at Lean called "Yallah": move fast, default to action, ship, observe, learn, and iterate. So last year, one of my squads ran an experiment, dropping the core Scrum ceremonies for a continuous flow with one hour of weekly planning, no pre-refinement meetings, and no more than a week of scope defined at a time.
Work that used to take days could now be generated by an AI agent in hours, so the two-week sprint stopped looking like structure and started looking like an artificial bottleneck.
That default-to-action mindset worked well enough that every squad adopted the same approach.
What was the first sign that the two-week sprint was actually costing you something?
Estimation was the first thing to break.
Story points and sprint velocity had always stood in as a proxy for team capacity, but that proxy stopped meaning anything once AI coding tools changed how fast a task could actually get done.
The old habit of breaking a big user story into many small tasks stopped making sense too.
An AI agent works better with one complete piece of context it can carry from design through implementation and testing, rather than a pile of small fragments.
Once both of those broke at the same time, it was clear the whole way we planned and split sprint work needed to change.
Once code itself stopped being the slow part, did it change how you thought about building quality into financial data systems?
Yes, to some extent, though I think everyone is still figuring out exactly where quality lives now.
Code got cheaper, but the validation layer around it did not get any smaller. If anything, it matters more.
For financial data products specifically, we now validate decisioning output the same way we validate the models and business rules behind it, checking that an income signal actually matches the real signal it claims to represent.
That’s pushed us to invest heavily in the layer after the code, unit and integration tests, end-to-end tests, and regression pipelines that run against real bank flows and data.
The one thing we haven’t managed to speed up at the same rate as writing code is that validation layer itself, so scaling our CI/CD pipelines and test coverage is where we’re investing next.
Two clocks for one delivery pipeline
What does your delivery process look like now, given you have to balance AI speed against high compliance and security requirements?
It’s still broadly the same software development cycle, but I think about it as two layers now.
The execution layer, requirement review, prioritization, building, and testing, is continuous and AI-assisted, and that layer has genuinely sped up.
The governance layer stayed exactly where it was, because we operate in a heavily regulated industry. Compliance and security review, architecture review, and the change-request process before any execution starts all still run the same way they did before.
Beyond compliance-specific checks, what other quality practices do you think generalize well to teams outside financial services?
Quality has to live in the whole pipeline, not just in a QA phase at the end.
One new mechanism we’ve added is a quality check on the plan itself, before any code gets written, essentially a technical design review of what you’re about to ask an AI agent to build.
The lines between roles are also blurring, frontend and backend, QA and backend, so quality ownership belongs to the whole squad end to end rather than a separate QA function.
From initial AI planning to code deployment, one team should own the entire process.
That's Lean’s 'Own the outcome' way in practice where ownership is measured in outcomes, not tickets closed. You don't drop the baton at the function boundary between backend and QA, and you don't disappear when your part is technically done.
Who owns a feature when one engineer builds it
On LinkedIn, you said that a single engineer can now own a product feature end to end, something that used to require a full cross-functional team.
Does that hold true in your world?
It’s genuinely true, with one caveat, that one engineer can now build a full-stack feature from start to finish without needing a dedicated cross-functional team around them.
The caveat is specific to our industry. Because we’re mandated to meet regulatory requirements and keep our financial products correct, an engineer building something like a credit decisioning feature still has to work with the wider team to verify that feature.
Execution can be individual, but the accountability for the decision stays a team effort.
Do you have a defined AI-driven delivery framework your team uses to ship at a predictable pace and quality?
Honestly, we don’t have a single defined framework yet.
We started by pushing every engineer to experiment freely, with different approaches, spec-driven work, chatting directly with an agent, and now increasingly building harnesses around these agents.
Engineers get autonomy to experiment, but they are accountable for outcomes. Poor results prompt a process review, not standardized mandates.
The tools themselves are moving too fast to lock a framework down. We went from AI inside an IDE, to Cursor, to now working with Claude, and each shift changes what a sensible framework would even look like.
What we do have is a shared way of using agents to deliver the maximum validated scope inside a time boundary, along with a loose mechanism for sharing knowledge and keeping some skills and architecture choices consistent across the codebase.
We’re building the framework as we go rather than starting from one.
What a fintech should protect before speeding up
What still has to move slowly on a team building KYC, AML, and fraud products?
Anything that changes a decision about an end user has to stay slow. That includes changing underlying risk signals or detection logic.
Those changes need policy review and compliance review, and they need to stay aligned with the regulatory framework we operate under for customer data and consent, including open banking and open finance rules.
You cannot change client-facing model behavior without running the full set of assessments and validation against it first.
It’s not about being slow for its own sake, it’s about not shipping a change to how a customer is treated without the checks that change actually deserves.
Given everything you’ve described, what’s the first thing another fintech CTO would need to rebuild to speed up delivery without losing quality?
Honestly, the first thing to drop is Scrum.
Good outcomes don’t come from repeating the same process out of habit rather than rethinking it for the era you’re actually in.
The second thing is to invest even more in the core software engineering practices you already have, specifically a genuinely solid quality and validation layer.
Once your team can ship changes fast, you cannot afford to find out something is broken after the fact.
Alongside that, build a culture where engineers are expected to experiment with these tools and develop their own AI-driven practices, the same way they built deep expertise writing code over the last twenty years, and share what they learn with each other rather than working it out alone.
At Lean, the principle is to raise the bar structurally first and then move fast, not the other way around.
Any resources you’d recommend to managers who want to go deeper on AI in engineering?
It’s a genuinely hard question, because the amount of people writing about this is overwhelming.
The one resource I keep coming back to is a newsletter called Token by Token, a weekly rundown of AI industry stories and approaches.
3 moves worth making
Move validation investment to match your new shipping speed
Ehab Qadah’s team didn’t slow down when AI coding tools sped up delivery, they redirected the saved time into testing.
Lean now runs regression pipelines against real bank flows and data, on top of standard unit, integration, and end-to-end tests.
If code gets cheaper and the test and review layer doesn’t grow with it, the payoff shows up later as a much harder problem to unwind.
Let one engineer build, but never let one engineer decide alone
Ehab’s team has accepted that a single engineer can now build a full-stack feature without a cross-functional team around them.
The accountability for a credit or fraud decision still sits with the wider team, not with whoever wrote the code.
Separating who builds a change from who is accountable for its effect on a real customer keeps individual speed from becoming individual risk.
Kill the ceremony that AI already made pointless
Ehab dropped Scrum’s two-week sprints and pre-refinement meetings once story points stopped tracking anything real.
His team replaced them with one hour of weekly planning and a week-long scope, reviewed and adjusted as the work reveals itself.
The goal isn’t speed for its own sake, it’s removing processes that no longer match how the work gets done.
Authors
Prem Markowski
Experienced IT Business Leader helping Saudi businesses grow through the right technology approach. Passionate about building win-win partnerships and driving growth with scalable software solutions and expert engineering teams. Golf enthusiast who likes the sport’s strategy and discipline - golden values both on the course and in business.