What goes on behind the scenes: software, data and artificial intelligence within a digital product

A simple function within an app may depend on dozens of invisible components. The software receives an action and executes logic; the data reveals what is happening and what happened previously; and, when the problem requires predicting, classifying, recommending or generating a response, an artificial intelligence model may come into play. Understanding a digital product requires distinguishing between these layers and, above all, understanding how they depend on one another.

Freeze the screen before you touch anything

Imagine you open a transport app on your phone and, without asking for anything else, a single information card appears:

Your journey will take approximately 38 minutes. There is an incident on your usual route. We suggest you set off now via a faster alternative route.

The message seems straightforward. It takes up three lines and can be read in four seconds. However, behind this apparent simplicity lies an immediate technical question: how many decisions can be contained within a fifteen-word sentence?

For that card to appear on a smartphone screen, the system has had to break reality down into several independent variables.

When the screen displays ‘your journey’, it requires prior context: it knows who is requesting the information, from which geographical coordinates they are doing so, and what their likely destination is. When it states ‘38 minutes’, it is not reading a fixed sign on a wall; it is calculating or estimating a duration subject to changing variables. When it warns ‘there is an incident’, it relies on external information captured moments ago by sensors, local authority alerts or third-party reports.

The reference to the ‘usual route’ reveals memory: the system recalls previous journeys and recognises a recurring pattern of behaviour. The phrase ‘we suggest’ implies a process of selecting from several possible routes, evaluated according to optimisation criteria. And the word ‘now’ introduces the most stringent variable in digital engineering: real time.

If we view the screen as a vertical cross-section rather than a flat surface, what is visible is merely the topmost layer. Beneath that layer lie the product experience, the software execution, the data repositories and data flows, potential statistical models, and a silent array of security and monitoring protocols. The screen displays the result; the system is everything that had to happen for that result to appear.

Software makes it possible for something to happen when you click

It is common to hear that software ‘is the application’s code’. But in the practical context of a real technological product, software is the engine that ensures things happen in a deterministic and consistent manner every time you interact with it.

When you tap the screen or open the mobility app, the software is responsible for receiving the request, checking that the technical parameters are valid, consulting the necessary services, applying predefined business rules, handling any errors, and returning a structured response that your phone can display.

In educational terms, we usually divide this world into two broad areas: the front-end, which encompasses the interface you interact with directly (the buttons, the map rendering, the transitions and the forms), and the backend, comprising the servers, databases and internal logic that processes requests out of your sight. It is worth noting that this separation is a didactic simplification; modern software architectures distribute responsibilities across microservices, distributed functions and intermediate layers that constantly collaborate.

Within this collaboration, application programming interfaces (APIs) act as the communication protocol between independent components. The app installed on your phone does not store the world map or the status of your city’s traffic lights in its internal memory. That would be impractical. What the software does is communicate via an API with a remote service: it sends a structured query containing your location and receives, in milliseconds, the data it needs to display.

Programming the ‘happy path’ is only part of the job

In software engineering, there is a revealing concept: the ‘happy path’. It is the idyllic scenario in which the user presses a button, the internet connection is perfect, the servers respond instantly and the requested information arrives without a single error.

Anyone can design basic logic for the ‘happy path’. The real challenge in software development lies in everything else. What should the app display if the weather service takes five seconds to respond? What happens if the mobile signal drops just as the route is confirmed? How does the system prevent a duplicate request from charging twice for a ticket?

Professional software devotes a large part of its architecture to handling exceptions:timeouts, staggered retry policies,fallback mechanisms that display cached data when the network goes down, and audit logs that allow a technical fault to be reconstructed. Programming for the best-case scenario is only part of the job. A real product also has to know what to do when something is missing, delayed or fails.

Data describes what the system can know

If software represents the pipes, engines and switches, data represents the state of the world. An application cannot make any decisions about something that has not previously been recorded, measured or transmitted in the form of data.

In the mobility card we are analysing, profoundly different types of data coexist:

• The current state: instantaneous data such as the latitude and longitude coordinates transmitted by the device’s GPS, the exact time, road conditions and the availability of vehicles in the area.
• Historical data: consolidated records of thousands of previous journeys made at the same time in previous weeks, average stop times and aggregated urban mobility patterns.
• Context: external variables that alter reality, such as an unexpected downpour, a football match blocking a main avenue, or a public holiday on the official calendar.
• The result: what the user ultimately decides. Whether they accept the proposed alternative, whether they reject it, how long it actually takes them to complete the journey, and whether at any point they alter their route whilst en route.

The recording of these events highlights a fundamental technical reality: having a lot of data does not equate to having useful data. If a traffic sensor sends duplicate readings, if street names are incorrectly coded, or if the mobile app loses half the coordinates due to a telemetry fault, the system will attempt to operate blindly.

