Custom website development

What we build

Cloud web applications, where the product is the software itself and the browser is the delivery mechanism. Client portals, where your customers see their own projects, documents, invoices or status without emailing to ask. Internal tools, which are usually the highest return work we do because they replace hours of manual handling every week. And workflow systems that move a job through its stages with the right notifications, permissions and records at each step.

Most of these projects also involve connecting to something that already exists. An accounting package, a CRM, a scheduling tool, a supplier feed. We build around the tools you already pay for wherever that is sensible, rather than proposing a rebuild of everything because it would be tidier for us.

How we build it

We work in typed JavaScript on the server and the browser, with a relational database underneath and access rules enforced at the database rather than only in the interface. That last point matters more than it sounds: if permission logic only lives in the front end, anyone who can open developer tools can go around it. Rules belong where the data is.

Validation runs on the server as well as in the form. The client version exists to give people fast feedback; the server version is the one that decides. Anything a user could tamper with, including totals, tiers and role assignments, is recomputed server side before it is stored.

We ship in working increments rather than disappearing for three months. You get something usable early, then we widen it. That is partly about risk and mostly about accuracy, because people describe what they need very differently once they are clicking on it.

Data, access and the boring parts

Every project gets a real data model before it gets screens. What the entities are, how they relate, what has to be unique, what happens when something is deleted. Getting that wrong is the single most expensive mistake in this kind of work, because everything built afterwards inherits it.

Authentication, roles and audit trails are designed in from the start. Who can see what, who can change what, and what record exists afterwards. Roles are stored properly in their own table rather than as a flag on a user profile, which is the difference between a permission system and a suggestion.

We also plan for failure states, because they happen. What the system does when an external service is down, when a payment succeeds but the follow up email does not send, when the same webhook arrives twice. Handling those cases is unglamorous and it is most of what separates software that holds up from software that needs a person watching it.

Maintenance and handover

You own the code and the infrastructure accounts. We document how the system is put together, how to deploy it, and where the parts that will need attention are.

Custom software is not finished at launch, and we would rather say so up front than pretend otherwise. Requirements change, usage patterns surprise everyone, and small improvements after three months of real use are usually worth more than another feature at launch. Care plans cover that if you want them, and you are free to take the work elsewhere if you do not.

Questions about web development