Software shaped
around how you work.
Off-the-shelf systems ask you to change your process to fit them. Sometimes that is right. When your process is the thing that makes you competitive, it is expensive and quiet damage.
Interface
Logic
Access
Data
Quick answer
When is custom software the right choice?
Custom software is the right choice when the process it supports is itself a source of advantage, when no available product fits without substantial workarounds, or when the cost of adapting the organisation to a product exceeds the cost of building. It is the wrong choice for well-solved problems: accounting, email, payroll and general customer relationship management have mature products that will outperform anything built from scratch. The practical test is whether you would describe the process as ordinary or as the reason customers choose you. Ordinary processes should run on products. Distinctive processes are usually worth building around, and are frequently the ones being distorted to fit software that was designed for someone else.
The product doesn't fit.
Nobody has admitted it yet.
Most failures here are quiet — a spreadsheet running the real process beside software that was supposed to.
Failure 01
The workaround economy
The product does not fit, so the team maintains spreadsheets alongside it. The real system is the spreadsheet and nobody has admitted it yet.
Failure 02
Access control in the interface
Permissions are enforced by hiding buttons. Anyone calling the API directly reads everything, and no log records that they did.
Failure 03
Built to demo, not to run
It is impressive in a presentation and unmaintainable in month six, because nothing was typed, tested or documented while it was being written.
Four deliverables, not a feature list.
The model comes first. Everything else is built to match it, not the other way round.
01
Domain model
Your entities, relationships and rules expressed properly in the data structure rather than approximated by a product's assumptions.
02
Role and access design
Default-deny policies at the database with roles matching how your organisation actually delegates, verified by query.
03
The platform
Server-rendered, typed, accessible and responsive to 360 pixels, with structured data written alongside the content.
04
Operational readiness
Environment separation, locked dependencies, verified restorable backups, error handling that exposes nothing internal.
Five steps, in this
order, every time.
The data model is decided before a single screen is designed.
- 1
Model
Entities, relationships and rules defined before any interface exists. The data model is the product.
- 2
Bound
Roles and default-deny access policies designed with the model, never bolted on afterwards.
- 3
Build
Server-rendered, typed, accessible, tested. Dependencies locked and environments separated.
- 4
Gate
Rendering, performance, accessibility, dependency audit and cross-tenant access verified before deploy.
- 5
Hand over
Repository access, documentation and a restore drill, so your team can operate it without us.
Engineering rules in the Standard, each with a verification method.
Classified Critical: verified restorable backups and server-rendered discoverable content.
Systems handed over without a tested restore.
Why the data model is decided before the interface.
Every system we have been asked to rescue had this sequence reversed — screens designed first, with the data structure inferred from them. The result is a model that describes the interface rather than the business, and every subsequent feature fights it. Changing a data model after real records exist is a migration with downtime and risk; changing an interface is an afternoon. Deciding entities, relationships and access rules first costs a few days at the start and removes an entire category of expensive change later. Verification is straightforward: the model should be explicable without reference to any screen.
Source: The Qawex Standard v1.0, rules ENG-01 to ENG-11 · /standard/engineering/Answers, not brochures.
Should we build or buy?
Buy for ordinary processes, build for distinctive ones. Accounting, payroll and email are solved problems where a product will beat anything custom. The processes worth building around are the ones you would struggle to explain as ordinary — and those are usually the ones currently being distorted to fit software designed for someone else.
What stack do you build on?
Server-rendered TypeScript with a managed PostgreSQL database behind a CDN, with specifics depending on what you already run and what your team can maintain. We do not select a stack your people cannot support after handover, and we do not migrate a working system for novelty.
Can our team maintain it afterwards?
That is the intent, and handover includes documentation, repository access and a restore drill rather than a slide deck. The Standard is public, so your developers can verify the work against the same rules we used. Where you would rather not maintain it, a managed package covers that instead.
How do you handle access control?
At the database, with default-deny policies keyed on tenant and role, verified by authenticating as one tenant and querying another's data directly. Zero rows returned is the only acceptable result. Hidden interface elements are never treated as access control, because they are not.
What about integrating with systems we already run?
That is systems integration, and it is usually a component of a platform build rather than a separate project. Records, billing, messaging and third-party services connect through APIs, and for health data we build to HL7 FHIR rather than a proprietary export.
Start with the model, not the screens.
Scoping defines your entities, roles and access rules before anything is built, and tells you honestly if a product would serve you better.