About us / 00
An engineering
practice, not an
agency pipeline.
TRAIN IN THE LAB LTD is an IT company working on custom software, web platforms, cloud infrastructure and the integrations between them. We take on a small number of engagements at a time and stay close to the code we write.
01Focus
What we concentrate on.
Our work sits with operational software — the systems a business runs on rather than the ones it demonstrates. That means internal platforms, customer-facing web applications, data pipelines, and the connective tissue between tools that were never designed to talk to each other.
We deliberately avoid spreading across every technology category. Depth in a smaller set of problems means we recognise failure modes early, and it keeps our estimates honest, because they come from work we have actually done rather than from a general sense of difficulty.
We also take on continuation work. Inheriting a codebase written by someone else is a normal part of software engineering, and treating it with respect — reading it before judging it — usually produces a better result than a rewrite.
02Collaboration
How we work with your team.
Written by default
Decisions, trade-offs and open questions are written down in a shared place. Calls are for discussion; the record lives in text so it survives absence and turnover.
One point of contact
Each engagement has a named person on our side responsible for the work and for telling you when something is going wrong, early rather than late.
Visible progress
Work is reviewable in a running environment as it is completed, not held back for a single reveal at the end of a phase.
Direct disagreement
If we think a requested approach will cause problems, we say so, explain why, and then implement the decision you make.
03Engineering philosophy
Complexity is a cost, and someone always pays it later.
Every abstraction, dependency and service added to a system is borrowed against future understanding. Sometimes that borrowing is worth it. Often it is added out of habit, or because a pattern was appropriate in a system ten times the size.
We ask what the simplest arrangement is that satisfies the real constraints, and we push back on structure introduced for hypothetical futures. When a problem genuinely is complex, we isolate that complexity behind a clear boundary rather than letting it spread across the codebase.
We prefer explicit code over implicit magic, mature libraries over novel ones, and systems where a new engineer can trace a request from entry point to database without a guide.
read first · measure before optimising · delete more than you add
04Delivery principles
01
Slices, not phases
Work is cut into vertical slices that each produce something running. This surfaces integration problems in week one rather than month four.
02
Estimates with ranges
Estimates carry the uncertainty they actually have, and the assumptions behind them are stated so they can be checked.
03
Definition of done
A task is done when it is tested, reviewed, deployed to a shared environment and documented — not when the code compiles.
04
No silent scope drift
Additions are discussed and their effect on the schedule stated before they are absorbed into the work.
05
Environments that match
Staging resembles production closely enough that passing there means something. Differences are documented where they cannot be removed.
06
Handover from day one
Documentation is written as the system is built, so handover is a conversation rather than an archaeology project.
05Maintainability
Software is maintained far longer than it is built.
The initial build is a small fraction of a system's life. Most of the money and most of the frustration arrive afterwards, in the years when people who did not write the code have to change it under time pressure.
We optimise for that period. Consistent structure across the codebase, tests that document intent, dependency versions that can still be upgraded, deployment that is scripted rather than remembered, and written architecture notes explaining the reasoning behind decisions that would otherwise look arbitrary.
The practical test we apply: could a competent engineer who has never seen this system make a small change safely within their first week? If not, something is missing — usually documentation, tests, or clarity in the code itself.
06Scope of claims
What this page does not claim.
This site describes how we work and what we offer. It intentionally contains no client names, testimonials, awards, certifications, performance statistics or office locations, because we publish only information we can support. Any project examples elsewhere on this site are labelled as illustrative scenarios.