How to build a new revenue engine in 3 months
High-quality, reliable software delivery under immense time and regulatory pressure. A Central European bank had reorganised a thousand engineers for speed, stood up three digital labs, and still watched its unsecured loan slip seven months before the project was scrapped. We restarted it and launched country-wide in under four months.
The full narration, as text
Everything said over the deck, written out, with each page of the deck where it goes up in the talk. Read it instead of watching if that is faster for you — it is the same argument and it is all here.
Transcribed from the recording, in the speaker's own words. The cue above each part says what is on screen while it is spoken; click a slide to open the deck full-page and walk it with the arrow keys.
On camera
Who I am and what this talk is
Your organization resists digital transformation because no-one has shown the success it creates.
Good morning, day, afternoon or evening! I am Sandor Nagy, founder of AerelonTech consulting and principal architect. Today I am going to show you how a small product launch can succeed inside of a large organization and kindle the spark for transformation.
Page 1 · Situation
A bank that had already reorganised for speed
Once a large incumbent bank started a multi-year digital transformation, reorganizing one thousand plus staff in hopes of faster product delivery. Yet as time went by, the outcomes did not arrive into customers' hands as expected. The organization dragged.
You see, a digital product requires more than code to function, to deliver value and be paid for. Even if we talk only about a loan, a product that worked for hundred years without computers ever existing.
A loan needs enforceable contract, financial tracing, and countless other areas, just look at each line here that represents a function which an unsecured cash loan builds upon.
The strategy, on paper, was sound. When put into practice, the real bottlenecks showed up:
- seniors struggle to learn on tech challenges in a stable environment, they are simply not exposed to a wide range of experience,
- breaking down siloes always harder than it seems, people agree at first to take part then pull back when real trade-offs arrive,
- avoiding failure is natural, as we tend to think we are evaluated by each mistake, which stifles risk taking, leading to endless planning before action,
- and finally, the imagined and sold scope at a project start always bigger than it seems, and a soft lock-in done by manager promises can't be walked back.
Page 2 · Complication
When the pressure turns into "this isn't worth it"
Putting all these internal pressures onto multi-year long projects, combined with external competing pressures can lead to a destructive realization: we are wasting money on a transformation that doesn't worth it.
Even so, in the 21st century we would be bold to believe digital is not a necessity. Yet this exact thought process emerges from the pressure to bring revenue for stakeholders. A leader must balance all these forces, adapt throughout years of challenges, achieve a lot in the process that is hard to quantify.
But delays from expectations can sink all those efforts. This particular DX project faced its setback as such.
Page 3 · Question
Under four months, the worst failure mode, and a country-wide launch
From that setback, a stronger approach emerged and we were called in to deliver. And we did. In under 4 months, we built the application as expected, we even did the worst possible failure mode, and yet we rolled out a safe, reliable and secure product experience country-wide.
Page 4 · Four pillars
Why it worked, in four parts
But what enabled us to deliver while the previous team was disbanded?
I pieced it together months after the project ended by interviews, discussions, and from the documents I had access to and got to 4 key distinctions:
- Our team had multi-disciplinary members, a single member who could handle 3-4 distinct areas in one. The E-shaped team.
- We co-located every expert needed with the team. This can be done remotely, the key is that all team member's success is tied to the product launching, not to their previous day to day.
- Previous attempts and long preparation on multiple fronts actually set us up for success.
- And we were descoping. I called it "using a machete on the JIRA tickets".
On camera
Where genAI fits, and where it does not
In 2026, you would certainly ask, where is genAI in this picture? Would it have changed anything?
And my answer, after leading many projects with and without it, that it fundamentally did not change anything. Yes, it is useful at certain pattern matching heavy work, one single conversion of 2 days work would have been hours with it during this project. That is less than 0.2% of the project's total FTE bandwidth.
3 months × 4 weeks × 5 workdays × 8 hours = 480 hours
480 hours × 24 people = 11,520 workhours total
32 hours spent on a pattern matched problem → 8 hours with genAI rather
When you are creating something new, understanding doesn't come from an average-machine token karaoke. Decisions taken, not delegated to a black box by the thousands so your unique product can be built by the mean-regression of all text on the global internet.
There are components to the real world complexity that you can not put into equations and quantify. Those qualities are now being lost if you rely on genAI as a replacement to product engineers, to product design, to user experience, to experiments.
Back to my case study, let's break down each component that turned a multi-year struggle into a 3 month delivery sprint and a success story for 5+ years.
Page 4.1 · Product unit
I to T to E, and then a team
One of the major challenges to put together a team is that so much of an individual is not quantifiable, hence the team chemistry can't be predicted either. But a great model I learnt over the years is to look at people as complex individuals, understand their impact both in depth and width, and then to nurture them into a unit that can handle any challenges on their own.
Starting from the individual journey, most people leave university or their first jobs they become an expert in one thing. Frontend, backend, banking, product, etc. The I-shaped specialists.
Then as they work more within a team, have to pick up pieces from others, switch and change around to handle new challenges, they start to be able to deliver more complex solutions alone. May not be the best solutions outside their expertise, but workable ones. These were the full-stack engineers who handled a single feature through all layers of software. The T-shaped seniors.
Then as years go by, some move to other disciplines and deepened their expertise. Now they are able to shape outcomes to higher degree, who understands the intricacies of more disciplines, e.g. a solution architect who has built platforms, backends, frontends, databases under heavy load, caching, etc. Takes decade or decades but these are the E-shaped, multi-disciplinary experts.
Now a team can be put together from any combinations of the previous. And in a healthy one you will find all of those profiles. But the backbone for a fast delivery team comes from the E-shaped individuals due to a single trait: decisions are made inside their head doesn't need overhead in leadership.
Empowering a team like this eliminates a lot of bottlenecks. Form them for strategic projects on a tight deadline. Disperse the E-shaped so they can uplift, coach and train others to become such power.
Page 4.2 · Co-location
Co-location is an incentives question
Rather consequently, the expertise built up over decades of work, solving different challenges in those experts are a sought after help in every organization. Without a strict policy how to protect their focus, they will be pulled to many direction at once.
What happens when you are trying to run into many different directions in a rapid succession? Run up, down, now back up, left, then right? You won't be as fast as if you would running just forward with no directional change.
Co-locating a team for me is not just putting them into a single room. That can help in circumstances, especially during forming phase, early. But really it means that the team members success is tied to the team's success.
It is an incentives question. If an expert is evaluated on how many different requests they fulfilled, their focus will be always divided. If they are evaluated on their impact to a handful of strategic projects, they move mountains with no effort.
Page 4.3 · Strategy
The years before the three months
As nice it would sound that we delivered in 3 months from scratch, and how many companies and organizations tout a story like that, it is always certainly false.
At least a disservice to those who prepared the project, the effort that went into setting it up for success. Just as a Hollywood movie production doesn't start at filming the scenes, a digital product production doesn't start at the first line of code.
It starts years before any of that. Just as for a movie, or for any project, I would propose there are three bands that requires years of build up.
- Proving that the project can be done is the research, outside foundational science, the end goal can be broken down into parts and each part proven with engineering experience if it is doable.
- Proving that it worth to do is the business case, the belief that the return on the investment worth the costs poured into it at least on a napkin math. And drafting alternatives when certain assumptions fail during the project is just as important. Even market conditions can take years to form.
- And finally, proving that we are the ones who can do it, which builds on the individuals and the team's experience leading up to the opportunity. Including smaller prototype runs before committing the full investment.
Page 4.4 · Descoping
A machete on the JIRA tickets
And finally, none of the above worth anything if the scope just grows. Even if you fix the scope by project start, it will grow during it nevertheless. But why? If no-one allowed to put in new ideas, how the scope can grow?
It will grow because our understanding of the problem at hand naturally grows as we work on it. This is why a digital project is a research and development project, not a manufacturing type work. Less predictable, there is no way to confine it, like 10 kilograms of scope is done under 1 month.
Estimations were taken with assumptions that don't hold anymore. Or they were just wrong due to different understanding of what the outcome looks like.
The key is to let the team decide on what to cut during their project. The previous steps actually set it up so they can do it with confidence: E-shaped expertise, all relevant experts co-located and alternatives were planned in advance.
In our case, a hidden 3 months project was lurking in one of the tickets among 150 other tickets. By leadership support, we throw it out and replaced with a 1 week integration. The product worked and shipped, one step of the 17 pages was a decade older user experience.
Turned out, the users didn't mind it at all and the drop-off was minimal. 3 months of delay on top of a 3 months project was averted. However the team's fears weren't resolved yet.
Page 5 · Trade-offs
One wrong loan, and what it actually cost
The fear of the team stemmed from perception: no loan can be sold to an ineligible person. But mistakes happen, especially when the risk calculation requires half a thousand properties to be calculated perfectly. A controlled launch with a friends and family structure, meaning we sign testing contract with the recipient beforehand surfaced the mistake, the loan was sold to an ineligible person and reverted with shared agreement as the testing covered it.
Maybe this was the best learning opportunity for our client: risks can never be fully eliminated, but showing the loan's cost was in the hundreds of euros range, only one engineering day costs more. This finally put their fears into perspective and enabled the team to launch regularly with confidence.
With the most important confidence: even if the worst mistake is made, we have ways to revert, handle, fix, or understand the cost we had to take compared to endless efforts of excluding all possible mistakes.
On camera
Closing
To bring it all back together: your team's individual capabilities, their collaboration strength and proximity, your preparation in pre-production and ability to descope waste on the go ultimately determines the outcome.
Fix any problems arising from these areas, chasing the next trend or tooling salesmen promises to bring you the silver bullet won't move the needle.
Deliver a truly revenue making digital product in a short timeframe, months, and grow your organization from there.
If you want to see what holds you specifically back on your digital maturity, use our published framework here, or reach out to me for an introduction. With my Central European talent network, I am looking forward to work with you on any digital product challenges you may face!
Take care, and have a great day or night there!
Our engagement model is these same four pillars turned into a way of working — how an engagement actually runs, phase by phase, with its own narration as text.
The same four pillars are what an engagement with us is built out of. Discovery is a few calls and a few days, and you leave with your top risks and gaps on one slide whether or not we go further.
Book a discovery call