Walking Into Chaos: Building Systems That Outlast Me

776 words (Approximately a 4 minute read)

The Challenge

I often view technical constraints as roadblocks—annoying hurdles that prevent me from building the “perfect” solution. But sometimes, these constraints are the catalyst for necessary structure.

My client, a scaling healthcare provider, faced a dual challenge:

1. Technical: Their backend provider (Semble) offered a rigid API with no tagging or metadata implementation, making dynamic filtering impossible.
2. Organisational: Their internal process was the “Wild West”—hundreds of duplicate, dead, or misnamed booking forms with no central source of truth.

The goal was to build a modern, filterable “Booking Engine” for their website. The result was something much more valuable: A governance system.

To make things more interesting, I had never used Semble before. I walked into this project with zero prior knowledge of the platform’s constraints or quirks. This turned out to be an advantage: instead of relying on “how it’s always been done,” I approached the API limitations as a pure engineering puzzle, free from assumptions.

Overcoming Technical Limitations

The core technical problem was simple: The client wanted users to filter services by Location, Age, and Type (e.g., “London” -> “GP” -> “Child”), but the API only provided a flat list of form titles.

I couldn’t change the API, so I had to tunnel my own data structure through it.

I treated the Form Name—the unique field I could control—as a database row. I implemented a strict schema:

CATEGORY_SERVICE_LOCATION_DURATION_DAY_AGE_OPTION

For example:

gp_consultation_london_30_weekday_adult

This allowed me to parse “dumb” strings into “smart” objects on the frontend, effectively building a relational database inside a text field.

Organising and Implementing a System

This technical decision had immediate consequences for the client’s operations. You couldn’t just “create a form” anymore. You had to follow The System.

I moved from ad-hoc creation to a structured implementation:

1. The Schema: A rigid naming convention that defined exactly what a service was.
2. The Audit: To launch the engine, I had to audit hundreds of existing forms.
3. The Cleanup: Duplicates were deleted. “Test” forms were removed. Ambiguous names were clarified. Broken forms were fixed.
4. The Automation: The system auto-updates itself. New forms are automatically added to the program. With a sensible caching system, a single button press is needed to sync changes.

The technical requirement for the code to work forced the business to organise its assets. The codebase didn’t just display the forms; it enforced hygiene upon them.

Empowering the Team with Custom Tools

A system is only as good as its ease of use. I knew that asking marketing teams to manually type query strings like ?service=GP&location=London was a recipe for typos and frustration.

So, I built a custom URL Builder directly into their WordPress dashboard.

I intercepted the native “Insert Link” modal in WordPress and added a “Booking Engine” panel.

• The Problem: Manually constructing URLs is error-prone. One typo in ?locatoin=London breaks the filter.
• The Solution: A point-and-click interface where they just select “London”, “GP”, and “Child” from dropdowns.
• The Result: The tool instantly generates and inserts the deep link.

This seemingly small addition was a game-changer. It gave the content team the freedom to create targeted landing pages (e.g., “Book a Child GP Appointment in London”) in seconds, with zero risk of broken links. I didn’t just solve the data problem; I solved the workflow problem.

Managing Change

Any new system requires change management. I wasn’t just deploying code; I was deploying a new process.

To support this transition, documentation became a critical deliverable. I provided guides not just on “how to use the website,” but “how to name your services.”

• Before: A marketing manager asks, “Can you add this form to the site?” and a developer manually embeds an iframe.
• After: The manager names the form physio_initial_manchester... in Semble, and it automatically appears in the correct dropdowns on the site.

This shifted the dynamic from manual intervention to automated process.

Communicating and Providing Ownership

The ultimate win wasn’t the code—it was the transfer of ownership.

By documenting the naming convention and building the frontend to react dynamically to it, I handed the keys back to the client. They no longer rely on developers to update the website when they open a new clinic.

They own the schema. They own the data. They own the process.

Conclusion

I set out to hack a rigid API. I ended up building an operating system for the client’s booking process.

Great engineering isn’t just about writing code that works; it’s about building systems that work for the people using them. By embracing the constraint, I created a solution that solved the technical problem and fixed the organisational chaos behind it.