About
Built to be
maintained
POSTEJ LIMITED is a software engineering company. Our work is the ordinary, careful practice of designing systems, writing them down, testing them and keeping them running once other people depend on them.
About
POSTEJ LIMITED is a software engineering company. Our work is the ordinary, careful practice of designing systems, writing them down, testing them and keeping them running once other people depend on them.
01 — Focus
We build software for organisations whose processes are specific enough that generic products fit awkwardly, and whose systems are expected to stay in service for years rather than months.
That means internal applications, customer-facing web platforms, APIs, integrations between systems that were designed separately, and the cloud infrastructure underneath them. It also means working inside existing codebases, where the first task is usually to understand what is there before changing it.
02 — Approach to engineering
Before implementation starts we describe the shape of the solution: the domain model, the boundaries between components, the data that moves between them and the failure modes we expect. This costs a few days and repeatedly saves weeks, because disagreements surface while they are still cheap.
We optimise for the next person: consistent structure, meaningful names, tests that document intent and comments reserved for reasoning that the code cannot express. Refactoring is treated as routine maintenance rather than a separate project to be scheduled.
03 — Working principles
A problem that cannot be described in writing is not ready to be built. We write the statement first and adjust it as understanding improves.
Changes arrive in increments that can be read, tested and reversed, which keeps risk proportional to the size of each step.
Widely supported tools and conventional structures are preferred unless a specific problem justifies something unusual.
Configuration, contracts and assumptions are written down rather than carried in the heads of the people who built the system.
Logging, metrics and deployment paths are part of the first release, not retrofitted after the first incident.
Estimates are ranges, risks are named early and problems are raised while there is still room to respond.
04 — Collaboration practices
05 — Commitment to maintainability
Most of a system's expense is incurred after it is first delivered. We plan for that: dependencies are kept current, schemas are migrated rather than patched around, configuration is version controlled, and documentation lives next to the code it describes.
A project is finished properly when another competent engineer can read the repository, run the tests, deploy the system and make a change with confidence — whether or not that engineer works with us.
06 — Company information