Know how the work runs before you commit to it.

• A complete product to build: scope, interface, backend, integrations, deployment and handover, owned end to end.
• An existing product with a part that is blocking the rest, where the blocking part reaches below the application layer.
• An AI or automation surface that has to survive real use: tool boundaries, evaluation, and a defined path when it fails.
• Internal tools and operational software that a business genuinely runs on, rather than a proof of concept.
• A rebuild where the current system is understood well enough to say what must survive it.

• The problem, not the solution

  What is broken, slow, blocked or missing, described from the outside. The proposed fix is useful later; the constraint is what the scope gets built from.

• Who operates it

  Who uses the system and what they are trying to finish. A product surface designed without that is a guess with a design system on top.

• What already runs

  The current stack, where it is hosted, and what cannot change. Existing constraints shape architecture far more than preferences do.

• The real deadline

  Whatever is actually driving the date: a launch, a contract, a migration, an audit. A date with a reason behind it can be planned against.

• Access and compliance limits

  Anything that governs who may touch production, where data may live, and what has to be signed before work starts.

• How the decision gets made

  Who signs, what budget range is realistic, and what else is being evaluated. It shortens everything that follows.

You can also read it directly. The four models are set side by side on the services page, and the seven steps from first contact to handover are further down this one.

This is the path an engagement follows, published as the commitment being made rather than summarised after the fact. It is the process you would be holding us to.

1. 01

   Contact

   A brief or a call. The brief suits a settled scope; the call suits a problem still taking shape. Either reaches the person accountable for scoping the work.

2. 02

   Discovery

   One or two working sessions on constraints rather than features: what runs today, where it hurts, which risks matter first, and what must be true at the end. No commitment on either side yet.

3. 03

   Written scope

   The problem as understood, what will and will not be built, the stages, the assumptions it depends on, and the acceptance criteria for each stage. Nothing is billed until this is agreed, and if it shows the wrong company is holding the work, it says that.

4. 04

   Proposal

   The scope priced against one of the engagement models, with the payment schedule, the assumptions that would change the number, and what is explicitly out. A price quoted before the scope is understood is a guess wearing a suit.

5. 05

   Build in stages

   Work ships in reviewable increments against the agreed scope. Each stage lands something usable and is checked against its acceptance criteria, rather than accumulating toward one drop at the end.

6. 06

   Acceptance

   A stage is done when it meets the criteria written down for it, not when it is declared done. Anything that fails acceptance is fixed inside the stage, and anything found that was never in scope becomes an explicit decision rather than quiet extra work.

7. 07

   Handover

   Source in your repositories, infrastructure in your accounts, architecture notes, runbooks, the decisions and the rejected alternatives, and the known limitations. The test is whether an engineer who was not on the build can pick it up without a negotiation.

• Written by default

  Progress, decisions and blockers in writing, on a rhythm agreed at kickoff. Calls are for the things writing is bad at: disagreement, ambiguity, and design.

• A scheduled checkpoint

  One regular call in your timezone, plus whatever the work needs. The checkpoint exists so that a problem is never waiting for the next status report.

• Stage review

  Each stage is reviewed against its acceptance criteria as it lands, so quality is checked continuously rather than discovered at the end.

• Decisions recorded

  Architecture decisions are written down as they are made, with the alternatives that were rejected. That record is part of what you are paying for.

• An NDA can be signed before any detail is discussed. Send yours, or ask and a mutual one is provided.
• You own the code and the IP produced under the engagement. That is stated in the engagement document, not assumed.
• Access is least privilege and scoped to the work in hand, requested per system rather than granted broadly at kickoff, and handed back at the end.
• Credentials stay in your secret store. Never in source, never in a chat thread, never in a ticket.
• Infrastructure runs in your accounts and source lives in your repositories, so revoking access is something you can do without asking.
• Where a build genuinely needs a specialist, that person is named during scoping, approved by you, and scoped to that part of the project under the same NDA and access rules. No outsourcing, no agency handoff, no marketplace pass-through, and one accountable owner throughout.
• Invoicing is per milestone against the agreed schedule, in your currency where the payment rails allow it.
• Remote-first and global. Working hours overlap is agreed at kickoff rather than assumed.

• Work priced primarily on being the cheapest option. The engineering that makes a system last does not survive that constraint.
• A fixed price against a scope nobody has written yet. Scoping comes first, and it is a real piece of work.
• Staff augmentation by the hour with no defined outcome, where the engagement is a seat rather than a result.
• Anything that needs a deadline the scope cannot support. A date that can only be met by skipping the parts that make it hold is not a date worth agreeing.
• Work where nobody on your side can make a decision. An engagement without a counterpart who can say yes stalls at the first fork.

• PageTrust and dataThe vendor-review answers: the sub-processors behind this site and what each one holds, how long a submission is kept, and the registered entity details an onboarding record asks for.
• PageSecurityThe engineering behind the commercial rails: least privilege, where credentials live, what an agent or integration is permitted to touch, and how to report a vulnerability.
• DocumentsSample artifactsThe documents named just above, published as real formats: what each one records, when in the sequence it lands, and the risk it removes.