Principles
The principles
we build by.
Eight principles decide how we scope, build and decline work, for our own products and for every client. They are published so you can hold us to them.
8 principles
How we scope, build and decide.
They apply to our own products first and to client work in the same way. When a principle and a deadline conflict, we say so in writing and agree the trade-off with you.
Understand the system before changing it
We read the code, the data and the workflow before we propose anything. Changes made without that understanding are paid for later, in production.
Test every limit before accepting it
Budgets, performance targets and the way an industry has always worked are often assumptions nobody has checked. We check them. Where a limit is real, we design around it and say so.
Operate what we build
We run our own products in production, including their releases, support and running costs. The advice we give clients has been tested against consequences we carry ourselves.
Proven foundations, original products
New ideas belong in the product people use, not in the infrastructure underneath it. We build on proven, well-understood technology so the product can be the part that is new.
Document every decision
Architecture decisions, security reviews, runbooks and the options we rejected are written down and handed over. Your team should be able to run the system without us.
Finish the whole product
Error states, empty states, slow networks, permissions and data migrations are part of the work. Software that only works when everything goes right is not finished.
State the numbers early
Timelines, costs and our confidence in both are stated plainly in the proposal, including when the answer is not the one you hoped for.
Take the longer route when it matters
Some shortcuts stay invisible for a year and then shape a product for good. We avoid those, and explain the trade-off in writing whenever one is requested.
Boundaries
What we turn down.
Four situations where we decline the work or renegotiate the terms. We state them before a contract is signed.
Work we cannot staff properly
If we cannot put the right engineer on the work, we say so and suggest where else to look.
Timelines that skip testing
We will reduce scope to meet a date. We will not reduce testing, review or recovery planning to meet one.
Architecture we would not run ourselves
If we would not run it on Aurelia, Voyazio or AxleOne, we recommend against it in writing and propose an alternative.
Engagements built on lock-in
No undocumented systems, no credentials only we hold, and no proprietary layer that exists to make us hard to replace. You can change suppliers at any time.
Definition of done
Six conditions before we call it finished.
The same six conditions apply to our own products and to client work. They are part of every engagement and are never priced as extras.
Reviewed
No change reaches production without review by a second engineer. The rule is the same for our own products.
Reproducible
Environments defined as code. Any engineer can rebuild the stack from an empty account.
Observable
Logging, error reporting, and alerting configured before launch rather than after an incident.
Documented
Architecture notes, decision records and runbooks are delivered as part of the contract.
Accessible
Semantic markup, keyboard paths, contrast ratios, and reduced-motion support treated as requirements.
Recoverable
Backups are verified by restoring them on a schedule.
Hold us to them.
Tell us what you are planning. If we think a different approach would serve you better, the first reply says so and explains why.