This is where data quality comes into play – a technical discipline that describes the extent to which the available information is sufficiently accurate, complete, consistent, up-to-date and suitable for its intended use. Without data quality standards, any subsequent calculations lack an operational basis.

Accurate data can still be useless

There is a common pitfall when thinking about information: assuming that true data is always valuable. This is not the case. Data also becomes outdated.

Imagine you have an impeccable historical record of journey times in a city centre over the last ten years. The data was collected with pinpoint accuracy, is free from errors and has been stored meticulously. However, three months ago, the city council converted a major thoroughfare into a pedestrian zone, changed the direction of traffic on four adjacent streets and introduced new bus routes.

That ten-year history remains technically ‘correct’ with regard to the past, but its ability to represent the present or predict the future has plummeted. Technological systems operate in dynamic environments; when infrastructure, regulations or human habits change, old data ceases to describe reality. Understanding the life cycle of data means accepting that information is not a static monument, but a flow that becomes outdated over time.

AI comes into play when the answer isn’t written in advance

Up to this point, a well-programmed system with robust software and up-to-date data can achieve extraordinary things. That is why it is vital to dispel a common misconception: not all automated or sophisticated behaviour requires artificial intelligence.

If the business rule states: ‘If the user enters an incorrect password five times in a row, block access for fifteen minutes’, there is no need for machine learning. It is a deterministic rule written into the software. If A occurs, B is executed. The response is entirely predicted in advance by the engineering team.

Artificial intelligence comes into play in a digital product precisely when the response cannot be codified as a fixed rule.

This happens when the problem requires estimating an uncertain variable, classifying a complex pattern, ranking millions of items according to their subjective relevance, recognising anomalies invisible to the naked eye, or generating an appropriate response to an unforeseen context. Traditional software applies instructions; machine learning models infer probabilities and predictions from mathematical relationships discovered in the data.

In our mobility example, a strict rule can calculate the Euclidean distance between two points. But accurately estimating how many minutes it will take a vehicle to travel a specific stretch on a Friday afternoon in light drizzle requires learning from thousands of journeys observed under similar conditions. The system does not follow a rigid script; it calculates a probabilistic prediction.

This same distinction can be seen in other digital environments:

• E-commerce: a basic rule hides out-of-stock products; a recommendation model predicts which items are most likely to interest a user based on their browsing history.
• Fraud detection: a rule blocks payments that exceed a card’s configured limit; a model analyses dozens of subtle signals in milliseconds to score the probability that a specific transaction is fraudulent.
• Streaming platforms: a rule filters content by country or language; a machine learning system classifies and reorders the catalogue, adapting to the user’s changing tastes.

Mature architectures combine both approaches. Digital products do not replace rules with models; they establish a balance where rules set the unbreakable limits and models resolve uncertainty.

Not all sophisticated behaviour requires artificial intelligence

Treating artificial intelligence as a mandatory solution for any technical challenge is a design flaw. As set out in Google’s methodological guidelines in its engineering principles (Rules of Machine Learning), if a simple heuristic or traditional software logic solves the problem effectively enough, you should not implement a machine learning model, especially if you do not yet have reliable and stable data.

Training and maintaining a model introduces considerable technical debt: it requires training pipelines, specialised servers for inference, continuous monitoring and retraining mechanisms. Adding AI does not automatically turn a feature into a better product; it adds a new capability and also new dependencies that must be maintained. Technological sophistication lies in choosing the minimum tool required to solve a problem robustly.

The model may be brilliant, yet the product may still fail

One of the biggest culture shocks for those new to technology comes when they realise that a model with a theoretical accuracy of 98 per cent in an experimental environment can ruin a product’s user experience once it goes into production.

In a laboratory or an analytics repository, the model is evaluated in isolation against a static dataset. But in the real world, the model is just one small cog in a vast machine. As various technical architecture studies on machine learning systems in production have shown, the model code itself accounts for only a tiny fraction of the technical effort.

Real-time data ingestion systems, schema validators,model serving services, load balancers, firewalls and telemetry consoles must all be built around the model.

Imagine that the data science team develops a cutting-edge algorithm for our mobility app. The model calculates journey times with astonishing accuracy. However, when deployed on the live infrastructure:

• The mathematical inference takes four seconds to complete per journey, causing the app to freeze on opening.
• The service cannot cope with the concurrent volume of requests during peak hours and starts returning 504 errors (gateway timeout).
• Live traffic data arrives with a slight format mismatch that the model cannot interpret, returning null values.
• The user interface displays the prediction with a false sense of certainty (‘exactly 38 minutes’), causing immediate frustration for the traveller if the actual journey takes two minutes longer.

The result is clear: the product fails even if the model works.

In production, latency is an inseparable part of quality. A technically outstanding calculation that arrives too late is useless. Designing a digital product involves balancing technicaltrade-offs between algorithmic accuracy, the computational cost of servers, response time and fault tolerance.

