Request an audit: post your scope here

The demand-side template — the mirror of the auditor introduction thread. Makers: post your audit request as a comment here (or its own thread if substantial) in this format, and auditors from the intro thread respond. The format exists because "how much for an audit of my app?" is unanswerable, and the thread history above proves scoped requests get real quotes.

The template

• App in one paragraph: what it does, for whom, roughly how much traffic/revenue (ranges fine — this calibrates stakes, per the transition-of-stakes timing in the cost thread).
• Architecture sketch: stack, hosting, model provider(s), whether the model has tools or retrieval, multi-tenant or not, payment handling. Five lines, honest.
• Surface inventory: approximate route count, integrations, webhooks, anything public-facing you're unsure about. "I don't fully know my surface" is an acceptable line — it becomes part of the scope (see the route-inventory reply in the checklist thread).
• What you want examined: pick from the layers in "What a code audit for an AI app actually covers," or say "auditor's judgment" — also a legitimate answer.
• What you already have: tests/CI, prior reviews, the security one-pager, dependency scanning. This is your discount lever (preparation compresses engagements — cost thread).
• Constraints: budget range, timeline, and whether you need the report shaped for a specific reader (a buyer, a business customer's questionnaire, your own roadmap).
• Contact: how auditors should reach you for the parts that shouldn't be public.

Rules for this thread

Quotes and clarifying questions happen in replies or DMs — either is fine, but terms stated publicly (a range against a scope) help every reader calibrate, which is half this category's value. Auditors must link their intro thread in any response (the conflicts rule, mechanically applied). And when your engagement completes, come back and report: what it cost, what it found (in classes, not exploits — don't publish your open vulnerabilities), and whether you'd rehire. Outcome reports are the price transparency and the auditor accountability, in one comment.

One honest note while the community is young: auditor supply here may lag maker demand at first. If your request sits unanswered, the cost thread's DIY tier and the checklist thread are your meanwhile — and tell us, because unmet demand data is exactly what recruits the next auditor to the intro thread.

First requests below. Who's got a scope?

AXIS Editorial

A worked example of the template, so the first real request doesn't have to go first — this is an illustration, not a real engagement:

App: invoice-extraction tool for bookkeepers; ~200 users, low four-figure MRR. Architecture: TypeScript/Postgres on a managed platform, one model provider, retrieval over user-uploaded PDFs, no tools, Stripe. Multi-tenant. Surface: ~25 routes, Stripe + email webhooks, a legacy /export endpoint I'm unsure about. Want examined: injection surface on the PDF path, tenant isolation, billing gates; auditor's judgment beyond that. Have: CI with dependency scanning, AI-written tests, security one-pager. Constraints: $4-6k, report readable by a future acquirer, 3-week window. Contact: DM.

Note what the example does: stakes in the first line, the scary parts confessed (legacy endpoint, uploaded-PDF retrieval), the discount levers listed. An auditor can quote this without a single clarifying call — that's the bar.

AXIS Editorial

Follow-up from maker intake: "Should I get one quote or several? Multiple engagements feel wasteful but one quote feels blind."

Multiple quotes, one engagement — quotes against a written scope cost providers little and you nothing, and the cost thread's comparison discipline ('what would you cut at $X?') only works with 2-3 to compare. Where duplication does make sense, it's sequential, not parallel: a different reviewer for your next engagement a year on, because fresh eyes on previously-reviewed code catch what familiarity smooths over — the human version of the shared-blind-spot argument in the AI-testing thread. Same-scope parallel audits are an enterprise assurance pattern; at solo scale that budget buys more security as one engagement plus a re-test plus next year's different reviewer.

Jonathan (AXIS Launch)

On posting security details publicly, since the template walks a line: the scope level in the worked example — architecture shape, surface counts, what worries you — is safe to publish and is exactly what quoting requires. What stays out of public threads: specific unpatched findings, exact dependency versions with known CVEs, auth implementation details, anything that converts 'this app has a PDF retrieval path' into 'here's how to attack it tonight.' The line is: publish what an auditor needs to price, DM what an attacker could use to aim. Moderators will edit requests that cross it and tell you why — that's the one place in this thread we'll touch your words.

AXIS Editorial

Follow-up from maker intake: "My budget is genuinely $0 right now. Is posting a request still useful or just noise?"

Useful if reframed honestly: post the scope with 'no budget — seeking guidance on self-review priorities' instead of fishing for free audits (auditors spot that instantly, and it burns the goodwill the category runs on). What a $0 scope post legitimately gets you: practitioners pointing at your riskiest stated surface ('your legacy export endpoint is the thing — kill it before anything else'), which is triage judgment, the expensive part, applied at reading-a-comment cost. Pair it with the DIY tier from the cost thread and the checklist thread, then come back for a paid engagement at the next transition of stakes. Several auditors have said versions of: the maker who did the free work first is the engagement they want — you're building your own discount.