Before the company — twenty years of embedded vision

Why this page exists

People assume an "AI consultant" is someone who picks models and writes prompts. But projects rarely fail because the model is not strong enough. They fail because nobody handled the other 90%: the device cannot run it, the lighting changes and it breaks, the data format does not match, and after go-live nobody maintains it.

That is where our instincts came from.

The conditions we worked in

• No GPU — inference had to fit inside a CPU budget
• Memory measured in hundreds of megabytes; "just load the model" was not an option
• Devices in the field: vibrating, hot, occasionally losing power
• Nobody watching the logs; when it is wrong, the line stops

In that environment, "95% accuracy" is not the finish line. Running for three months without an incident is.

Three habits it left behind

Measure before you optimise. On an edge device, optimising by intuition usually optimises the wrong thing. Find the real bottleneck first — pre-processing, the model, or I/O.

Design for failure. Nobody on site reads exceptions. When confidence is low, the system needs a safe fallback, not a stalled pipeline.

Deliver something that can be taken over. Code, parameters, data formats, how to retrain. If the client cannot maintain it, the project never really ended.

How it connects to the work we do now

LLM projects face the same shape of problem: the model is one piece. Where the data comes from, what happens when it is wrong, and who maintains it are what decide the outcome.

That is why we insist on audit-before-PoC: confirm the problem is real, the data exists, and someone is willing to change the process — before talking about models.

What is not done

This page does not yet include specific project details (clients, hardware, measured numbers). Those need client consent to publish. If you have a project with similar constraints, let's talk.