Ten kinds of work, described plainly.

Custom development is appropriate when an operational process is specific enough that shaping it around off-the-shelf software would cost more than building the software would. The work starts by describing the process as it actually runs, including the exceptions people handle informally, because those exceptions are usually where generic tools fail.

From that description we define the data the system must hold, the operations performed on it and the rules that must never be violated. Implementation then proceeds in increments that can each be demonstrated against the original description.

Web applications are built with attention to the parts that are usually deferred: keyboard navigation, focus behaviour, colour contrast, form validation messages, behaviour when a request fails and behaviour on a narrow screen. These are treated as part of each feature rather than a pass at the end.

Performance is considered in terms of what the user experiences — how quickly the first useful content appears, whether the layout moves while loading, and how the interface behaves when data is slow to arrive.

Integrations fail in ways that are easy to miss: a request times out, a partner returns an unexpected shape, a message is delivered twice, or a nightly job stops running and nobody notices for a week. We design for those cases as the normal condition rather than the exception.

That means idempotent processing where a repeated message must not produce a duplicate effect, retries with sensible limits, validation of incoming data at the boundary, and visible reporting when synchronisation falls behind.

Cloud-oriented work here means applications that are configured through their environment, that keep no important state on the machine they happen to run on, and that can be recreated from source and configuration alone.

Where managed services genuinely reduce operational burden, we use them and record the dependency. Where a managed service would be difficult to leave later, we say so before it is adopted rather than afterwards.

Consulting engagements are usually short and focused: a review of an existing codebase, an assessment of a proposed architecture, a second opinion on a build-or-buy decision, or a written analysis of why a system behaves the way it does.

The output is a written document setting out what was examined, what was found, what the options are and what the trade-offs of each option would be. Recommendations are stated as recommendations, with the reasoning visible so it can be disagreed with.

Quality assurance covers automated tests at the levels that suit the system — unit tests for logic, integration tests for boundaries, and end-to-end checks for the few journeys that must never break — together with structured manual review where judgement is required.

We also look at what happens after release: whether failures are logged usefully, whether an error can be traced back to a request, and whether the team would find out about a problem before a user reported it.

Security work here is preventative and routine rather than a separate audit. Authorisation is checked on the server for every request, input is validated and output encoded, credentials are held outside source control, and dependencies are reviewed on introduction and on update.

Where personal data is involved, the amount collected is questioned before the schema is written, retention is defined rather than indefinite, and access is limited to the roles that require it.