Skip to content
M3T LabsEST. 2024

APPROACH

How we build.

This is how we build at M3T Labs, written down so you can hold us to it: how we pick our tools, how we test, and how we ship.

Principles

  1. Understand the problem, pick the tools.

    We start with the problem and choose the tools after. When a problem needs a technology we haven’t used, we learn it hands-on before designing with it. The less obvious answers come from knowing how it behaves in use. The aim is to extend what a person or a team does well, which usually rules out the flashiest option.

  2. New on top, proven underneath.

    We use new technology only where it earns its place, such as the model or a part nobody has built before. Everything under it runs on proven, durable tools. A new product on a fragile base is only a demo.

  3. Small, reversible steps.

    We ship often, in pieces we can undo. New features stay switched off until they are ready. Each release is small enough that when something breaks, the change behind it is easy to find.

  4. Evaluate before you believe.

    Every model and agent has a test it must pass before it meets a real user, and we write the test first. The test counts what the system misses, including failures nobody sees and cases it was never shown. A classifier that misses more than its written limit isn’t done. After launch we keep checking each model, because the world changes and a model doesn’t notice.

  5. Safety is designed, not bolted on.

    Ways to report, appeal, get notice and check the record belong in the first version, not added later.

    Safety, in full

  6. Think about the person.

    We write for someone new to the product: plain words, an obvious next step, and accessibility handled as part of the build.

    Accessibility, in full

  7. Honest about the AI.

    When something we build is AI, it says so, in the interface, in plain words. We don’t present it as a person, and we don’t hide what it can’t do.

How we ship.

We track the four DORA delivery measures: how often we deploy, how fast a change reaches users, how often changes fail, and how fast we recover. They reward small, frequent releases. New work goes into one main line, switched off until it is ready. Every change must pass type checks, automated tests, a build and browser tests before it merges. Every launch gets a written plan, and each review of a failure leads to a change.

How a build runs.

Toussaint does the engineering. Before any code exists, he sets the specification and the tests it has to pass. The work goes one small, defined piece at a time, each result is checked against the specification, and anything that falls short goes back. He decides what ships, and every release goes through evaluation, safety, and accessibility reviews.

What we won’t do.

We won’t ship features for growth before a way to report a problem. We won’t imply an AI is a person. We won’t publish a claim we can’t demonstrate. We won’t collect data without saying what it’s for. And we won’t take on work whose success depends on people not understanding what it does.

See the method in the work, or ask about it.

The work Talk to the studio