Understanding the business context is essential to finding the right solution.
Computer vision is a highly explored and developed field in AI today. Images and videos are a rich source of information that enable a wide range of inferences and real-world applications.
Many companies are working with computer vision, but the real question is: does this type of solution always need to be real-time (streaming), or are there viable alternatives for working with image or video data?
Recently, I faced the challenge of joining a team that was developing computer vision models for the first time in the company’s history. This team was already working on a project where the business had been promised a real-time inference solution to detect unsafe behaviors within their operations. My main role was to engage with the business and understand their real pain points in order to find the best possible solution.
What did I encounter during my first week? A frustrated business team expecting concrete results from what had been promised. What was happening? How did it get to that point? This was a fast-paced technological environment, with daily changes in focus and shifting objectives, both from the business and the technical team, who were developing multiple types of detections simultaneously without proper prioritization.
Initially, I focused on gathering information about what had been developed and how the team was working. I met with each member of the team involved in the technical solution to better understand both the workflow and the model being developed.
This process helped me understand the complexity of computer vision models, how real-time inference works, and the architectural challenges involved in delivering such a solution. So, what was the main issue that led the business team to this state? The inferences were inconsistent, and those that were generated had a high rate of false positives. But what was happening behind the scenes that caused these problems? Bandwidth limitations, a problem not related to data itself, but to the physical network capacity required to download and process the video streams used by the model.
This led to a critical question that needed to be answered together with the business: Is a real-time solution truly necessary for what we are trying to measure?
Rethinking the Product Under These Constraints
This question forced us to rethink our methodology and find a better way to address a problem that might not have been clearly understood by the technical team. But how do you tell a frustrated business that you need to start over and build a new solution with a different approach?
This required pausing the current development and dedicating a full month to internal planning with the technical team. During this time, we identified existing solutions in the market, conducted benchmarking sessions with different industries and companies, and worked to find the most suitable approach for our context. We held multiple knowledge-sharing sessions, defined the architecture, and evaluated the best model to implement.
At the same time, I participated in several meetings with the business to refine the project scope, focusing on identifying the real pain point to be solved. This meant shifting towards a problem-driven methodology, prioritizing a solution that fits the business rather than forcing the business to adapt to a predefined solution. As Uri Levine said, “Fall in love with the problem, not the solution.” This mindset encourages deep understanding and leads to solutions that are more likely to be adopted, instead of quick fixes without proper analysis.
After this month of reassessment, clarifying the real business problem and defining a concrete plan, we began developing a new methodology and presented two possible solution paths.
In addition, we structured the work into three stages:
- POC (Proof of Concept): Narrowing the problem to a single event detected across three cameras to test scalability and network saturation.
- MVP (Minimum Viable Product): Defining clear business rules (in collaboration with business stakeholders) and scaling the solution to five cameras.
- PR (Production Release): Expanding the solution to all cameras within the target area.
Edge Computing for Real-Time or Batch Detection
Following the identification of two possible solution paths, it is important to understand that computer vision models can operate using two types of inference: real-time (streaming) and batch processing.
- Streaming inference refers to detecting events as they happen. For example, detecting a speeding vehicle through a security camera allows for immediate action regarding safety and potential incidents.
- Batch inference refers to detection that occurs with a delay, executed at fixed intervals such as daily or hourly. This approach allows for identifying patterns over time, such as recurring unsafe behaviors, enabling actionable insights and long-term improvements.
Depending on the type of behavior the business aims to detect, solutions can be classified as batch or streaming, which also helps reduce bandwidth usage when processing video data. But what happens when real-time inference is required, and the infrastructure cannot support it?
This is where edge computing comes into play.
Edge computing is a paradigm that enables data processing close to the source, using hardware devices such as GPUs, sensors, or embedded systems. This reduces latency and bandwidth consumption while enabling real-time analysis.
Many industries currently use edge computing to run analytics directly on security cameras without overloading the network, while still generating valuable insights for operational safety.
Can a Non-Technical Business Understand This Complexity?
Managing a complex solution that must be explained to a non-technical business, while maintaining the same delivery expectations as a fully developed product, is where my role became particularly important.
Explaining concepts that involve multiple teams, such as infrastructure, data, networking, and architecture, to a business that only seeks concrete results requires translating technical ideas into simple, non-technical language. This included explaining what edge computing is and clarifying the differences between real-time and batch approaches.
We then conducted brainstorming sessions with both the technical and business teams to define which milestones truly required real-time capabilities and which could be handled in batch.
As a result, we decided to work with two dedicated teams:
- One team focused on edge computing, including hardware acquisition, infrastructure setup, and real-time model testing.
- Another team fully dedicated to batch solutions, ensuring continuous progress and value delivery to the business.
This approach helped calm the business by providing concrete results, a well-defined roadmap, and clear timelines for delivering partial solutions that, together, formed a robust and complete product aligned with business expectations.
We Have the Model, But How Do We Show Results to the Business?
Alongside the technical work, we focused on finding a tangible way for the business to evaluate whether the computer vision model was delivering the expected results.
Is the best way to present results through a pipeline, raw inference tables, or video footage from cameras? No. The business operates more effectively with simpler tools.
Through iterative discussions, we concluded that the best way to present results was a simple dashboard with key metrics.
This demonstrates that even a complex solution involving advanced analytics and image processing can be presented in a format that the business is already familiar with.
The delivered dashboard was straightforward:
- A daily view of detected unsafe behaviors
- A focus on accuracy over volume of alerts
- Aggregations by date, time, and location
- Number of alerts and a snapshot image from the camera at the moment of detection
This also enables users to trace back to the original video if needed, allowing further investigation with precise timestamps.
With this output we were able to finish the product to be delivered and close the project.
Key Learnings from This Experience
It is critical to understand the real business pain and the desired outcome, something that can be used in daily operations without creating friction, but rather integrating smoothly into existing workflows. The initial solution that had been promised did not add value; instead, it generated noise through false alerts, increasing dissatisfaction.
Additionally, requesting data again while the product was already in development was not well received by the business. It created the perception that the problem had not been properly understood, leading to a loss of trust and credibility. Managing this situation required sensitivity, and trust was gradually rebuilt through in-person meetings and clearly structured agendas with defined objectives.
Documenting every meeting and progress update is essential. It helps define the scope of each development stage, break down work into manageable tasks, and maintain alignment with the roadmap. It is also important to frequently update the business on even small progress milestones.
From a technical perspective, I learned that projects should not start from the use of a trending technology, especially with the current rise of AI tools. Instead, the solution should be driven by a real problem. The best approach is to start simple and increase complexity only when necessary.
Finally, working with a non-technical business helps you understand the most effective way to communicate complex problems using simple language. This is key to aligning expectations and successfully delivering solutions involving both real-time and batch processing.
