MR.
CASE STUDY · 04 / 04
SECURITY PRODUCT · IN DEVELOPMENT

SMB.

Enterprise-grade security for the company that does not have a security team.
ROLE
Founder · Sole engineer
PERIOD
2026 — alpha Q4
STATUS
In development
READ
≈ 5 min
CHAPTER 01
THE BRIEF

The middle of the market is where security stops working.

A ten-person company can install antivirus and call it a day. A two-thousand-person company has a SOC. The two hundred companies in between have neither — and they are the ones being phished, ransomed, and silently breached.

The product gap is real and well-documented. Tools built for individuals do not understand multi-user environments, role boundaries, or compliance evidence. Tools built for enterprises assume a security team exists to operate them. The mid-market gets sold the enterprise tool, fails to operate it, and ends up with an expensive dashboard nobody reads.

I have spent the last year talking to founders, ops leads, and the occasional accidentally-promoted "head of IT" at companies in this band. The conversation always ends the same way: we know we should be doing more, we do not know what, and we cannot hire someone who does.

This product exists for the person on the other end of that conversation.

CHAPTER 02
THE APPROACH

One backend. Three views of the same truth.

The mistake every product in this space makes is building one dashboard for one persona. The CEO opens it, sees a wall of CVEs, and closes it. The engineer opens it, sees a marketing summary, and closes it. The auditor opens it, finds no evidence, and asks for a spreadsheet.

The same data has to answer three different questions. What should I do today? for the engineer. Are we okay? for the executive. Can you prove it? for the auditor. The product collapses these into one backend that emits three views, each tuned for the question its reader is trying to answer.

Setup is the hard problem. The engineer wants control; the executive wants it done; the auditor wants a paper trail. The default install is a single OAuth flow against the company's identity provider, a one-click connection to the cloud accounts, and a sensible baseline that explains every choice. Power users can override anything. Nobody has to.

FIG. 01 · ONE BACKEND, THREE VIEWS
IDENTITY PROVIDER CLOUD ACCOUNTS DEVICE FLEET SAAS APPS UNIFIED MODEL CONTROLS · EVIDENCE · RISK ENGINEER VIEW QUEUE · ROOT CAUSE EXEC VIEW RISK · TREND · DELTA AUDITOR VIEW EVIDENCE · TRAIL
"A security product the CEO does not understand is a security product the CEO will not pay for."
CHAPTER 03
FROM DISCOVERY

What the conversations keep returning.

A few dozen interviews into the discovery process, the same set of constraints keeps showing up. None of them are about the technology. All of them shape the product.

D.01 · NO DEDICATED OWNER

Security is the third hat on someone's head.

Almost always the head of engineering, sometimes the founder, occasionally an external MSP. Whoever it is, they have ten minutes a day for this — not ten hours.

D.02 · COMPLIANCE FORCES THE BUY

SOC 2 is the wedge, not the goal.

Few of these companies wake up wanting better security. They wake up wanting to close the next enterprise deal, which requires a SOC 2 letter, which requires the work. The product has to make that path obvious.

D.03 · TOOL FATIGUE IS REAL

Three dashboards is two too many.

Every company I spoke to has at least one half-deployed security product they pay for and do not use. Adding a fourth is a non-starter. Replacing two of them is a compelling pitch.

D.04 · TRUST SCALES WITH EXPLAINABILITY

Why this finding, why now.

A non-engineer reading the report wants to understand what they are looking at. Findings without a one-paragraph explanation get ignored. Findings with one get fixed.

CHAPTER 04
THE FIRST THIRTY MINUTES

What setup actually looks like.

The product earns or loses the customer in the first session. If the engineer has not seen real, specific findings about their own infrastructure within thirty minutes of signup, they will close the tab and never come back. The onboarding is built around that constraint.

OAuth into Google or Microsoft. Connect AWS, GCP, or Azure with a read-only role. Let the agent pick up the device fleet from the existing MDM. The first scan finishes inside fifteen minutes. The first report is in the engineer's hands inside twenty.

smb · onboarding state · simplified
# the user-facing checklist that drives the first session
step 1  connect identity provider      ▮ done · 2m
step 2  connect cloud accounts          ▮ done · 4m
step 3  link mdm (optional)             ▮ done · 1m
step 4  baseline scan                   ▮ done · 11m
step 5  first report ready              ▮ done

# first report · summary line
17 findings · 2 critical · 6 medium · 9 informational · evidence: 41 artifacts
CHAPTER 05
WHERE IT STANDS

Alpha in Q4. Slow on purpose.

The product is mid-build. The unified model is working against a small set of integrations; the three views are wireframed and the engineer view is in code. The closed alpha opens in Q4 2026 with five design-partner companies who agreed to use it as their primary security product for a quarter and tell me everything that is wrong with it.

The cadence is intentional. A security product that ships fast and breaks often is a security product that loses customers permanently. Every release path through the product is treated as a trust contract — the kind of release that erodes confidence in week three is worse than a release that takes three weeks longer to land.

The thesis is simple. The mid-market does not need a smaller version of an enterprise SOC. It needs a different shape of product entirely — one that respects how little time the operator has and how much the work matters anyway. That product does not exist yet. This is an attempt to build it.

— END OF REPORT —