How a project with Mytrya runs

A project runs in four steps: a free scoping call, a written spec with a fixed price, a build you watch in dry-run every week, and a handover into your own repositories with documentation and a runbook.

Fixed scope and fixed price means the number doesn’t move once we’ve agreed the spec. If the spec changes, we write down the change and the new number before anyone builds it.

The four steps

  1. 01

    Scoping call

    Thirty minutes, free. You describe the process: what it is, who does it, how often, what goes wrong when it's late. I ask about the systems it touches and what documentation exists.

    Sometimes the answer is that it isn't worth automating yet, or that writing the documentation is the better first project. I say so on the call.

    You get

    A yes, a no, or a smaller first project.

  2. 02

    Written spec and fixed price

    A short document: what the system will do, which systems it reads and writes, what it will not do, how we'll know it works, and what it costs. You review it. We change it until it's right.

    You get

    A spec you can hold me to, and a price that doesn't move.

  3. 03

    Build, with weekly dry-run demos

    Every system I build has a dry-run mode from the first week. Each demo shows the real system running against real data and writing nothing. You see every action it would take before it's allowed to take it.

    Integrations go live one at a time, each behind its own flag.

    You get

    A working system you've watched rehearse.

  4. 04

    Handover

    The code lands in your repositories and runs in your cloud accounts. You get documentation, a runbook for when it misbehaves, and a walkthrough with whoever will own it.

    After that, ongoing tuning is an optional retainer. Many systems don't need one.

    You get

    A repo, a runbook, and a system your team can run without me.

What handover includes

  • The code, in your GitHub or GitLab organisation, with history
  • Deployed in your cloud accounts: Vercel, Cloudflare, AWS, or wherever you already are
  • A README that gets a new engineer running locally in under an hour
  • A runbook: what to check when it misbehaves, how to turn each integration off, who to call
  • The dry-run console, so your team can rehearse changes before shipping them
  • A recorded walkthrough with whoever will own it

After handover

Ongoing tuning is an optional monthly retainer. It covers monitoring, model and dependency updates, and small changes. Many systems don’t need one; the runbook is written so that yours might not.

Fixes for anything that doesn’t match the spec are included, for as long as the spec is the spec.

Rules every system is built under

7

  1. 01

    Dry-run is the default

    Anything that can write to a system ships with a mode that shows the full trace and writes nothing. That mode is on until you turn it off, one integration at a time.

  2. 02

    Grounded or escalated

    An agent may state what it retrieved and cite where it came from. It may not approximate. When there is nothing to ground an answer in, escalating to a person is the correct output.

  3. 03

    Numbers are computed, not generated

    Counts, medians, returns and thresholds are computed in code where a test can check them. Models describe and classify. They don't add up.

  4. 04

    Read the structure that already exists

    Scripts have scene headings, tickets have fields, boards have columns. Parsing them is exact and free. Asking a model to infer them costs the whole document and returns a guess.

  5. 05

    Cost is part of the spec

    Caps per window, shared in-flight requests, and work deferred until someone actually opens the page. A system whose bill grows with curiosity gets switched off.

  6. 06

    Assume the source will disappear

    Rate limits are measured, not assumed. The old path stays as a fallback. An unexpected response shape is treated as an outage and reported, never interpreted as data.

  7. 07

    Identifiers come from context

    Ticket IDs, account IDs and record keys are read from the assembled context, never from model output. A hallucinated ID has nowhere to go.

Next step

Ready for step one?

The scoping call is free and takes about thirty minutes. Bring the process, not a solution.

Start a project How a project runs

Free 30-minute call · one working day