Start with discovery
Paylo.One · Systems engineering

We engineer systems that hold.

Paylo.One is a systems engineering firm. We take on zero to one builds, reliability work, process design, and complex systems where the cost of getting it wrong is operational rather than cosmetic. We start with the problem and the constraints, not the framework.

Start with discoverySee the capabilities
  • 01Zero to one: from an unproven design to working software on an honest scope
  • 02Reliability: designed recovery and stated guarantees, not incident response after the fact
  • 03Process: an engineering practice your team can actually run, sized to the work
  • 04Complex systems: boundaries, state ownership, and contracts that survive change
  • 05Our engineering doctrine is published. Read it before you decide to hire us.
Competing constraintsOne designed system
CONSTRAINTSREQUIREMENTSFAILURE MODESLEGACY ESTATECOMPLIANCEOPERATIONSCOSTTEAM SHAPEOne designed system

Architecture follows constraints, not fashion. Every line into the design is one we can name, and every trade-off between them is recorded.

The firm

Paylo.One is a systems engineering firm.

We work on systems where correctness, reliability, and the ability to keep changing the system matter more than the speed of the first release. Engagements run from discovery and architecture through implementation, verification, and handover into your own environments.

Sequence

Engineering precedes implementation

We understand the problem, the requirements, and the constraints before we write code. Implementation is the last stage of engineering, not the first.

Constraints

Architecture follows constraints

Structure comes from load, latency, consistency, compliance, cost, and the shape of your team. Never from what is currently popular.

Failure

Recovery is designed, not discovered

Everything fails. Timeouts, retries, idempotency, backpressure, and degraded modes are decisions taken before implementation, not patches applied after an incident.

Honesty

We surface conflicts, we do not reinterpret them

When implementation shows the requirements are wrong, infeasible, or ambiguous, we stop and say so. We never quietly build something else.

The doctrine behind this is written down, published under an open licence, and applied on every engagement. You can read it in full before you decide to work with us.

Where we work

We take on engineering where the consequence of failure is operational, financial, or regulatory. The sector matters less than the shape of the problem: real constraints, real integrations, and a system that has to keep working long after we leave it.

  • Regulated infrastructure
  • Payments and financial flows
  • Industrial and field operations
  • Platform and internal tooling
  • Data and integration estates
  • Legacy modernisation
  • Delivery into client-controlled environments
  • AI-assisted engineering
Capabilities

Four kinds of work.

Each of these is a different engineering problem with a different failure mode. We name which one you have before we propose anything, because the wrong classification is more expensive than the wrong framework.

01

Zero to one

Taking a system from nothing to working software, on a scope that is honest about what the first release actually contains.

When you need it

You have an opportunity, a date, and an unproven design. The risk is rarely writing the code. It is committing to the wrong scope and finding out late, when the date is close and the options are gone.

What the work covers

Discovery, requirements and invariants, architecture options with stated trade-offs, a tiered delivery assessment against the date, and the first release built and verified.

What you get

A release you can ship, the reasoning recorded as decision records, and an explicit statement of what was deliberately left out and what it would take to add it.

02

Reliability engineering

Making an existing system behave predictably under load, partial failure, and change.

When you need it

The system works until it does not. The same failures recur, recovery is manual, and nobody can state what the system actually guarantees. Incidents are being treated as events rather than as design feedback.

What the work covers

Failure mode analysis, timeout and retry semantics, idempotency, backpressure, degraded modes, reconciliation of effects that move value, observability, and recovery paths that are tested rather than assumed.

What you get

Stated guarantees, tests that assert them rather than chase coverage, and a system whose state, decisions, and failures can be interrogated in production.

03

Process design and implementation

Designing the engineering practice a team runs on, then putting it in place and showing that it works.

When you need it

Delivery is unpredictable, reviews catch the wrong things, and quality depends on who happened to pick up the ticket. Adding process has been tried and it slowed everything down without improving the outcome.

What the work covers

Work classification, the engineering sequence, decision records, review and verification gates, release and rollback planning, and the templates that carry them. Including how AI-assisted work is classified and reviewed.

What you get

A practice your team can run, sized to the work in front of it. On small changes the checking gets shorter. It does not disappear.

04

Complex system building

Building and restructuring systems with real boundaries: multiple services, shared state, external contracts, and data that outlives the code.

When you need it

