Fast-Track Discovery: How Lumitech Validated an AI Investment Platform in Two Weeks
Complex fintech systems require clear architecture, secure data flows, and validated assumptions. We understand that the biggest risks appear long before development begins. This is why we focus extra attention on the Discovery phase.
- Discovery
- For new clients
Denis Salatin
January 15, 2026

Skipping the Discovery phase is like building a house without blueprints, hoping that the walls will somehow come together in the corners. Spoiler: they won’t, and it will cost three times as much to redo.
That’s why we at Lumitech pay special attention to the Discovery phase, immersing into the processes, business needs, and clients’ expectations. In this article, we will explain how a few days of intensive collaboration with the client in Dubai helped us create a clear plan, and why live contact between developers and the business is the best investment in the product's success.
How It All Started
In mid-December, a client approached Lumitech with an unusual request. Instead of a standard budget estimate or the preparation of a commercial proposal, it was necessary to assess the feasibility of a complex AI platform for investment management. And it had to be done quickly. There were fewer than two weeks left until the end of the year.
The product concept included an investment cockpit, dealing-room logic, a portfolio engine, a simulation module, an AI model for decision-making, and risk management and compliance blocks. The client needed to understand whether such a system could work in a real environment, taking into account the architecture, data, regulatory requirements, and operational processes.
Building a Focused Discovery Team
Due to the limited time, the Lumitech team quickly formed a core team for the Discovery phase. It included a Lead Business Analyst, Lead Designer, and System Analyst. This composition enabled simultaneous work on product logic, user experience, and system architecture.
Some of the meetings were held at Lumitech’s office in Dubai Silicon Oasis, but most sessions were held directly at the client’s office in the Trade Center. This format greatly simplified communication: issues were discussed quickly, and ideas were tested immediately during work.

On the client’s side, engineers, investors, and representatives of the financial unit participated in the process, so each solution was considered from several perspectives: technical, business, and operational.
To work as efficiently as possible, each Discovery team member had a clear area of responsibility.

This structure enabled parallel movement across three key areas: product logic, user experience, and system architecture, significantly accelerating discovery in a highly complex project.
Why This Team Setup Works for Fast Discovery
Fast discovery requires the right organization of work. In this project, a compact team and joint work with the client’s stakeholders in one space played a key role.
The on-site format allowed for short work sessions during the day, quickly testing ideas and immediately clarifying issues that could otherwise drag on for several days of correspondence or online meetings. When engineers, investors, and the product team participate in the same discussions, decisions are formed much faster.
“This approach also helps to avoid the typical gap between concept and practice. Ideas are immediately tested from the perspectives of business, technical implementation, and real-world processes,” adds Denis Salatin, Founder and CEO of Lumitech.
This dynamic joint work made it possible to cover the path in two weeks, whereas in the standard discovery format, it often takes several months.
A Typical Day Inside the Discovery Room
In short, every day started with coffee and the question: “Okay, but how will this work in real life?”
We gathered in the client’s office: engineers, investors, the finance team, and us. Talking straight to the point. Someone draws the system blocks on a whiteboard, someone opens a laptop and starts sketching the architecture, while the designer simultaneously turns ideas into wireframes.
Sometimes the discussion could start with a very simple scenario: “What happens when the system suggests changing the portfolio?”
And within half an hour, we are already talking about data sources, signal algorithms, risk limits, and who ultimately presses the button in the dealing room.
There was also a typical Dubai moment: the discussion could start as a technical conversation about the AI pipeline, and ten minutes later, someone would say, “What will the regulator say if this model is wrong?”
And the whole architecture suddenly gains a new level of complexity.
Often, ideas that emerged during the morning conversation were transformed into wireframes or architectural diagrams by the afternoon. This allowed us to understand, literally, the same day, whether the concept worked.
The rhythm was very simple:
idea → discussion → visualization → reality check
Sometimes this meant that a good idea did not survive the reality check. But that is how discovery works.
The Moment the System Got Real
At one point during the discussions, someone asked a seemingly simple question: “What exactly happens when the AI suggests changing the portfolio?”
That question opened a chain of architectural decisions.
Where does the signal come from?
How do we validate it?
Who approves the trade?
What happens if the model is wrong?
Within minutes, the conversation moved from product ideas to risk controls, compliance requirements, and execution logic. It was one of those moments when the concept of the system suddenly becomes very real.
And it became clear: to move forward, we needed to turn the concept into a structure – to decompose the system into modules and determine how they interact with each other.
Structuring the System: Breaking Complexity into Modules
Following the initial talks, the team began defining the system’s functional modules and user roles. This allowed us to transition from high-level concepts to a tangible operational model.
The system architecture is based on a knowledge base processing engine – a central module that aggregates data, processes information signals, and generates analytical conclusions for other platform components.
Several functional layers are formed around this core.
Investment Decision Layer
This layer supports investment decision-making and is used by capital allocation specialists. Key features include:
Investment dashboard: overview of the current portfolio status
Risk threshold charts: visualization of acceptable risk levels
Asset class allocation: portfolio structure by asset class
Top performers/outsiders: identification of assets that demonstrate the best or worst dynamics
Investment policy configuration: setting investment policy and restrictions
These modules allow you to assess the portfolio’s status and make strategic decisions about capital allocation.

