24 Hours to 9 - How AI is reshaping the Discovery Phase in banking software implementation
At ApPello, artificial intelligence is not only a product feature we demonstrate to our Partners, but it is a working discipline embedded across our delivery process. Let us share our practical experiences with AI, starting with the lessons learned during the discovery phase and how AI has helped us accelerate and improve this stage of the delivery process.
The problem with Discovery as it was
Discovery workshops are where implementation projects are won or lost. Yet for years, the process followed a familiar and limiting pattern. The Partner would present their concept live. The team would improvise questions, take notes under pressure, and produce meeting minutes days later from memory. High-level specifications depended on a single person's recollection. The Product Backlog carried all of that ambiguity forward into development. The consequences were predictable: topics required multiple workshop-rounds to close, edge cases surfaced late, and flawed assumptions reached the codebase before anyone had formally questioned them. This was not a failure of professionalism. It was a structural limitation of the process itself.
A New Flow: Four deliverables, one continuous thread
Working with an Asian Bank across 20 intensive workshops in a single month, our Business Analyst team redesigned the discovery process around four interconnected deliverables, with AI integrated at every stage to eliminate low-value work and create space for high-value judgment.
Preparation questions shifted from improvisation to structure. Question sets were generated in advance with the help of AI, organized by business rules, scope boundaries, edge cases, and integration dependencies, each enriched with suggested answer options so the client arrived ready to decide rather than to explain. Topics that previously required multiple sessions closed in one. Workshop time moved from orientation to decision-making. Also the language barrier, that had initially created friction, gradually receded.
Meeting minutes moved from reactive to proactive. Real-time AI transcript recording replaced note-taking under cognitive pressure, enabling same-day structured documentation: decisions made, open questions, action items with named owners, and timestamp references for every key moment. A single workshop on one functional topic produced seven documented decisions, eleven action items with owners, and more than forty timestamp references. A human note-taker in a multilingual session carries language processing as an additional burden. The AI handled it without quality loss.
High-Level Specifications became source-driven rather than memory-dependent. With preparation questions and minutes as structured inputs, the HLS gained consistent structure across projects, explicit in and out of scope, flagged open points with named owners, and modular approval packages that allowed the Partner to sign off section by section. Production time dropped with AI from approximately 8 hours to 3 to 6.
Also the Product Backlog benefited from every upstream improvement. Product Backlog items mapped directly to HLS modules. Acceptance criteria became the Definition of Done in sprint tickets. Open points appeared as explicit flagged risks rather than hidden assumptions. First-draft time fell from 5 hours to 2 to 4.
Time savings with AI
One important calibration note: AI tends to overestimate effort, and Business Analyst review against team velocity and existing implementation remains essential.
Where human judgment remains irreplaceable
Domain knowledge cannot be prompted. The understanding that a client's use of a specific term reflects a regulatory context, or that a workflow notification system has known reliability issues in their environment, lives in professional memory, not in any document. Client relationship judgment, stakeholder alignment on open points, Product Backlog calibration, and final quality review all remain human responsibilities. AI provides the scaffold. Experienced judgment determines whether it is credible and complete.
And there is a scenario worth considering: A Partner, having observed the quality of AI-assisted documentation, attempts to replicate the process independently. They feed their business requirements into an AI and ask it to validate the concept. The AI will agree with them. It can only see what the document says. A Business Analyst working outside the document sees what the document does not say: the assumption never questioned, the edge case considered too obvious to write down, the dependency that only becomes visible when you understand how the existing system actually behaves. That gap is precisely where implementation risk lives, and where an experienced, AI-equipped Business Analyst creates lasting value.
We believe in AI and we see the results. This project is one example. And there are more to come.
In the coming blogs, we will dive deeper into our experiences and best practices for using AI in detailed specification design, as well as the techniques and practical approaches we have developed for software development and testing.