Skip to main content
FOUR TIMES ONE logo: four amber squares in a rowFour Times One

An engineering group, described without embellishment

FOUR TIMES ONE builds and maintains software systems. This page explains how we think, how we work, and what we hold ourselves to — nothing beyond that.

01Company story

One idea, examined four ways

FOUR TIMES ONE was formed around a preference for engineering that can be explained. Much of the software we were asked to repair had the same problem: it worked, but nobody could say why it worked, what it depended on, or what would break if it changed.

So the group organised itself around a simple method — examine one problem from four sides: the process it serves, the data it moves, the people who operate it, and the system that must keep running afterwards. That is what the name records.

We publish no timeline, office list, or client roster, because we prefer to state only what is verifiable. What we can describe precisely is the work: services, process, and the standards we hold each increment to.

Cluster of matte terracotta and cream geometric blocks arranged into one floating structure
Figure 1 — four perspectives assembled into one structure.

02 — Mission and vision

Where we are going, and why

Mission

To build software that the people who own it can understand, operate, and change without depending on the people who wrote it.

In practice this means documented architecture, automated tests, reproducible environments, and handovers that include the reasoning as well as the code.

Vision

A working standard where maintainability, accessibility, and security are ordinary requirements rather than optional extras.

We would rather contribute to that standard through consistent delivery than through claims about it, which is why our public statements stay narrow and checkable.

03Values

Six commitments we apply to every engagement

  • V01

    Say what is true

    We describe only work we perform and claims we can support. No invented history, awards, or figures.

  • V02

    Write it down

    Decisions, assumptions, and risks exist as text. A system nobody can read is not finished.

  • V03

    Small steps

    Short increments with acceptance criteria keep mistakes cheap and progress visible.

  • V04

    Least privilege

    Access, data, and dependencies are kept to the minimum the system genuinely requires.

  • V05

    Leave it maintainable

    Readability and tests are part of delivery, because most of a system's life happens after launch.

  • V06

    Accessible by default

    Interfaces are built for keyboard, contrast, and assistive technology from the first commit.

Hand-drafted technical schematic of a network topology drawn in rust and amber ink on warm paper
Figure 2 — architecture is drawn before it is written.

04Approach to technology

Boring choices, deliberately made

We select technology after the problem is understood, and we favour mature, well-documented tools over novel ones. A component enters a system when it removes more risk than it introduces.

Dependencies are reviewed for maintenance status and licence terms. Infrastructure is expressed as code so an environment can be recreated rather than remembered. Where a simpler approach solves the requirement, we take the simpler approach and say so.

05Quality principles

What "done" has to mean

An increment is complete only when each of these is satisfied. None of them is negotiable at the end of a sprint.

  1. Q01Acceptance criteria were written before implementation began.
  2. Q02Every change passed peer code review.
  3. Q03Automated tests cover the new behaviour and run in the pipeline.
  4. Q04Keyboard operation and contrast were checked against WCAG 2.2 AA expectations.
  5. Q05Performance stayed within the agreed budget on a mid-range device.
  6. Q06Inputs are validated on both the client and the server.
  7. Q07Documentation and release notes were updated in the same change.

06 — Collaboration philosophy

Fewer meetings, more written record

We work asynchronously by default. Scope, questions, and decisions live in shared documents and trackers so anyone can catch up without a call. Synchronous time is reserved for the discussions that genuinely need it: design reviews and demonstrations.

Disagreement is treated as useful information. When we think a request will cause a problem later, we say so, explain the trade-off, and record the decision that follows — including when the decision is not ours.

Two engineers discussing code on a monitor together in a warm, low-lit workspace

07Team expertise

Described by capability, not by biography

We do not publish names, photographs, or headcounts. What we can describe honestly is the range of competence the group covers, and the fact that every engagement is staffed only with the disciplines it actually requires.

  • Software engineering across web front-end, backend services, and API design.
  • Architecture and technical analysis, including review of existing systems.
  • Cloud and platform engineering: containers, pipelines, infrastructure as code.
  • Data engineering: pipelines, validation, reporting models, and automation.
  • Quality engineering: test strategy, automation, accessibility, and performance.
  • Security-oriented practices: threat modelling, access design, secure review.

Where an engagement needs expertise the group does not hold, we say that plainly rather than learning it at a client's expense.

Fibre optic patch cables plugged into a server switch, photographed close up in amber light
Figure 3 — systems we are expected to keep running.

08Contact information

Reach the group in writing

Full contact details are listed on the Contacts page.

Company
FOUR TIMES ONE
Website
fourtimesonegroup.com