Approach
How we build
Most of what separates software that survives contact with a real business from software that does not is decided early, in what the system refuses to do. This page sets out how those decisions get made, with examples from work you can go and read.
Structure under load. Designing the constraints in is what makes it hold.
Scoping
Decisions before code
Every engagement starts with a written scope, and the most valuable part of it is usually the list of what the system will not do. A scope that only records intentions leaves every ambiguity to be resolved during the build, which is the expensive place to resolve them.
The scope also states what we need from you and by when. Most delays on this kind of work are not engineering delays. They are waiting on an export, a login, or a decision that only you can make, and naming those upfront is cheaper than discovering them in week three.
If an existing product does the job, the scope says so. That conversation ends without an invoice. We would rather lose a build than sell one that should not have been built.
Principles
Constraints designed in
Each of these is taken from something we have actually shipped, and each one made the build harder. They are on the corresponding product pages in more detail.
A model does not sign anything
In our safety documentation tool, approving and issuing a risk assessment are not reachable through the AI interface at all. A named competent person does it in the application, because the regulations put a person’s name on the assessment and that has to mean something. Wherever there is real accountability, a person holds it.
Absence is reported, not assumed
Our fleet tool treats a blank MOT date as a gap rather than as compliance, because a missing record is not the same as a clean one and it is the blanks an examiner asks about. Software that quietly treats unknown as fine is worse than useless in a compliance setting.
Nothing derived is stored twice
There is no "current mileage" field anywhere in the fleet tool. Mileage, consumption, next service and cost per mile are all arithmetic over recorded readings. Storing a derived figure means eventually it disagrees with what it was derived from, and then nobody knows which is right.
An issued document cannot be rewritten
Library entries are copied onto a job rather than referenced, so editing a hazard library next year cannot change a document issued last year. Records that have gone out into the world have to stay as they were sent.
Separation is tested in both directions
On our multi-tenant platform, every write policy carries an explicit check, the tenant identifier is never settable by the browser, and isolation is tested from both sides before a second business is let in. One customer seeing another’s data is the failure that ends a platform.
Ask rather than infer, where being wrong is costly
The trade platform asks which VAT treatment applies and shows the basis for it rather than guessing from the job. Construction VAT has too many edge cases for a guess to be safe, and a confident wrong answer is worse than a question.
Data, access and security
How we work
- Credentials live in a managed store, never in source and never in a shipped binary.
- Where a system holds personal data, controller and processor roles are settled before the build, because it changes what the software has to do.
- Where we act as processor, a data processing agreement is in place before anything goes live.
- Local-first is offered wherever it genuinely fits: a desktop tool with a local database means no hosting bill and nothing leaving the building.
- Accounts and credentials are created in your name, so access does not depend on our continued goodwill.
Quality
- Automated test suites on anything where a wrong number has consequences.
- An accessibility check against every build before handover, included as standard rather than sold as an extra.
- Generated documents produced as PDF/A where they may need to be read back years later.
- Byte and performance budgets on anything shipped to a browser, measured on every build rather than remembered.
Handover
Built to be handed over
A small supplier is a real risk to take on, and pretending otherwise would not survive a procurement conversation. The way we answer it is to make the work survivable without us: the source is yours, the accounts are in your name, and the documentation is written for somebody who has never spoken to us.
Support is offered afterwards and priced separately. It is never bundled into the headline price, because a support fee that exists to make leaving difficult is not support.
What we will not do
Stated plainly, so nobody wastes a meeting
- Build software that should not be built. If a product on the market fits, we will name it.
- Let an automated system approve, sign or issue anything carrying real accountability.
- Hold your accounts or credentials in our name as a way of retaining you.
- Quote a build without a written scope, or absorb scope changes quietly and argue about them at the end.
- Give legal advice. We flag where something needs a solicitor and say so rather than guessing.
- Take on work that needs a full-time on-site team. We are a small operation and we say so before you ask.
Bring us something difficult
The engagements that go best are the ones where the constraints are real and stated early. Tell us what yours are.