It starts innocently. Your website is a brochure: services, photos, a contact form. Then customers ask if they can book online. Then pay online. Then log in to check progress, upload a document, see their history. One reasonable request at a time, and somewhere along the way your website stopped being a website.
It became a business system. And the moment that happens, the rules change, because publishing information and operating a service are two different jobs with two different sets of consequences. A typo on a brochure page is embarrassing. A bug in a system that takes bookings and money is expensive.
The signs are easy to spot once you look. Visitors have accounts. Forms create records that staff act on, not just emails. Money moves. Information flows both ways. Someone asks "can the system just..." more than once a month. If your website is doing any of this through a stack of plugins and crossed fingers, it's operating as a system without being built as one.
Every customer action has a staff consequence. A booking made at midnight needs someone to see it, own it and act on it in the morning. The public experience and the staff experience are one design job, and treating them separately is how businesses end up with a beautiful front end feeding a chaotic back office. Before any screens get designed, the underlying journey deserves proper mapping: what's created, who owns it, what happens next, and what happens when it goes wrong.
Screens come and go; your data structure is forever, or near enough. Customers, bookings, jobs, documents and payments need modelling as proper related records with clear ownership, validation and permissions. Get that right and new features become additions. Get it wrong and every new feature is an excavation.
Permissions, in particular, stop being a nicety the day customer data and money arrive. Who can see what, who can change what, and what evidence exists afterwards: these become part of the product itself.
A website-turned-system usually talks to other tools: payments, accounts, email, calendars. Those connections need the same honesty as everything else: visible when they work, loud when they don't. And not everything needs building. Where a standard product does a job well (payments being the obvious one), use it, and spend the custom effort where your business is actually distinctive.
Resist launching seventeen half-features. One complete journey, working end to end, from the customer's first click through to the staff action and back, teaches you more and earns more trust than a sprawl of partial ones. That's how we approached Darkin Architects' client portal, and it's how every good web application starts: narrow, complete, and solid enough to extend.
If your website has been quietly promoted to critical infrastructure, it deserves to be treated accordingly. That's the ground our web application work covers, from websites that are ready to grow into systems, to the full journey, right here in Swansea.