Dealing and Execution Layer
The next level of the system concerns the operational part of the investment process. At the center of this layer is the dealing room, where asset transactions are conducted. The functionality includes:
Formation of trading actions;
Checking risk limits;
Generation of compliance and regulatory reports;
Application of investment inclusion/exclusion rules.
This level ensures the controlled execution of investment decisions in accordance with internal policies and regulatory requirements.
Have a complex product idea that needs structure? Our team helps turn ambitious concepts into clear system architectures and product roadmaps.
Market Intelligence Layer
A separate block of the system is responsible for analytical and informational insights. Its functionality includes:
Markets & AI industry insights;
Top AI insights;
Market news aggregation;
Search for specific assets and instruments.
This layer helps analysts quickly obtain the contextual information needed to make investment decisions.
Data and Integrations Layer
Access to external data sources is critical for the system to work. The platform provides integrations with:
Client's LOB systems
External information sources
Public newsletters and analytical services
These integrations ensure a steady flow of market data, news, and analytics, which the AI model and other system components use.
System Сore: Knowledge Base Processing Engine
The central element of the architecture is the knowledge base processing engine. It is this component that integrates all data flows, processes information, and generates signals for the system’s other modules. Its functions include:
Aggregation of data from various sources;
Processing of analytical information;
Generating recommendations for investment decisions;
Supporting AI models.
Such a modular structure allows the system to remain scalable and flexible, and also clearly separates the levels of decision-making, operations execution, and analytics.

Using Wireframes to Test Product Logic
In parallel, the team began visualizing the product through low-fidelity wireframes. They covered key parts of the platform: the cockpit, the dealing room, the risk dashboard, and the portfolio overview.
In this project, wireframes served as a working tool for testing ideas. When abstract concepts were transformed into concrete screens, it quickly became clear where logical gaps appeared, where scenarios were too complex, and where the interface could overload the user.
“For complex investment systems, it is important that the product remains manageable in daily operation. Visualization helped to test this very aspect of the system,” explains Yevhen Synii, Lead Business Analyst at Lumitech
Developing the Architectural Perspective
In parallel with the product discussions, the team worked on forming a preliminary architectural vision of the platform. The task of this stage was to translate the concept of an investment AI system into a clear technical model with clear data flows, integrations, and dependencies.
The architecture is based on the knowledge base processing engine, a central component that aggregates market data, analytical information, and signals from the AI model. It is this module that is responsible for data processing, generating investment insights, and transferring results to various functional parts of the platform.
From an architectural standpoint, the team worked on several key aspects.
Data Ingestion and Processing
The first step was to determine the data sources and the method of processing them. The system includes integration with several types of information flows:
The client’s internal LOB systems;
External market data providers;
News and analytical sources;
Public information channels and research materials.
For each data type, the update frequency, information volume, and normalization requirements were assessed before the data type was used in the system.
AI Signal Generation
The next important component is the AI module for generating investment signals. At this stage, the team and the client discussed:
The types of signals that the model should generate;
Methods for aggregating information from different sources;
Possible approaches to training the model;
Mechanisms for checking and validating the results.
Special attention was paid to the issue of interpreting AI results. For investment systems, it is critically important to understand on what basis a recommendation is formed, especially when it comes to large amounts of capital.
Before building complex systems, it’s critical to understand how they will actually work. Our discovery process helps define architecture, AI pipelines, and integration strategy.

Decision and Execution Boundaries
Another key issue was defining the boundary between the system’s recommendations and actual investment actions.
The architecture assumes that AI generates analytical signals and recommendations for portfolio changes. The final decision on the execution of operations is made by a person through the dealing room interface. This approach allows users to:
maintain control over investment decisions;
meet regulatory requirements;
reduce the risks associated with automated operations.
Integration and Scalability Considerations
At the architectural level, the team also evaluated integrations and potential scalability limitations. Key factors included:
Dependence on external data providers.
System performance requirements as data volumes grow.
Architectural approaches to scaling AI components.
Stability of the simulation engine.
A separate block discussed the possibility of building your own simulation model, which would allow testing investment scenarios and verifying hypotheses regarding portfolio strategies.
As a result of this work, the product concept was transformed into an architectural model of the system with a clear understanding of data flows, component roles, and potential technical limitations.

Two Weeks of Discovery – And a Clear Direction
In two weeks of intensive work, the Lumitech team, together with the client, was able to go through a path that usually takes much longer in a standard discovery format. Thanks to daily work sessions, on-site collaboration, and a clearly structured process, it was possible to quickly move from an abstract idea to a clear system model.
As a result of the Discovery phase, the team:
structured the platform concept and decomposed it into functional modules;
formed a preliminary system architecture, including data flows and integrations;
identified the role of AI in making investment decisions and the limits of automation;
assessed the technical feasibility of key components, including the simulation engine;
identified critical technical and operational risks;
proposed a phased implementation model that reduces uncertainty at each stage of product development.
The most important result was clarity about the system’s realism. The client received a reasoned assessment of the concept, an understanding of architectural constraints, and a clear vision of how such a product could be implemented in stages.

FinTech Expertise Behind the Process
Such discovery processes require a deep understanding of financial systems, investment logic, and the regulatory environment. At Lumitech, we provide proven fintech development services; the team regularly works with products in the fintech, capital markets, and data-driven financial platforms. This includes:
investment and trading platforms;
portfolio management systems;
fintech analytics and data platforms;
AI tools for financial analysis;
systems operating in a regulated environment.
Such experience allows us to quickly move from a business idea to a system product model, accounting for both technological and operational aspects. Check more of our projects in the fintech industry here.
