Why we're building Mavenly in public — and what that actually means.

Building in public usually means posting revenue charts. That is marketing, not transparency — the numbers are selected, the trend is flattering, and nobody has ever posted a chart of the thing that is going badly.

For us the phrase has to mean something more specific or it is not worth using, so we wrote down four commitments and we would like to be held to them.

One: the roadmap is visible to customers, including the parts we have deprioritized and why. Deprioritization is the honest signal. Anyone can list what they intend to build; the useful information is what got cut and what tradeoff produced the cut.

Two: security posture is published before anyone asks for it. What data we store, where it lives, who on the team can access it, how long we keep it, what happens to it if we shut down. Organizations are putting their evaluations, budgets, board materials, and funder correspondence into our system. That is a large ask from a young company and it deserves more disclosure than the category norm, which is a trust badge and a marketing page.

Three: incidents get written up. Outages, data handling mistakes, model behavior that went wrong in a way that affected a customer's work. Short, factual, with what we changed. We have published these when they were embarrassing, which is the only condition under which the practice means anything.

Four: model behavior is documented in the product itself. What Maven drafts, what it refuses to draft, what it cites, and why the refusals exist. Not in a policy PDF nobody opens — in the interface, at the moment the refusal happens.

The underlying reason is trust asymmetry. When an organization adopts Mavenly, it takes on real risk: dependency, data exposure, and the possibility that a tool produces something inaccurate in front of a funder. We take on comparatively little. Disclosure is the cheapest way we have to move some of that risk back onto ourselves, because published commitments are expensive to break.

It also disciplines the work, which we did not fully anticipate. It is meaningfully harder to ship a shortcut when the reasoning has to be written somewhere a customer can read it. Several decisions have changed at the writing stage, not because someone objected, but because the explanation would not have survived being read out loud.

There are limits, and pretending otherwise would defeat the purpose. We do not publish customer names without permission, ever — a nonprofit's funding strategy is competitive information and several of our design partners would be materially harmed by disclosure. We do not publish security details that function as an attack map. And we do not publish specific revenue or headcount, because in a young company those numbers are noise that invites narrative.

What we will publish: what we shipped, what broke, what we learned from customers, and what we decided not to do. That is most of the interesting information anyway.

The Field Notes you are reading are part of this. They are not content marketing in the usual sense; several of them argue against features we could easily sell. We would rather be legible than persuasive, on the theory that in a category built on institutional trust, legibility eventually converts better.