MOT Assistant

This project was a bit different for us, and it’s one we couldn’t have done without direct experience. Our founder, Robert, originally trained as a motor mechanic and worked in a garage right here in Fife. He knows what it’s like to have your hands covered in grease, be halfway through a job, and have to stop everything to fiddle with a computer or a notepad. That first-hand knowledge was the foundation for this whole project.

We didn't have to guess what an MOT tester needs. We knew the frustrations because we'd lived them. This meant we could skip the part where the client has to spend hours explaining the basics of their job. Instead, we could get straight to the core problem: how to save a busy tester time and hassle. It’s a good example of why we believe understanding a client's business, sometimes from the ground up, leads to a much better end product. We weren't just building a piece of software; we were building a solution to a problem we understood personally.

The biggest technical challenge wasn't just turning speech into text. Any phone can do that. The real work was in teaching the system to understand a tester's shorthand and convert it into the exact, compliant wording required by the Driver and Vehicle Standards Agency (DVSA). A tester might say 'OSF track rod end has play', but the system needs to output the precise MOT defect description.

This involved building a complex library of terms, synonyms, and variations, and then programming the logic to match the spoken phrase to the correct defect. We also had to account for the noisy environment of a workshop. The system needed to be smart enough to filter out the sound of an airgun or a radio in the background and focus only on the tester's voice. This required extensive testing with different microphones and in various real-world garage conditions. It's a good illustration of our work in specialised app development and business systems – we get into the fine detail to create a tool that actually works on the job.

You can’t market a tool like MOT Assistant with generic SEO. Nobody is searching for 'voice-activated productivity software for vehicle inspectors'. They're searching for solutions to their daily headaches. Our strategy was based on more than 15 years of hands-on SEO experience, focusing entirely on what a stressed MOT tester would type into Google.

We targeted long, specific search phrases, often phrased as problems. Think 'how to find MOT failure codes quickly', 'MOT defect wording cheat sheet', or 'save time writing MOT advisories'. We built content around these questions. The blog posts and guidance pages aren't just for marketing; they are genuinely useful resources for testers. This approach builds trust and attracts the right people. It also means we're not competing with massive software companies on broad terms. We find a specific niche, own it, and provide real value to the people in it. This 'problem-led' approach is something any business can use: think about what your customer is complaining about, and write content that solves that specific complaint.

When designing the tool's interface, our rule was 'make it usable with a greasy thumb'. There could be no complicated menus, no tiny buttons, and no unnecessary steps. A tester is using this mid-test, often while holding a torch and looking under a vehicle. The interface has to be instant and intuitive.

This focus on simplicity is partly driven by our founder's experience with dyslexia and ADHD, which creates a natural preference for clear, efficient tools that cut out noise and reduce cognitive load. If an interface is cluttered or confusing, it gets in the way. For MOT Assistant, this meant a huge, central 'record' button and a clear, legible display of the transcribed text. Every element was put on trial: if it didn't directly help the tester do their job faster, it was removed. This principle applies to any website or app we build. It's not about adding features; it's about creating the most direct path for the user to get what they need.

A project like this goes far beyond a simple website. The website is just the shop window. Behind it, we had to build the entire business engine. This included creating a secure user account system where testers could sign up and manage their details. We developed a full subscription and payment flow, allowing for recurring monthly or annual payments without any manual invoicing.

This is what we mean when we talk about 'business systems'. It’s about creating a product that can run itself. A tester can discover the tool on Google, understand it in seconds from the homepage, sign up for a trial, and convert to a paying customer without ever needing to speak to someone. It's an automated, self-service model. This comprehensive approach, combining a public website with private user accounts and e-commerce functionality, is essential for any modern Software as a Service (SaaS) product.