A dental services company: from audit to build
- Type
- Client work
- When
- Throughout 2026
- My role
- Product and UX audit, then full-stack development
- Platform
- Web
- Tools
- My own auditing and reporting tool, QuietStrength Audit
The client’s name and screens are kept private. The diagrams are illustrative.
The situation
A dental services company asked me to review an internal web application used by its team to manage day-to-day operational work.
It was already a working product with real users and real business data, so this wasn’t a case of starting again. My job was to understand how it worked, identify where it was making life harder for the people using it and work out which changes would make the biggest practical difference.
What started as an independent audit became an ongoing development relationship, with me taking responsibility for implementing the improvements as well as identifying them.
My part
I started independently, auditing the product from both the user’s point of view and the way it had been built.
Rather than handing over a report and walking away, I then took on the development work myself. That meant I could take each recommendation from problem through to implementation without losing the reasoning behind it in a handover.
The work has covered product and UX improvements alongside front-end, back-end, data, security and reliability work.
What I did
1. Audited what was there.
I reviewed the application as a real working product rather than simply looking at individual screens.
That meant looking at how people moved through everyday tasks, how the interface behaved across different devices and where the underlying architecture, data handling or security could create problems for users.
The result was a prioritised set of findings rather than a long list of everything that could theoretically be improved.
2. Turned the findings into a plan.
I separated the things that genuinely needed attention from the things that could wait.
The aim wasn’t to redesign or rebuild everything. It was to preserve what already worked, tackle the highest-value problems first and make changes that were proportionate to a small business and the way its team actually used the product.
That gave the client a practical development plan rather than an audit report that simply sat on a shelf.
3. Built it.
I then implemented the work myself, front end to back end.
That has included improving existing workflows and mobile usability, strengthening authentication and individual user access, protecting offline working and resolving data synchronisation issues.
Because the product was already being used to run part of the business, changes also had to be introduced carefully. Existing behaviour couldn’t simply be broken in pursuit of something technically cleaner.
Testing therefore became part of the design process too. For more sensitive changes, I built isolated ways of testing against realistic data and deliberately tried to break the behaviour before asking the client to rely on it.
Why it matters
There was no handover between the person who investigated the problem, the person who designed the solution and the person who built it.
When something uncovered during development changed my understanding of the original problem, I could adjust the solution rather than blindly implementing an old recommendation.
That continuity has allowed the product to evolve rather than be unnecessarily replaced.
For the client, the result is an existing business system becoming easier to use, safer and more dependable a piece at a time, without forcing the team through a disruptive rebuild.
For me, it demonstrates the kind of work I most enjoy: understanding an existing product properly, working out what genuinely needs fixing and then being able to build the solution.