A small practice, taking software seriously.

STYLE AND CLASS LIMITED operates as an independent technology company. We build custom software, cloud platforms and data systems, and we take responsibility for keeping the systems we build in service over time.

The company is deliberately small. We would rather do a limited number of engagements carefully than distribute attention across many at once.

We believe good software is a form of long-term infrastructure. A well-built system reduces operational cost, makes the business easier to change, and quietly compounds in value for years. A poorly built one does the opposite.

Our purpose is to produce software that behaves like the first kind of system: legible, maintainable, secure by default, and honest about its limitations.

To design and build production-grade software that solves specific business problems and can be operated by other engineers years after we finish.

To remain a small, senior engineering practice known for the durability of the systems it produces, and to keep engineering, rather than sales, at the centre of the company.

• Write things down. Requirements, decisions and hand-overs live in writing so that anyone joining later has the same context.
• Prefer boring technology. Established, well-documented tools make software easier to operate and easier to hand over.
• Ship reversibly. Every change we make in production can be rolled back cleanly.
• Own the whole path. The engineers who design a system are also the ones who write it and help operate it.
• Say “no” when it matters. If a request would produce software the client would regret, we say so.

Engagements are staffed with a small number of senior engineers who stay on the project from discovery through operation. Client stakeholders speak directly with the people writing the code; there is no account layer between.

We communicate primarily in writing, with a fixed cadence of short synchronous reviews when they add value. This keeps everyone aligned without overloading calendars.

We work in short iterations with working software at every step. Testing, observability, security review and deployment automation are part of the build, not a phase at the end.

Architectural decisions are captured in short written records so they can be reviewed later by people who were not in the room when the decision was made.

Every release is preceded by automated tests, code review and, where relevant, security and performance checks. Every deployment is observable, and every incident is documented.

When an engagement ends, the receiving team inherits code that is legible, documented and covered by tests, together with the runbooks needed to operate it.

We assume credentials leak, dependencies break, and networks are hostile. That assumption shapes how we design authentication, how we manage secrets, how we separate environments, and how we treat data at rest and in transit.

Where an engagement handles personal data, we minimise what we retain, document where it lives and align processing with the client’s legal obligations.

The value of an engagement is not measured by lines of code delivered but by the change it produces in the client’s operation: a manual process removed, a legacy dependency replaced, a data question answered faster, a system made cheaper to run.

We aim for changes of that shape. When a project cannot produce one, we say so early and adjust the scope rather than continuing for its own sake.