Taking Mappa from First Commit to Production

The model was never the whole Mappa product. The real product was the durable loop around it: accept an input, carry it through long-running analysis, evaluate the result, and present it carefully to a person making a consequential decision.

I co-founded Mappa in 2023, served as CTO until May 2026, wrote the first commit, and remained its largest code contributor; an NDA prevents me from discussing customers, private data, internal schemas, proprietary matching methodology, workflow definitions, or the evaluation corpus, so this account stays with public architecture and decisions.

Mappa began with a simple question. A résumé lists experience but reveals little about how someone communicates, responds to pressure, or works with others. Could voice analysis make some of those less visible signals useful in hiring? Mappa publicly describes extracting vocal markers from an audio sample and mapping them across behavioral traits.

On paper, the path was short:

voice → analysis → behavioral structure → useful human output

Each arrow hid a production boundary. Audio had to arrive in a usable form. Analysis had to outlive a normal request. Model output had to become data we could validate, persist, and render. The report had to help without implying more certainty than the analysis supported.

A demo can run once with clean input and print plausible prose. A production system receives overlapping work from people waiting for an outcome. Providers slow down, inputs are malformed, and deploys interrupt processes. The state cannot live only inside whichever process happens to be handling it.

We represented long-running work as explicit, durable stages. That did not remove failure; it made failure legible. A named stage could distinguish work that never started from work that ran and produced an invalid result. The system could record whether another attempt was safe, then retry, wait, or stop. This mattered when repeating expensive analysis could duplicate work.

For example, work that never began could be attempted safely; work that completed analysis but produced invalid data required a different response. Treating both as the same failed request would either abandon recoverable work or repeat expensive work without knowing what had already happened. Durable stage state preserved the distinction after the original process was gone.

Durability was not free. Every stage created another state the team had to understand, and retries could turn a provider outage into accumulating work. We accepted that cost where a stage made a real failure easier to locate or recover from. Our volume did not need to be hyperscale to expose assumptions that only survive in demos.

Fluent language is not necessarily usable output. Hiring teams did not need a transcript of a model thinking aloud, and downstream software could not safely consume an unbounded chat response. We needed an artifact structured enough to validate, store, render, and reason about.

Structure solves only shape. A valid object can still be misleading, inconsistent, or wrong for the task. Evaluation had to address behavior. My public experience record states that our agent workflows were gated by hundreds of evaluation cases. The important part was the gate: a case could prevent a consequential behavior change from reaching customers.

Probabilistic output makes good anecdotes dangerously persuasive. Two responses can both sound polished while one violates a requirement. A prompt or model change can improve one class of result and quietly damage another. Stable cases gave those tradeoffs somewhere to appear before customers discovered them.

Evaluations became the acceptance boundary for changes to consequential output. They did not make the system deterministic or reject every harmless variation. They gave us a repeatable way to decide whether new model behavior was acceptable for the product. A result that passed schema validation but failed an evaluation was different from a malformed result, just as both were different from a network interruption. Preserving those distinctions kept recovery and product judgment from collapsing into the vague category of “AI failure.”

A faster analysis step was still a regression if the report weakened or established cases failed.

Hiring software can affect consequential human decisions. Engineering therefore continued through the handoff from structured output to human interpretation.

Mappa's public framing is compatibility rather than declaring traits inherently good or bad. In a TechCrunch profile, CEO Sarah Lucena said, “We don’t really categorize traits as good or bad. We understand traits as compatible or not.”

A polished report may help someone ask better questions. It can also imply certainty that the underlying signal does not support. Careful analysis could not rescue an interface that rendered an estimate as fact. The product had to consider what a result invited someone to conclude and whether the interface supported a decision or substituted for one.

The report was where probabilistic output became a hiring decision, so that handoff remained part of the engineering.