Most product decisions look like luck from the outside. Here are ours, before the outcome was known.
A page about the actual frameworks we use — build vs buy, hire vs contract, ship now vs wait, customer-driven vs founder-driven — and three real decisions we made in the last six months, with the reasoning we wrote down at the time. Two of them turned out right. One is still being argued about. That's the point.
Slow on entry. Fast on reversal.
Every decision we make is rated on two axes that have nothing to do with cost or upside: how reversible is it, and how much information do we have right now. If a decision is hard to reverse, we slow down before making it. If it turns out wrong, we move fast to undo it. The first half is easy to write down. The second half is the part most teams get wrong.
The reason most companies don't reverse decisions even when they should is that the decision becomes someone's identity. The person who pushed for it has to lose face to undo it. So we made a small structural choice early: nobody owns a decision after the meeting ends. Whoever championed it doesn't carry the social cost of unwinding it. We unwind it because the evidence changed, not because someone was wrong.
This is also why we write decision notes — not for documentation, but for ourselves. When we look at a six-month-old note and the reasoning still holds, we leave the decision. When the reasoning doesn't hold, we change it. The note is the evidence trail; the meeting is just where the trail started.
Build vs buy.
The default in most startups is "build it ourselves, it'll be faster." This is almost always wrong in the first eighteen months and almost always right after. The question isn't speed; the question is whether the thing you're building is on your critical path to a moat.
- It's commodity infrastructure. Email send, OAuth, observability — table stakes, not differentiators.
- A vendor exists with three years of incident history and we'd recreate the same incidents.
- Building it would consume an engineer for > 6 weeks and the result is at best parity.
- The cost is a known monthly number we can predict against revenue.
- It touches our actual moat. Anything that handles raw signal data, model orchestration, or research generation — we own end-to-end.
- The vendor has roadmap risk against us (will they enter our category?).
- We need iteration speed measured in days, not quarters.
- The behavior we want is so specific that vendor customization will cost more than the build.
We get this wrong about a third of the time. Usually we build something we should have bought, because building feels like progress and writing a check feels like admitting we couldn't. The check is almost always correct.
Hire vs contract.
We've kept the team deliberately small. Eleven people as of May 2026, growing to roughly fifteen by year-end. Every additional headcount is the most expensive ongoing commitment a startup makes — not because of salary, but because of the meetings, the onboarding, the reporting structure, the slow erosion of high-bandwidth communication.
- The work has a defined endpoint — a launch, a redesign, a migration.
- We need a specialist for < 6 months of full-time equivalent.
- The work is adjacent to our core but not on the daily critical path.
- We can scope it in writing and tell when it's done by looking at the artifact.
- The role creates more roles — it scales the team's output, not just adds one unit.
- The work is open-ended and the right answer changes with context only an insider has.
- We'd want this person in the room when we're rewriting the strategy a year from now.
- The cost of being wrong about this hire is recoverable in < 90 days.
Our brand work, our website illustrations, our annual security audit, and most of our marketing video work is contracted. Engineering, product, design system, customer-facing roles, and anyone who handles the model layer are W-2.
Ship now vs wait.
The bias inside the building is always to ship. The bias outside the building should be a customer's right to ignore us. So the question we ask before any release isn't "is this ready?" — it's "if a customer never hears about this, are we proud of what they encounter when they bump into it?"
- The worst-case experience is "this feature isn't useful yet" — not "this gave me wrong data."
- We can roll it back in < 30 minutes without affecting other customers.
- The feedback loop from real users is faster than the feedback loop from internal testing.
- Three customers have asked for the thing in three different words.
- It writes to a customer's CRM, sends on their behalf, or surfaces a claim with a confidence number.
- Rollback requires a migration or a customer-side change.
- The data shown could be wrong in a way the customer can't detect — and a wrong claim costs them a deal.
- We caught a bug in staging that we don't fully understand the root cause of yet.
Customer-driven vs founder-driven.
There's a recent fashion to build only what customers explicitly ask for. There's an older fashion to build only what the founders believe in regardless of feedback. Both, taken alone, kill companies. The skill is knowing which mode you're in for which question.
- Workflow ergonomics. How the product fits inside an existing day — keyboard shortcuts, CRM field mapping, sequencing rules.
- Integration surface — who we integrate with next.
- Error messages, empty states, the language used in the UI.
- Pricing structure and packaging.
- What the product is for. The thesis — that signal-first outbound beats volume-first — was set before our first customer.
- What we refuse to do (see /anti-patterns).
- The tone and visual identity. We're not going to A/B test a font.
- The metrics we publish on /open.
Three real decisions. Reasoning before the outcome.
Frameworks are easy to write. Here are three actual decisions we made and what we wrote at the time. Two have outcomes now. One is too early to call — we'll update this page when we know.
What we won't decide quickly.
Most of this piece is about how to move faster on the right things. Just as important is the list of things we won't move fast on, period. These are the decisions where the cost of being wrong is asymmetric — the upside of speed is small, the downside of a mistake is large or unrecoverable.
Everything not on the slow list is on the fast list. Default to motion, default to writing the reasoning down, default to changing course when the evidence changes. That's the whole game.
You're either deciding whether to work with us, deciding whether to work at us, or wondering how we operate.
All three are reasonable. The fastest way to find out whether our decision-making actually shows up in the product is to use it for two weeks. The fastest way to find out whether it shows up in the people is to talk to us.
If you disagree with any of the four frameworks — or have a candidate for a fourth real decision we should be writing up — write back. We update this page whenever the call deserves it.