When the screen displays an error, the cause may lie far beyond the screen

When a digital product produces an absurd result, the average user’s natural reaction is usually to blame the interface (‘the app isn’t working’) or to attribute the nonsense to supposed algorithmic clumsiness (‘the AI has gone mad’). Anyone who understands the inner workings of a system knows that the visible symptom rarely points directly to the culprit.

Let’s return to our transport example with a specific fault: the screen suddenly indicates that your usual 35-minute journey will take 67 minutes today, even though the road ahead of you is clear.

Where does the error lie?

• It could be a data quality issue: a local traffic sensor has become stuck, looping a reading from a traffic jam that occurred three days ago.
• It could be a software and integration fault: the service that converts geographical coordinates from an external provider has interpreted the speed as miles per hour rather than kilometres per hour due to an undocumented change in its API.
• It could be a business-rule failure: a developer set up a deterministic restriction that adds 30 minutes to any route passing near a minor roadworks site, without checking the actual flow of traffic.
• Or it could, in fact, be a fault in the predictive model: the algorithm confuses the impact of a sporting event scheduled for midnight with the current traffic situation in the middle of the afternoon.

The same diagnostic principle applies to an e-commerce or streaming platform when it recommends completely irrelevant content. The cause may be a poorly optimised model, but it is equally likely to stem from a temporary loss of the user’s session, a corrupted browsing history, or a business rule that forces certain sponsored products to appear above the user’s actual preferences.

Not every fault that appears in a ‘smart’ function is an AI fault. Learning to diagnose digital systems requires tracing the technical dependency chain layer by layer before assuming where the logic broke down.

Models also change as the world changes

Traditional software has one reassuring characteristic: if you do not modify the code of a deterministic function or its infrastructure dependencies, that function will continue to run exactly the same way today, tomorrow and in six months’ time.

Data-driven models do not enjoy that peace of mind. A model can keep its code intact, run on the same servers without any software errors, and yet become progressively useless as the weeks go by. This phenomenon is technically known as model drift or data drift.

The reason is not that the algorithm mechanically deteriorates. It is the outside world that changes.

If a model was trained to predict travel demand based on fares, the weather and working hours in 2024, its predictive ability will deteriorate if remote working becomes widespread in 2026, if free travel passes are introduced, or if fuel prices change drastically. The model continues to calculate correlations that were once true, but the actual data entering the system today belongs to a different statistical distribution.

For this reason, putting a model into production is not the ultimate goal of a project, but rather the start of its operational phase. Engineering teams must set up continuous monitoring dashboards to oversee not only the server’s technical performance (such as memory or CPU usage), but also the statistical distribution of the input data and the stability of the predictions. In a data-driven system, maintaining the product also means checking whether the real world still resembles the one described by the data on which it was built.

When a product uses AI, what needs protecting also changes

As a digital product incorporates more dynamic data and inference capabilities, the attack surface that needs to be protected undergoes a radical transformation.

Traditional cybersecurity has revolved around three fundamental pillars: confidentiality, integrity and availability. In a conventional application, this translates into protecting databases against unauthorised access, encrypting communications using secure protocols and shielding servers against denial-of-service attacks.

These principles remain intact, but the introduction of predictive models and large volumes of telemetry raises more complex security and resilience dilemmas, as outlined in the risk management framework of the NIST (National Institute of Standards and Technology):

• Privacy and governance: for the mobility app to suggest setting off for work at 08:15, the system must record and store extremely intimate location patterns. Who within the organisation has access to these identifiers? How long are they retained? Are they anonymised before being reused for internal analytics?
• Data manipulation and integrity: if a network of malicious users simulates dozens of slow journeys by sending false data from tampered phones, can they artificially alter traffic estimates and clear a road for their own benefit?
• Non-deterministic behaviour: in systems incorporating generative models or advanced inference, what safeguards prevent a response from hallucinating dangerous instructions or breaching other users’ privacy?
• Graceful degradation: if the system’s intelligent component suffers a security incident or stops responding, is the digital product capable of continuing to operate using basic software rules, or does the user experience collapse entirely?

The fact that a model gets things right most of the time does not in itself determine whether the product is secure, explainable or appropriate for its context of use. Security, privacy and technical oversight are not cosmetic layers added at the end of development; they are design requirements that shape the software architecture from the very first line of code.

Before asking which AI to use, we must decide which problem is worth solving

There is a recurring technological temptation: to become fascinated by a novel tool and then go looking for problems to apply it to. In the ecosystem of digital organisations, this bias translates into meetings where the opening question is: ‘How can we fit AI onto this screen?’.

Robust digital products take the opposite approach. They begin by identifying, with surgical precision, the user’s need or the organisation’s bottleneck, and then seek out the minimal and most sustainable combination of technologies to resolve it.

