Index / 00 — Engineering practice
Software built
like laboratory
work.
TRAIN IN THE LAB LTD is an IT company. We design, build and maintain custom software, web applications and cloud infrastructure for organisations that depend on those systems every working day.
Custom software · Web engineering · Cloud & DevOps · Integration · QA · Consulting
01Introduction
A small practice organised around one question: will this still be maintainable next year?
Most software problems we are asked to solve are not exotic. They are the ordinary consequences of systems that grew faster than their structure: manual steps that should be automatic, data that lives in three places, a release process nobody wants to run on a Friday.
Our work is to replace that with something deliberate. We write code that another engineer can pick up, keep the number of moving parts as low as the problem allows, and make the behaviour of a system visible once it is running.
We work in English with distributed teams and communicate in writing by default, so decisions are recorded rather than remembered.
02Core areas of expertise
Four practices, one delivery team.
01
Application engineering
Back-end services, front-end interfaces and the data models that hold them together, built as one coherent system rather than disconnected parts.
02
Infrastructure and delivery
Reproducible environments, build pipelines and deployment routines so that releasing a change is an ordinary, low-drama event.
03
Interfaces between systems
APIs, message flows and data exchange between internal tools and third-party platforms, including the error handling those exchanges require.
04
Verification
Automated test suites, manual exploratory passes and instrumentation that make the behaviour of a system observable after release.
03Custom software development
Systems shaped around how the work is actually done.
Off-the-shelf products assume a standard process. When a business has a process worth keeping, bending it to fit a product is expensive in a way that rarely appears on an invoice. Custom software is worth building when the process is a genuine part of how the organisation operates.
We start from the data and the rules that govern it, then build the interfaces around that model. Typical deliverables are a running application, a documented data model, automated tests, deployment configuration, and notes explaining why the system is arranged the way it is.
04Web application engineering
Interfaces that stay fast as the data grows.
Front end
Component-based interfaces with predictable state handling, keyboard accessibility, and layouts that hold together from a phone to a wide desktop display.
Back end
Server-side logic, authentication and authorisation, background processing, and database schemas designed with the query patterns in mind.
Performance
Rendering strategy, caching and query tuning chosen against measurements taken on representative data rather than assumptions.
Longevity
A conservative dependency list, a documented upgrade path and build tooling that a new engineer can run on the first day.
05Cloud architecture and infrastructure
Environments you can rebuild from a repository.
Infrastructure assembled by hand becomes a record only one person holds. We describe environments as code so that staging and production differ by configuration rather than by history, and so that recovery is a procedure instead of an improvisation.
Provisioning
Declarative infrastructure definitions kept in version control and applied through the same review process as application code.
Pipelines
Automated build, test and deploy steps with a clear signal for what is deployable and what is not.
Observability
Structured logs, metrics and alerts chosen around the failures that actually matter to users, not around everything that can be measured.
Cost and scale
Capacity sized to observed load, with the scaling behaviour written down rather than assumed.
06Systems integration and automation
The interesting part of an integration is what happens when it fails.
Connecting two systems on a good day is straightforward. The engineering is in the rest: duplicate deliveries, partial writes, a provider returning a response nobody documented, a nightly job that silently stopped three weeks ago.
We design integrations with explicit contracts, idempotent operations, retry behaviour with limits, and dead-letter handling so failed work is visible instead of lost. Data migrations run as repeatable scripts with verification steps, not as one-off manual imports.
Automation follows the same rule: a scheduled task is only finished when its failure is as loud as its success.
contracts · idempotency · retries · reconciliation · alerting
07Quality assurance and testing
Testing that describes behaviour, not coverage targets.
A test suite earns its keep when it lets a team change code confidently. We write unit tests around business rules, integration tests across real boundaries such as the database and external APIs, and a focused set of end-to-end tests covering the journeys that must never break.
Tests run in the pipeline on every change. Flaky tests are treated as defects and fixed or removed, because a suite people learn to ignore is worse than no suite. Exploratory manual testing covers what automation is poor at: ambiguity, layout and the feel of an interaction.
08Security-conscious engineering practices
Security treated as a property of the build.
We are engineers, not auditors, and we do not present ourselves as a security certification body. What we do is apply established practice consistently during development: input validation at trust boundaries, parameterised database access, authentication and authorisation checked on the server, secrets kept out of source control, least-privilege access for services, and dependencies reviewed and updated on a schedule.
Where an engagement calls for formal penetration testing or a compliance audit, we prepare the system and documentation for a specialist to assess, and we act on their findings.
09Project delivery process
How a project runs, start to finish.
Step 01
Discovery
We read the existing code, data and documentation, talk to the people who use the system, and write down the constraints that will shape the work: integrations, data volumes, compliance expectations, deadlines.
Step 02
Shaping
We describe the proposed solution in plain terms — components, data flow, sequencing — and identify the parts we consider risky. Anything uncertain is prototyped before it is committed to a schedule.
Step 03
Build in slices
Work proceeds in vertical slices that can be reviewed in a running environment. Each slice ships with its own tests and documentation rather than leaving both to the end.
Step 04
Review and hardening
Code review, dependency review, performance checks under representative load, and a pass over failure paths: timeouts, partial writes, unavailable third parties.
Step 05
Release
Deployment through an automated pipeline, with a documented rollback and a defined check to confirm the release behaved as expected.
Step 06
Handover and support
Runbooks, architecture notes and a walkthrough with the team who will own the system next, followed by an agreed period of support.
10Engineering principles
Six commitments we hold to.
01
Readable before clever
Code is read far more often than it is written. We favour direct, explicit implementations over abstractions that only pay off in theory.
02
Small, reversible steps
Changes are kept small enough to review properly and to undo quickly when something unexpected appears in production.
03
Tests as specification
Automated tests describe intended behaviour, so the next engineer can change the code without guessing what it was supposed to do.
04
Boring infrastructure
We choose well-understood tools and keep the number of moving parts low, because operational simplicity compounds over the life of a system.
05
Explicit boundaries
Modules and services have defined responsibilities and contracts, which keeps a change in one area from rippling through unrelated code.
06
Written decisions
Significant technical decisions are recorded with their context and trade-offs, so future work starts from reasoning rather than archaeology.
11Engagement models
Four ways to work together.
Project engagement
A defined scope with an agreed outcome — a new application, a migration, an integration. Suitable when the objective is clear enough to plan end to end.
Ongoing team capacity
A continuing allocation of engineering time working alongside your own team on a shared backlog. Suitable for products under active, open-ended development.
Focused consulting
A short, bounded piece of work: an architecture review, a performance investigation, a plan for modernising a legacy system. Produces written findings and recommendations.
Maintenance and support
Dependency updates, security patching, small improvements and responses to defects for a system that is already live.
Terms, timelines and commercial arrangements are agreed individually for each engagement.
12Illustrative project scenarios
What a typical engagement can look like.
The scenarios below are illustrative examples written to show how we approach common situations. They do not describe specific clients or completed engagements.
Illustrative scenario — replacing a spreadsheet workflow
A distribution team coordinates orders across several spreadsheets. The work would involve modelling the process as data, building a web application with role-based access, importing historical records, and running both systems in parallel until the new one is trusted.
Illustrative scenario — integrating a new payment provider
An existing platform needs a second payment provider alongside the current one. The work would involve an abstraction over both providers, webhook handling with idempotency, reconciliation reporting, and a test suite covering refunds, retries and partial failures.
Illustrative scenario — moving a monolith to managed infrastructure
A long-running application is deployed by hand to a single server. The work would involve containerising the application, defining infrastructure as code, adding a build and deploy pipeline, introducing monitoring, and cutting over with a documented rollback.
13Frequently asked questions
Questions we are asked most often.
What kinds of projects do you take on?
Software that a business depends on to operate: internal platforms, customer-facing web applications, integrations between systems, and modernisation of software that has become difficult to change.
Do you work with an existing codebase?
Yes. A substantial share of software work is continuation rather than greenfield. We begin by reading the code and its history before proposing any change.
How do you handle changing requirements?
Work is planned in short slices, so direction can change at slice boundaries without discarding completed work. Changes to scope are discussed explicitly rather than absorbed silently.
Who owns the code you write?
Ownership of deliverables is agreed in the contract for each engagement. Our default position is that the client owns the code produced for them.
What do you need from us to start?
A description of the problem, access to any existing system or documentation, and one person on your side who can answer questions and make decisions.
How is progress reported?
Through working software in a shared environment, plus a written summary of what changed, what is in progress and what is blocked.
Do you provide support after launch?
Support terms are agreed per engagement. This can range from a defined handover period to a continuing maintenance arrangement.
What technologies do you use?
Choices follow the problem and the team who will maintain the result. We prefer mature, widely supported tools over novel ones, and we document the reasoning behind each significant choice.
14Contact information
Get in touch by email.
Write to us with a short description of the system, the outcome you are aiming for and any fixed constraints such as a deadline or a platform you must stay on. We reply in English.