Skip to content
Menlo·Labs

1140 Doyle Street, Suite 4

Menlo Park, California 94025

Mon–Thu, 09:00–18:00 PT

EST. MMXIX — Menlo Park, California

Software thatknows what it isdoing.

Menlo Labs Studio is five people who build instrumented software — control-room interfaces, narrow machine-learning systems, and visualization for teams that live inside their tools twelve hours a day.

We take three or four engagements a year, staff them with the people you met in the pitch, and plan our own exit from the first week.

Selected workStart a project
Interface engineeringApplied machine learningInstrumentationData visualizationDesign systemsTechnical diligenceEdge deploymentOperator researchInterface engineeringApplied machine learningInstrumentationData visualizationDesign systemsTechnical diligenceEdge deploymentOperator research

§ Position

Most software for professionals is designed for the day it is demonstrated, not the ten thousand hours after. We work on the ten thousand hours.

That means we care about the tenth hour of a shift, the fourth interruption, the reading that is ninety seconds stale. It means we measure what happened after launch and report it even when the number is unflattering.

It also means we say no more than a consultancy our size probably should. If an engagement wants a rewrite where a three-week repair would do, we will tell you, and we will tell you before the contract.

§ Selected work

Six of eighty-three

Full index →

§ Capabilities

A

Interface engineering

Production front-end for software people use all day. Keyboard paths, dense data, states that actually exist.

  • React & TypeScript
  • Design systems
  • Accessibility to WCAG 2.2 AA
B

Instrumentation

Telemetry that answers a question you wrote down beforehand, rather than a dashboard nobody opens twice.

  • Event modeling
  • Session analysis
  • Operator research
C

Applied machine learning

Narrow models aimed at one measurable job, deployed where the work happens — often on hardware, often offline.

  • Edge inference
  • Labeling programs
  • Evaluation harnesses
D

Data visualization

Charts and maps built to be defended in a meeting. Uncertainty shown, not smoothed away.

  • Cartography
  • Real-time views
  • Print-safe palettes
E

Technical diligence

A two-week read of a codebase and the team around it, written for people who will not read the code.

  • Architecture review
  • Risk register
  • Hiring guidance

§ How an engagement runs

Four phases, and the last one is leaving.

Every phase ends in something you own outright — a document, a deploy, a runbook. Nothing about the arrangement requires us to still be here next year.

  1. 01

    Survey

    1–2 weeks

    We sit where the work happens before we propose anything. Fixed fee, and it ends in a written document you own whether or not you hire us again.

  2. 02

    Prototype

    2–4 weeks

    One narrow slice, built for real and put in front of the people who will use it. We are looking to be wrong early and cheaply.

  3. 03

    Build

    6–14 weeks

    Two-week cycles, a working deploy at the end of each. Your engineers are in the repository from the first commit, not the last.

  4. 04

    Hand-off

    2 weeks

    Runbooks, recorded walkthroughs, and a named owner on your side. We plan our own exit at the start of the engagement.

§ Next

Tell us about the
tenth hour of the shift.

Send a paragraph about the work and who does it. You will hear back from Tomás or Junia within two business days — from a person, with questions.

Start a project