JMS Dev Lab

Labs

A very small team can build and look after many products if the routine work is planned, checked and watched by software, and a person approves what matters. These are the tools we use to do that on our own apps.

Lab notes

  • Command centre

    One place that shows whether every one of our products is healthy, who is really using them, and what they earn.

    Today
    Checks the health of all 15 of our products on a schedule, counts real users with our own test accounts filtered out, and reads revenue from the payment providers rather than from the apps themselves.
    What we learned
    A dashboard is only useful if each number comes from its source. Test accounts and self-reported figures make a product look healthier than it is.
    Status
    In daily use on our own products. Not available to other teams yet.

  • Development harness

    A set of AI agents that plan, write and review changes to our apps, each in its own isolated copy of the code, under written rules and a daily budget.

    Today
    Runs supervised work on our own repositories. Changes pass tests and checks before they are released.
    What we learned
    An agent saying a job is done is not proof. Each change needs an independent check, such as tests or a live check, before it counts.
    Status
    Internal. We are working on how other teams could run it safely.

  • Software design process

    A written process from research to retrospective, with checks in code that stop a plan going ahead when parts are missing, such as acceptance criteria, a test plan or a way to roll back.

    Today
    First version written on and built into our harness on .
    What we learned
    Checks only help if every stage feeds the next one. Gaps between stages are where work quietly stalls.
    Status
    Internal. The written process may be the first thing we publish.

How the three fit together

The design process says what a good change looks like. The harness does the work and has to show evidence at each stage. The command centre watches what happens once it is live, and what it finds becomes the next plan.

How the Labs tools connect Design process leads to the development harness, which leads to the command centre; findings from the command centre feed back into the design process. Design process 13 stages, each with a check Development harness Agents plan, build, review Command centre Health, users, revenue What we find in production becomes the next plan

The thirteen stages of the design process

  1. Requirements, with acceptance criteria on every step
  2. Design document and decision records
  3. API contract first
  4. Test plan that covers every acceptance criterion
  5. Small, bounded changes
  6. Tests run for real
  7. Independent review by a different agent
  8. CI gates on the exact change
  9. Verification on real systems
  10. Documentation changed with the code
  11. Release checklist and rollback plan
  12. Post-release check
  13. Retrospective with lessons and a regression plan

Interested?

None of this is for sale yet. If your software team would like to hear when it is, or to compare notes on building with AI agents, send us a line about your team.

Email us about Labs

We reply within one working day, in writing.