The hard part is not the features. It is state ownership, compatibility over time, and the interfaces other people have already built against. There are no purely internal changes in a system this size.

What the work covers

Boundary and state-ownership design, schema and interface evolution, migration and rollout planning, threat modelling, and integration with systems you do not control.

What you get

A system whose complexity sits where you chose to put it, with the cost of that choice recorded, and whose changes do not break the people downstream.

The method

Every task is classified before it is built.

How much engineering a piece of work receives is a decision, not a habit. We classify the work as trivial, routine, substantial, or critical, then apply the sequence that classification calls for. Substantial and critical work follows all eight steps. Smaller work uses a compressed process, where the checking gets shorter rather than disappearing.

01

Understand the problem

Establish what is actually being asked, what already exists, and what the words in the brief mean in this system. Most failed builds are failures at this step.

02

Establish requirements and invariants

State what must be true, what must never be true, and how each will be verified. A requirement with no test and no stated reason for having none is not a requirement.

03

Analyse architectural trade-offs

Name the options, the criteria, and the consequences. There are no best answers here, only least-worst ones for the constraints you actually have.

04

Design boundaries and state ownership

Every piece of persistent state gets exactly one owning component that writes it and defines its invariants. Everything else goes through that owner.

05

Design for distribution, failure, and recovery

Assume every remote call times out, duplicates, reorders, or fails, and assume a crash between any two operations. Correctness has to survive both.

06

Implement with disciplined software design

Deep modules with simple interfaces, complexity pulled downward rather than pushed onto callers, and new code that follows the system's existing concepts or changes them deliberately.

07

Plan compatibility, release, and rollback

Old readers and old writers coexist with new ones during and after rollout. Versioning, migration, and deprecation are first-class work, planned before the first deployment.

08

Verify and review adversarially

Work is complete when it demonstrably satisfies its requirements and invariants and has survived a review designed to break it. Not when it compiles, and not when the author believes it is done.

The six non-negotiables

These do not flex for a deadline. If an engagement cannot accommodate them, we say so before it starts rather than after.

01

Financial effects are idempotent and reconcilable

Any operation that moves or commits value is safely retryable, exactly once in effect, attributable to a durable record, and reconcilable against an external source of truth.

02

State ownership is explicit

One owning component writes each piece of persistent state and defines its invariants. All other access goes through that owner, or through explicit replication with a stated consistency model.

03

Remote interactions handle failure

Every remote call can time out, duplicate, reorder, or fail. Timeouts, retries, and idempotency are designed in. A design that assumes a reliable network is wrong by construction.

04

Changes preserve compatibility

Schema and interface changes account for old readers and old writers coexisting with new ones, during and after rollout. Data outlives the code that wrote it.

05

Substantial work receives adversarial review

Anything introducing new state, contracts, boundaries, concurrency, or financial and security relevance is reviewed by someone trying to break it, against the stated requirements.

06

Requirements conflicts are surfaced

If the requirements turn out to be wrong, infeasible, or ambiguous, we raise the conflict and revise them explicitly. We never silently reinterpret a requirement into something easier to build.

Engagements

Discovery first. Always.

We do not quote a build from a brief. The first engagement is a short, paid discovery with explicit exit criteria, so both sides can decide on evidence instead of optimism. If discovery says we are the wrong firm for the work, that is a valid and useful result.

01

Discovery

A fixed-length review of the problem, the constraints, the existing estate, and the documents you already hold. It ends with a written analysis, a register of the open questions that decide the work, and a tiered delivery assessment against your date.

02

Design

Requirements and invariants, architecture options with stated trade-offs, boundaries and state ownership, threat model, and the decision records that explain why. Proposed decisions are proposals until you approve them.

03

Delivery

Implementation against the agreed scope, verified against the requirements and invariants rather than against a coverage number. Release, rollback, and compatibility are planned before the first deployment, not after it.

04

Handover

The system, its decision records, its tests, and the knowledge needed to operate it, delivered into your repositories and your environments. We plan to leave, and we plan for the system to keep working when we do.

Scope, commercial terms, and intellectual property are set per engagement in a written agreement. Nothing on this page is an offer or a fixed-price commitment.

Open source

Our engineering doctrine is public.

How we work is not a slide in a pitch deck. It is a published repository you can read, run, and hold us to. We also publish product work, so you can see the doctrine after contact with a real codebase rather than only in the abstract.

