How Vanda Coatings built its own AI system (and what we learned doing it)
A 25-year-old Cardiff business. Thirty thousand data duplication points. A custom ERP built from scratch. This is the project that the automation practice is built on.
Book a free callWhat the project delivered
Data duplication points identified and resolved across the business.
Admin time saved across the team, every week, once the system was running.
Of accumulated process knowledge captured, structured, and made usable.
Who now advises other SMEs on AI implementation. First-hand, not theoretical.
Vanda Coatings: a real business, not a case study assembled after the fact
Vanda Coatings is a Cardiff-based commercial recoating business. It was founded in 1998 and has been owner-managed since the management buyout in 2003. The business has been operating for over 25 years across commercial, industrial, and infrastructure projects. Clients include BAA (now Heathrow Airport Holdings), Canary Wharf, and Google.
This is not a startup, not a digital business, and not a company built around technology. It is a traditional services business that has grown organically over a quarter of a century. It has the operational complexity, the legacy systems, the undocumented processes, and the staff culture of a real owner-managed SME. That context matters, because it is exactly the environment where the AI build happened.
Anthony Jones completed an MSc in Computing at Cardiff University while running the business. That gave him the technical foundation to build internally rather than commission externally. What it did not give him was any certainty that the project would work. The build started as an experiment, not a plan.
Thirty thousand reasons to start
The business had grown over 25 years in the way most owner-managed businesses grow: by solving the problem in front of you, then moving on to the next one. Processes were documented when someone had time, which was not often. Data lived in spreadsheets, in email threads, in the heads of people who had been there long enough to remember. A legacy system sat at the centre of the operation, doing some things, ignoring others, and not talking to anything else.
The immediate symptoms were familiar: orders taking longer than they should, costing done by hand, job scheduling managed through spreadsheets that required constant manual updating. Admin was growing as the business grew, which is what happens when the processes underneath do not scale with the work.
When Anthony started doing a proper audit of where the time was going, the picture that emerged was more specific than he expected. Thirty thousand data duplication points across the business. The same information was being entered more than once, in more than one place, by more than one person. Every one of those duplications was a source of potential error. Every one was a source of wasted time. Together, they represented a structural inefficiency that had been quietly accumulating for years.
The problem was not that the business was broken. It worked. It had always worked. The problem was that it was consuming far more time than it needed to, and nobody had ever had the bandwidth to fix it systematically. That is the situation most owner-managed businesses find themselves in.
Start with one thing. Make it work. Then expand.
The system was built in Python and Flask, hosted on Azure. Not a packaged ERP solution selected from a product comparison page. A custom build, designed around the actual workflow of the business rather than a generalised workflow imposed on it. That distinction is the difference between a system that gets used and one that gets tolerated.
The build started with a single process: purchase order matching. The decision was deliberate. Purchase order matching is high-volume, rule-based, and manual. It was taking time every week, the rules were consistent enough to automate, and the risk of getting it wrong was manageable. It was a good test case.
That first module worked. It was not perfect, but it was reliable enough to use, and using it surfaced the edge cases that testing alone would never have found. Once it was stable, the scope expanded: costing next, then job scheduling, then reporting. Each stage followed the same pattern. Build a proof of concept. Put it in front of the people who actually do the work. Fix what breaks. Then move on.
The employee input was not an afterthought. The people who processed orders, produced costings, and managed job schedules knew where the friction was. They knew which steps in a process were genuinely necessary and which existed only because the old system required them. Building without that knowledge produces systems that are technically correct and operationally ignored. Building with it produces systems that people actually use.
The data work ran in parallel with the process work. Deduplication at the scale of 30,000 points is not something you can do by hand. AI-assisted extraction and validation tools were built to identify where the same data existed in multiple forms, reconcile the versions, and feed a single source of truth into the new system. That foundation is what made the automation reliable. Automating a broken data model just produces wrong answers faster.
What changed, and what it meant in practice
Every result here is from the Vanda Coatings deployment. Not an estimate. Not a benchmark from a vendor's marketing material.
30,000 duplication points resolved
The audit identified the scale of the problem. The deduplication work resolved it. Data that had existed in multiple inconsistent versions across the business was consolidated into a single source. That removed the main source of costing errors and made the automation reliable.
5 hours of admin saved per week
Across the team, not per person. That is time that was previously spent on manual data entry, manual matching, and manual report generation. It did not disappear from the business. It was redirected to work that actually required a person's attention.
Costing errors from manual entry stopped
Manual entry was replaced with extracted and validated data. Errors from copying numbers between documents, or from using an out-of-date version of a figure, dropped to near zero on automated steps. For a business where costing accuracy directly affects margin, that is a meaningful result.
Reporting time cut from most of a day to minutes
Reports that had previously required someone to pull data from multiple places, format it, and send it manually now ran automatically. The time saving was significant. More importantly, the reports were current rather than historical by the time anyone read them.
The constraints are the same. The approach is the same.
Vanda Coatings is a commercial recoating business. The specific processes being automated were purchase orders, job costing, scheduling, and reporting. None of that is directly transferable to a financial services firm, a construction company, or a professional services practice.
What is transferable is the set of conditions that made the project necessary and the approach that made it work. The legacy data problem is not unique to coatings. The undocumented processes, the spreadsheet-managed schedules, the manual entry into systems that do not talk to each other: these are the standard conditions inside most owner-managed businesses of 10 to 200 people, regardless of sector.
The approach that worked at Vanda Coatings is the same approach used for every client engagement at smedigital.ai. Start with an honest audit of where the time is actually going. Identify the processes that are high-volume, rule-based, and genuinely automatable. Pick the one with the best ratio of value to complexity. Build a proof of concept. Test it with the people who do the work. Expand from there.
You do not need to start with a full system. The Vanda Coatings build started with one process. That one process worked, justified the next, and the project grew from a single working module into a system that changed how the business operates. The starting point is not a commitment to a large project. It is a commitment to finding out whether a small one is worth doing.
This is the experience that informs every client engagement.
Not a framework borrowed from a consultancy playbook. Not a case study from someone else's client. The Vanda Coatings project is the reason this practice exists: because working through it made clear that most SMEs are sitting on the same problem, and most of them have no one to help them fix it who has actually fixed it themselves.
If you want to talk through what that experience might mean for your business, the first conversation is free. Bring a description of the tasks that take the most time. You'll leave with a clear view of whether there is a project worth doing.