Building Blue Canoe · 15 of 19
A Site Designed for One Job
Why the TMS replacement was designed around one business rather than a platform comparison.
This account was drafted on 19 August 2026. Client feedback and estimates refer to that period; later developments are identified separately.
It would be easy, and unfair, to turn The Motorsports School rebuild into an argument about WordPress.
WordPress is a general-purpose publishing platform with an enormous ecosystem. It is expected to be a shop, brochure, news site, membership system, booking interface and almost anything else its plugins can persuade it to become. The replacement had a much narrower advantage: it only had to be The Motorsports School.
Specialisation, not platform virtue, was the point.
The old journey had moved work into the office
The previous booking application required three clicks before a customer even reached its form. That form did not capture all the information TMS needed, and seat counts eventually had to be adjusted manually after sales.
Customers called because they wanted more information or reassurance that they had selected the correct course. Staff then had to explain the options, take or complete the booking and make sure the remaining availability was correct.
Putting a transaction online is not the same as making it self-service. If the customer still needs reassurance, the office still needs missing information and availability still needs manual repair, the form has only digitised part of the job.
Start with the questions people actually ask
We reorganised the site around the decisions a customer had to make. What is ARDS? Which course applies to me? Am I eligible? What happens on the day? Who will teach me? How many places remain? What do I need to provide?
Some facts came from the old copy, but the wording was rewritten and the promotional layer removed from the information. The aim was not to make the school sound less capable. It was to let capability show through useful answers.
That approach also created more surface area for search. Course pages, ARDS guides, licence pathways and instructor pages each answered a distinct question instead of asking the homepage to carry the entire site.
Build around the operation
The booking system was shaped around the school's actual rules rather than the assumptions of a generic catalogue. Courses could expose appropriate dates, times and places. Customers could see remaining capacity. TMS could add or remove timeslots as instructor availability changed.
The underlying implementation was deliberately small: straightforward PHP, HTML, CSS, JavaScript and JSON, with Stripe handling payment. That choice was not a claim that small code is automatically good code. It simply removed layers we did not need and left us responsible for the layers we did.
The same discipline applied to the frontend: semantic HTML, baseline accessibility, a restrictive content-security policy and no inline CSS or JavaScript. These were not decorative quality marks. They made the site easier to reason about and reduced the number of places behaviour could hide.
We were not building for Lighthouse
The Lighthouse scores were unexpected. They were welcome, but they had not been an original target.
Once the site began scoring unusually well, the remaining points became a useful finishing tool. They helped us chase down the last few stragglers in performance, accessibility, best practice and search presentation. In our checks, we repeatedly saw scores of 100. The build had not been organised around manufacturing four green circles. Those observations are not a promise of identical scores on every device or a substitute for testing with people.
A benchmark can identify a missing label, an expensive request or an avoidable delay. It cannot tell us whether a nervous customer understands which ARDS course to book, whether the office has received the information it needs or whether availability can adapt when another instructor joins the day.
Fitness for purpose
The replacement did not prove that a bespoke site is always better than WordPress. It proved something narrower and more useful: when the business rules are understood and the scope is controlled, software designed for one job can remove compromises that a general system has to carry.
The acceptance test was not whether the new site contained fewer components. It was whether customers could understand, choose and book—and whether TMS could operate the result without fighting it.
The office supplied the answer after launch.