How we work

Start with the operational boundary

The first conversation is about where the current workflow fails. We ask for a representative product, its known-good price or output, the systems that need to exchange data, and the step an operator still performs manually. Those examples expose constraints that a list of requested screens often misses.

A discovery engagement is appropriate when the brief cannot yet support a build commitment. It can produce an architecture, pricing-rule specification, integration inventory and phased plan. The output of a discovery engagement is written so that a supplier other than us can execute it. The plan should make the unknowns visible, including interfaces we have not inspected and samples we do not yet have.

Agree on observable acceptance

The default engagement is fixed-scope with written acceptance criteria and priced change control. Managed operations is a separate, opt-in agreement.

An acceptance criterion names an input, an expected result and a way to inspect it. A pricing engine can be checked against the client's known-good quotes. An output pipeline can be checked against specified geometry, colour intent and preflight rules. An integration can be checked for acknowledgement, retry and rejection behaviour. A page layout alone is not evidence that an order can be made and produced.

When new information changes the work, the scope is updated in writing. This prevents a technical discovery from silently becoming an unbounded promise.

Ownership and handover

The engagement contract is intended to assign the deliverables built specifically for the client after the applicable milestone is paid. On completion of an engagement the client owns the source code, the data schema and the documentation produced for them.

Pre-existing material used in a deliverable remains owned by its original owner, with a licence for the client to use and maintain it as part of that deliverable. Third-party components remain governed by their own licences. The dependency inventory identifies both classes. That distinction matters: a client can maintain an owned platform only if it knows what rights and dependencies came with it.

Every engagement ends with source code, schema documentation, a runbook and deployment instructions transferred to the client. The handover is assessed like any other deliverable, including build, test, deploy, rollback and recovery instructions.

Decide whether this route fits

If the product rules are standard and speed is the principal requirement, read when not to hire us. If the constraints need formal definition, the architecture and discovery service explains that scope. A project brief starts with one real example rather than an assumed solution.