That is why product metrics must be defined well before choosing the algorithms. Improving an abstract technical metric in the model (such as reducing the mean squared error in a prediction by a few tenths) in no way guarantees that the product will improve. The real business and design question is a different one:

• Does the user reach their destination with less stress and fewer delays?
• Are cart abandonment rates reduced?
• Do we detect fraudulent transactions without unfairly blocking legitimate customers?
• Does the time the user saves on the task justify the cost of the infrastructure we have deployed?

Turning these questions into a real product requires leadership and management that goes far beyond simply drawing timelines on a whiteboard. A digital product requires coordinating people who speak very different languages: data science specialists working with probability distributions, software engineers prioritising the stability and performance of APIs, analysts ensuring data governance, user experience designers and cybersecurity managers.

Technology project management consists precisely of striking that balance: aligning scopes, cross-dependencies, operational costs, technical risks and delivery deadlines so that the collective effort translates into a workable solution.

However sophisticated the technical system may be on the server, it ultimately manifests itself through a human experience. A machine can process a risk event and return a cold, hard figure such as:

risk_score = 0.8734

That isolated number is not a product. The product exists when the team decides what that figure technically means: at what threshold two-step verification is triggered, how the alert is worded so as not to alarm the person unnecessarily, and what manual alternative is enabled if the user cannot verify their identity at that moment.

The software executes. The data describes. The model infers. The interface communicates. Security sets the boundaries and protects the integrity of the entire ecosystem. And the product vision decides which outcome matters. The true value of technology does not lie in any one of these components in isolation, but in the precise moment when they all cease to contradict one another.

What does studying technology mean when you start looking at an app in this way?

When you develop this X-ray-like view of a screen, your relationship with technological learning changes fundamentally. You begin to understand that training in technology is not simply about ‘learning to code’ or memorising commands for a trendy tool, but about mastering the principles that enable you to design, orchestrate and protect complex systems.

The very same digital product you use every day to get around your city, listen to music or manage your savings requires different levels of technical depth and various specialisations to come to life:

• Understanding the entire information cycle, from rigorous data capture to the design and training of advanced algorithms capable of learning patterns and producing predictions, forms the core of UDIT’s Official Degree in Data Science and Artificial Intelligence. Modern education requires training in mathematics, applied statistics, databases and deep learning architectures tailored to the realities of the sector – a key perspective on how data analysis and artificial intelligence are intertwined
• For those who already have a quantitative or technical background and wish to lead the design of advanced intelligent systems, the Official Master’s Degree in Artificial Intelligence delves into the rigorous development of predictive models, computer vision, natural language processing and their practical integration into production environments.
• Not all problems require the construction of generative models; transforming large volumes of unstructured information into accurate diagnoses, strategic metrics and critical support for business decision-making is a discipline in its own right. Understanding Official Master’s in Data Analysis helps explain why the Official Master’s in Data Analysis approaches modelling from a perspective focused on business intelligence and advanced analytics.
• As organisations rely on continuous data flows and automated inferences, securing digital environments becomes a matter of survival. The Official Online Master’s in Cybersecurity and Ethical Hacking prepares professionals responsible for auditing vulnerabilities, protecting infrastructure and ensuring that systems can withstand threats in an increasingly connected environment.
• And since none of these technical skills will have any impact unless they are channelled into viable, sustainable and coordinated projects, the Official Master’s in Project Management provides the methodologies, risk management and leadership required to transform technological capabilities into operational realities.

Learning about technology changes when an application no longer seems like a black box to you. You begin to distinguish which part executes a rule, what information underpins a response, when it is necessary to infer something using a model, and what conditions allow everything to continue functioning once the product leaves the laboratory. Explore UDIT’s Technology department and discover the different ways to delve deeper into that system.

Next time an application seems ‘smart’, take a closer look

Take another quick look at the card we started this journey with:

Your journey will take approximately 38 minutes. There’s a disruption on the usual route. We suggest you take a quicker alternative route now.

If you’ve made it this far, it’s very likely you can no longer read that sentence in the same way.

You no longer see a simple ‘magic’ answer produced by ‘an AI’. You see the invisible thread of a software connection validating parameters via an API; you see telemetry sensors recording the state of the world in real time; you see databases cross-referencing your location with records that must remain up to date; you see business rules safeguarding the boundaries of logic; you see, perhaps, a predictive model calculating probabilities under strict latency constraints; and you see layers of cybersecurity ensuring that no one intercepts your position along the way.

The true advancement of modern technological engineering does not lie in hiding complexity behind a buzzword, but in being able to bring together very diverse disciplines to solve a real-world problem in a way that goes unnoticed. The next time you tap a screen and an app provides you with a useful response in a fraction of a second, don’t just scratch the surface: look beneath it.