Software built with restraint.

We work as an engineering partner rather than a supplier of finished products. That means we take responsibility for the technical shape of a system: how it is structured, how data moves through it, how it is tested, how it is deployed and how it will be changed once it is in use.

Engagements typically involve building something that does not yet exist, replacing something that has become difficult to maintain, or connecting systems that were never designed to speak to each other. In each case the work is scoped in writing before implementation begins, and the scope is revisited whenever the understanding of the problem changes.

We do not position ourselves as a substitute for an organisation's own judgement about its business. We contribute engineering judgement: what is feasible, what it will cost in complexity, and what the long-term consequences of a given technical decision are likely to be.

The practice concentrates on a small number of areas rather than claiming general coverage of every technology in circulation.

Application engineering

Server-rendered and client-side web applications, including the data layer, authentication flows, background processing and the administrative interfaces that support them.

Systems and data flow

Designing how records move between services: message handling, scheduled synchronisation, idempotent processing and reconciliation when two systems disagree.

Interface implementation

Translating designs into accessible, responsive interfaces with predictable behaviour across screen sizes, input methods and assistive technologies.

Operational readiness

Build pipelines, environment configuration, logging, error reporting and the routine mechanics that determine whether a release can be made calmly.

The services listed here are described in more detail on the Services page at dogjonesco.com/services. In summary, the practice covers the full span of a software system's life: deciding what to build, building it, connecting it to what already exists, and keeping it healthy afterwards.

Custom software development

Applications shaped around a specific operational process rather than adapted from a generic product.

Web application development

Browser-based systems with attention to accessibility, performance and behaviour on constrained connections.

Integration work

Interfaces between systems, including the error handling and retry behaviour that integrations usually lack.

Modernisation and maintenance

Incremental improvement of systems already in production, prioritising the changes that reduce risk first.

Technology choices are made in service of the problem, not the other way round. We prefer widely used, well-documented tools with long support histories over newer alternatives that would require the organisation to depend on our continued involvement.

Before a dependency is added, we ask what happens if it stops being maintained, whether the same result could be achieved with what is already in the project, and whether the next engineer would recognise it. A smaller dependency surface is easier to secure, easier to upgrade and easier to reason about during an incident.

Where a client already has an established stack, we work within it. A rewrite is proposed only when the existing foundation genuinely prevents the outcome being asked for, and the reasoning is set out in writing so it can be challenged.

Reliability is a property of how a system is built, not a claim made about it afterwards. The practices below are the ones we apply consistently, and they are the standard we ask to be held to.

Behaviour is verified, not assumed

The parts of a system that would cause real harm if they broke are covered by automated tests written alongside the implementation.

Failure is designed for

Network calls time out, disks fill and third parties return unexpected responses. Handling those paths is part of the feature, not a later addition.

Code is written to be read

Naming, structure and comments are chosen for the person who will next open the file, who may have no context at all.

Changes are reviewed

Work is examined by someone other than its author before it reaches production, and review comments are treated as part of the deliverable.

Security is treated as an ordinary engineering concern rather than a separate stage. Input is validated at the boundary, access is checked on the server for every request, secrets are kept out of source control and dependencies are reviewed when they are introduced and when they are updated.

Personal data is handled on the principle of collecting as little as the function requires and keeping it no longer than the purpose justifies. Where a feature would involve personal data, we ask what the lawful basis is, who needs access to it and how it will eventually be deleted, before the schema is written.

Our own handling of information relating to this website is described in the Privacy Policy published at dogjonesco.com/privacy-policy.

Rather than claim experience in named industries, it is more honest to describe the kinds of situations where this approach tends to be useful. The characteristics below matter more than the sector a business happens to operate in.

Process-heavy operations

Organisations whose day-to-day work follows defined steps that are currently held together by spreadsheets, email and habit.

Multiple systems of record

Environments where several tools each hold part of the truth and someone spends time keeping them aligned by hand.

Long-lived internal software

Applications that are expected to run for years and be maintained by people who did not write them.

Small teams with real constraints

Situations where there is no capacity to absorb an unreliable system, so the cost of a defect is felt immediately.