A developer-tools company of JetBrains' shape has six security engineers for 200 developers shipping desktop IDEs, a plugin marketplace and a hosted build service. It replaces mandatory pre-launch security review with a self-service threat-modelling questionnaire plus a trigger list, keeping deep review for triggered changes. What has it given up, and when does that bill arrive?

What the change buys

The arithmetic is why this happens. Six engineers who can each run two useful design reviews a week have a ceiling near 50 reviews a month, and a request rate above roughly 80% of that ceiling makes queueing time grow faster than the queue — the same behaviour as any saturated server. At 40 design changes a month the queue is bearable; at 70 the median wait to start a review was nine days, which is long enough that teams stop asking.

Self-service converts most of that demand into a form the team fills in itself. Lead time falls to a day and the review team's attention moves to the changes that were chosen deliberately rather than the ones that arrived first. That is a real gain, not a compromise.

What it pays

A questionnaire can only find what it already knows to ask. It encodes last year's threat model. The changes that hurt are the ones that create a trust boundary nobody has seen before: a plugin marketplace that starts executing third-party code inside the IDE process, a build service that lets a customer's pipeline reach an internal artifact store, a licence server that begins holding customer telemetry. Those are exactly the cases where every question on the form is answered honestly and the answers are irrelevant.

Three more costs, in the order they show up:

• Drift. Nobody owns the question set, so it ages. A question set older than two release cycles is describing a product that no longer exists.
• Gaming. When a "yes" triggers a two-week review, the answer becomes "no". This is not dishonesty; it is the incentive the design created.
• Loss of the corridor conversation. Much of a review's value was a senior engineer saying "why is that service talking to that one at all". A form never asks that.

When the bill arrives

Not gradually. It arrives at the first architecture the form did not anticipate, and it is discovered either by an external researcher or by an incident. The interval is typically a year or two: long enough that the throughput win has been celebrated and the review team has been resized to the new load.

Keeping the option to reverse

• Mandatory triggers that are structural, not cost-based: a new trust boundary, a change to authentication or signing, anything crossing tenant isolation, anything that makes an internal service reachable from customer-controlled input. Cost thresholds get gamed; "are you creating a new place where untrusted input meets trusted code" does not.
• Sample the self-served route. Review one in five completed questionnaires anyway, chosen randomly. Track high-severity findings per review on the sampled route against the triggered route. If the sampled route is producing comparable findings, the triggers are wrong and you have the evidence to change them.
• Give the form an owner and an expiry. Each question carries the incident or finding that justified it. Questions whose justification no longer exists are deleted, which keeps the form short enough to be answered honestly.

When not to make this trade

When the blast radius of one mistake is the whole business and the volume is low: a payment processor's core authorisation path, a signing key service, a product handling health data for a regulator. Below roughly one design change a week per reviewer, the queue never forms and self-service solves a problem you do not have. The questionnaire is for organisations whose demand genuinely exceeds their review capacity, and the honest version of the trade is that you are choosing which failures you will find late.