Public repositories
  • Paylo-One/engineering-constitutionEngineering doctrine · Licence Apache-2.0The doctrine itself: 25 durable engineering principles, the mandatory engineering sequence, work classification, an operational skill for each engineering discipline, and templates for requirements, system design, decision records, threat models, and production readiness.
  • Paylo-One/pilot.paylo-one.reactWorking product, TypeScript · Licence AGPL-3.0A working product built under the constitution: a multi-tenant application with connected data sources, background processing, and AI-assisted output. Read it to see the principles applied rather than described.
Read before you commit

You can audit how we work before you brief us.

Most firms ask you to take their engineering standards on trust. Ours are in public version control, with a full history of how they changed and why. Start with AGENTS.md for the sequence and PRINCIPLES.md for the reasoning.

Read the engineering constitutionBrowse the GitHub organisation

Client work is never published. Engagement material stays in your repositories and your environments, under the agreement that governs it. What you see here is our own work, licensed as each repository states.

Assurance

How we handle your code, your data, and your name.

Confidentiality and control are engineering constraints, not paperwork. These are the defaults we work under, before any client-specific agreement narrows them further.

Your environments, your repositories

Where an engagement calls for it, we deliver into your source control and your cloud accounts rather than our own. Intellectual property transfers on the terms your agreement sets, and we design for that from the first commit.

Client material stays client material

Documents you supply are preserved unchanged and hashed, and kept in a private working repository. Nothing about an engagement is published, reused as a reference, or named on this site without your written consent.

Least access, stated in writing

We ask for the narrowest access that allows the work, for the shortest period that completes it. Access is recorded, reviewed during the engagement, and removed when it ends.

Security is designed in

Trust boundaries, authentication, authorisation, data classification, retention, and abuse cases are settled at design time. Retrofitting them costs more and works less well.

AI assistance under the same rules

We use AI-assisted engineering, governed by the same classification and review gates as any other work. Client material is not used to train general models, and every output is reviewed by the engineer accountable for it.

Data protection by default

Paylo.One is established in the Netherlands and works under the GDPR. Processing roles, subprocessors, retention, and transfer safeguards are agreed in writing before any personal data is handled.

Questions

What clients ask first.

Direct answers, including where the answer is no. If your question is not here, ask it and you will get the same kind of answer.

How does an engagement start?

With a short, paid discovery that has explicit exit criteria. It produces a written analysis, the open questions that decide the work, and a tiered delivery assessment against your date. You own the output whether or not we continue together.

Do you take fixed-price work?

Not from a brief. A fixed price set before discovery prices the unknowns into a number one side will regret. After discovery, when the scope and the open questions are on paper, a fixed scope and price for a defined release is reasonable and we will quote one.

Can you deliver into our repositories and cloud accounts?

Yes, and we prefer it. Delivering into client-controlled source control and environments keeps ownership unambiguous, makes handover a continuous process rather than an event, and avoids the migration at the end that quietly costs the most.

What if discovery says the project should not go ahead?

Then that is what the report says. Discovery exists to make that finding cheap. We would rather lose a build than deliver one we know is scoped against requirements that will not hold.

Can we see your engineering standards before we commit?

Yes. They are public. The engineering constitution is on GitHub under Apache-2.0, with the full history of how it changed. Read it, challenge it, and hold us to it during the work.

Do you use AI in delivery?

Yes, under the same classification and review gates as any other work. AI-assisted output is still substantial or critical work when it touches state, contracts, or money, and it receives adversarial review accordingly. A human engineer is accountable for every line.

Who owns the intellectual property?

Whatever your agreement says, agreed before the work starts rather than argued after it. Where an engagement transfers IP on acceptance, we design the delivery arrangement around that from the beginning.

Where are you based?

Utrecht, in the Netherlands, registered with the Dutch Chamber of Commerce under KvK 42091728. We work with clients across Europe, remotely by default and on site where the work genuinely needs it.

Start with discovery

Bring us the system you are worried about.

Tell us what you are building or what keeps failing, what constrains it, and when it has to work. You will get a considered reply about what we think the real problem is, and an honest view of whether we are the right firm for it.

Email access@paylo.oneRead the engineering constitution

Paylo.One · Utrecht, Netherlands · KvK 42091728