The standard

Precision Engineering.

The slogan is the discipline. The descriptor names the three properties that discipline is spent on. Both have mechanisms behind them, and this page is the mechanisms.

The discipline

Precision is measurable or it is marketing. Everything below is checked by machine, on every change, before anything merges.

  1. Correctness is proven, not asserted.

    Every change ships with the tests that prove it, in the same change. First-party coverage holds at 70 percent; below that the pipeline fails the build. Coverage counts lines and branches a test asserts on — code executed without being checked is not covered.

  2. Tests go where failure lives.

    Parsing, validation, error branches, boundaries, state transitions, concurrency. Accessors are not padded to lift a number.

  3. A regression is a different event from a bug.

    The first occurrence is fixed. The second stops feature work until the root cause is fixed, with a regression test that fails without the fix. A third is handed over with its full history rather than patched again.

  4. Architecture is selected, not defaulted.

    Onion, hexagonal, plugin, layered, or plain modules — whichever fits the problem. No interface for one implementation, no factory for a struct literal, no layer that only forwards. Real domain complexity gets real structure instead of being flattened into something that reads clean and hides the problem.

  5. Documentation ships with the code.

    A decision recorded a week later is a reconstruction. Documentation that has gone out of date is a defect and is fixed like one.

01

Maxed for speed

Speed

Performance is a decision made during the work, not a discovery made in production.

  1. Designed in, not optimised on.

    Data access patterns, payload sizes and hot paths are settled while the work is being done, not left to be found by a complaint.

  2. The pipeline is fast too.

    Cheapest and most decisive checks first, so an obvious failure never burns a full build. Slow feedback makes careless engineers.

  3. So is delivery.

    One item, one branch, one ticket. Nothing waits in a queue for a meeting.

Evidence This site is under 590 KB in total, serves from one origin, and ships each typeface subset to the characters it actually sets — 342 KB of Akaya Kanadaka becomes 27 KB.

02

Maxed for privacy

Privacy

Software that does not report on the people using it, and can be checked on that.

  1. Nothing is collected.

    No telemetry, no analytics, no crash SDK, no update check against a server of ours. The only outbound connections are the ones the user configured.

  2. Where it matters, absence is enforced.

    Documenta bans HTTP, TLS and socket crates from its dependency graph as a blocking gate. A dependency that would give the application a route onto the network fails the build.

  3. Claims are verifiable.

    Quiblo's silence is a numbered release criterion, checkable by packet capture on a clean install. A claim you can test is worth more than a policy you have to believe.

Evidence This page loads nothing from any origin but this one. No CDN, no font host, no tag manager — which is what lets its Content-Security-Policy be a description rather than an aspiration.

03

Maxed for security

Security

A gate, not a review note. Nothing merges past a red one.

  1. Scanned before it merges.

    Dependency and advisory scanning across every package ecosystem in the project, plus secret scanning over every change.

  2. Licences are the first gate.

    A dependency whose licence is unknown is a liability, not a detail to sort out later.

  3. Releases are traceable.

    Tagged, versioned, and described in notes that say what changed. Nothing is deleted to make a problem go away — authored work moves, it does not vanish.

Evidence Six gates run in a fixed order on every change: licence, code quality, tests and coverage, security, build, release. A red gate is fixed rather than bypassed.

How the work runs

One item, one branch, one ticket
A numbered item with a written plan and a test plan before code starts, on a branch named for it, tracked in the open. Work discovered along the way becomes its own item rather than riding along inside this one.
Protected trunk
Integration and release branches are entered by pull request only. No direct commits, no force-pushes, no exception for small changes. A merge to the release branch is a publish and is treated as one.
Six gates, in order
Licence, code quality, tests and coverage, security, build, release. Blocking rather than advisory: a red gate is fixed, never bypassed.
Nothing is deleted
Authored work moves; it does not vanish. Obsolete documents are superseded and archived rather than removed, and releases stay tagged and described. History stays honest.
Sessions hand off in writing
What changed, what was verified, what is open, what is next, and what is waiting on the client. No decision is explained twice.

What Maxmya will not do

  • Ship untested work to hit a date and call the gap technical debt.
  • Patch a regression a third time instead of escalating it.
  • Accept scope without acceptance criteria. “You’ll know it when you see it” is a dispute scheduled for later.
  • Hand over a system only we can run. If you cannot build, test and deploy it without us, it is not finished.
  • Add a framework, a service or an abstraction because it is fashionable.

Who this is for

Clients who need a system that outlives the engagement: a codebase a new team can pick up, a pipeline that says no on its own, and documentation that matches the code.

In practice that is founders past the prototype, teams inheriting something fragile, and companies whose software became load-bearing without ever having been built like it.

A poor fit for anyone who wants a demo by Friday and will accept whatever is behind the screen.

Talk to Maxmya