Custom websites for behavior a template cannot do.

• Choose custom development when the requirement is behavior, not appearance.

  Calculations, lookups, gated content, records flowing into another system, or a workflow the business runs daily. If the honest answer is that the site just needs to look better, a business website build is the cheaper route.

• Choose a business website when the job is content and conversion.

  Pages, proof, search visibility and inquiries. That is a different build with a different cost, and a custom system for it would be money spent on capability you never use.

• Consider a web application when users need accounts and state.

  Once people sign in, have permissions, and change data that other users see, you are building an application. It belongs under web apps and SaaS, where the architecture starts from the data model.

When an off-the-shelf tool forces the business to work in a shape that costs it money, or when the process is itself a competitive advantage. If an existing product fits with light configuration, buying it is cheaper. Custom work earns its cost through the workarounds it removes, not the control it offers.

The useful test is what happens today without it. If a person reconciles two systems by hand every week, that time has a price, and it recurs. If the workaround is mildly annoying twice a year, it does not justify a build.

The second test is what the requirement will be in two years. Custom work is worth most where the process is stable and central, and worth least where the business is still deciding how it operates — there, a configurable product buys you the right to change your mind.

Through documented interfaces, in one direction at a time. The website either reads from another system, writes to it, or both, and each connection is specified with its authentication, its data shape and what happens when the other side is unavailable. Silent failure is the defect to design out.

Most connections fall into a small set of shapes: fetching data to display, submitting a record, receiving an event from another system, or keeping two stores in step on a schedule. Which shape applies decides how errors are handled and whether the page can be static.

• A read at build time, where data changes rarely — the page stays fully static.
• A read on the server per request, where the data has to be current.
• A write on form submission, validated and stored before it is forwarded.
• An inbound webhook, where the other system tells you something changed.
• A scheduled job, where two systems are reconciled on a timetable.

Custom code does not maintain itself, and neither does a plugin stack. Dependencies receive security updates, browsers change, and third-party interfaces get versioned or deprecated. The difference is that with custom code the work is visible and scheduled rather than triggered by something breaking.

We hand over documentation, a release process and a rollback route so that maintenance is possible without us. Where you would rather it were not, care plans are covered under hosting, maintenance and support as an explicit arrangement rather than an assumption.

• Frontend development
• Backend development
• Database-backed websites
• API-connected websites
• Dynamic websites
• Custom functionality

• The software fits the process

  The build follows how the business works instead of the reverse, which removes the manual workarounds that quietly consume more time than the software cost.

• One system instead of twelve components

  Fewer moving parts means a smaller security surface, fewer update conflicts, and a clear answer to which part of the codebase owns a given behavior.

• Custom without losing search

  Public pages stay statically generated or server-rendered with generated structured data. Functionality lives behind them rather than in front of the content.

• No supplier lock-in

  Standard languages, standard frameworks, your repository, documented deployment. Another developer can take it over, which is the only real protection a client has.

• A calculator, configurator or quoting tool

  Pricing, sizing or eligibility logic that a visitor uses before making contact, and that has to stay consistent with what the business will actually honor.

• A database-backed directory or listing

  Stock, properties, courses, practitioners or locations, where the records change often and each one needs a page a search engine can index.

• A site that has to talk to another system

  Availability from a scheduling system, records into a CRM, a lookup against an internal database. The website becomes an interface rather than a leaflet.

• TypeScript throughout, so the shape of the data is checked at build time rather than discovered in production.
• Server-rendered React through the Next.js App Router, with static generation on every route the content allows.
• A data model designed first, with the access layer written against it rather than queries scattered through the interface.
• Server-side validation on every input, because validation that only runs in the browser is a suggestion.
• Integration failures handled explicitly — retries, timeouts and a visible state — rather than left to fail silently.
• Secrets and credentials in environment configuration, never in the repository.