What if a screenshot could become the starting point for a structured analysis?
Financial charts contain a lot of information.
Price movements, candlestick patterns, indicators, support and resistance levels, timeframes and other visual signals all contribute to how traders interpret the market.
For a trader, interpreting a chart is part of the daily workflow. For an AI application, turning that visual information into something useful introduces an entirely different engineering problem.
That was the thinking behind SignalCheck: allow users to submit a screenshot of a trading chart and receive an AI-powered analysis.
The experience sounds simple. The engineering behind it is considerably more interesting.
The challenge of understanding a chart
A chart screenshot isn't a clean dataset. It is an image containing visual information that needs to be interpreted.
The model may need to identify:
- The asset or trading pair.
- The visible timeframe.
- Price direction and structure.
- Relevant technical indicators.
- Potential support and resistance areas.
- Patterns or other visible market signals.
There are complications: the screenshot might be cropped, labels might be difficult to read, indicators might overlap, and the chart might not contain enough information to support a confident conclusion.
This means the application needs to account for uncertainty. A model should not be forced to produce a definitive answer when the image doesn't contain sufficient information.
Why connecting a vision model isn't enough
Modern multimodal models can interpret images and generate natural-language responses. That makes them useful building blocks for applications like SignalCheck.
But a product needs more than an image input and a model response. It needs a consistent pipeline:
1. Image submission
The user uploads a chart screenshot. The application validates the file, checks supported formats and prepares the image for analysis.
2. Image interpretation
The image is passed to a vision-capable model with instructions describing the information that needs to be extracted.
3. Structured analysis
Rather than accepting an unrestricted paragraph, the application should aim for a defined response structure:
- Market context
- Observed trend
- Relevant price levels
- Potential scenarios
- Supporting observations
- Confidence or uncertainty
- Missing information
Structured outputs make it easier to build a consistent interface around the model.
4. Validation and presentation
The application checks whether the response contains the expected fields and presents the analysis in a readable format.
The goal is to turn a model response into an actual product experience.
The latency problem
One of the interesting challenges we encountered while testing SignalCheck was response time.
Analysis could take approximately 20 seconds. That might not sound like much in isolation, but when a user uploads an image and waits without knowing what's happening, 20 seconds can feel considerably longer.
“Model performance and product performance are not the same thing.”
A model might produce a useful answer, but if the application makes users wait without feedback, the overall experience still feels poor. There are several ways to approach this:
Asynchronous processing
Instead of making the entire interface depend on a single blocking request, the application can create an analysis job and process it in the background. The frontend can then retrieve the result when processing is complete.
Visible progress
Users should know that something is happening. The interface can communicate stages such as upload received, reading chart information, analysing market structure, and preparing results.
Caching and request management
Repeated analysis requests, duplicate submissions and unnecessary processing can increase cost and latency. Appropriate caching, request identification and processing controls help make the system more efficient.
Building trust into AI-generated analysis
Trading applications introduce an additional responsibility: AI-generated observations should not be presented as guaranteed outcomes.
There is a difference between identifying a potential market pattern and predicting what the market will do next. A responsible product should distinguish between:
- Information visible in the submitted chart.
- Interpretations made by the model.
- Potential scenarios.
- Information that cannot be reliably determined.
The product should never imply that its analysis is more comprehensive than the information available to it.
Why we approached the product as a complete system
SignalCheck was explored as a product with a market-scanner backend and a Next.js consumer application.
This separation matters because the AI analysis pipeline and the customer-facing experience have different responsibilities. The backend manages processing, model interactions and analysis logic; the frontend manages the user's interaction from image submission to result presentation.
A well-defined boundary makes it easier to improve each part independently.
The bigger lesson
AI products are often described in terms of the models they use. But users don't buy access to a model. They buy an outcome: solving a problem, making a decision or completing a task more effectively.
The model is only one component in that experience. The real product includes everything around it: input handling, validation, processing, latency management, error handling, interface design and user trust.
“A working AI feature is a starting point. A useful AI product is an engineering achievement.”