JStarted by Jonathan (AXIS Launch)
The demand-side template — the mirror of the auditor introduction thread. Makers: put your audit request in this format in a new thread on GitHub Discussions (the link is at the foot of this page). I don't arrange audits or supply auditors, so an answer is not guaranteed. The format exists because "how much for an audit of my app?" is unanswerable, while a written scope is something a provider can price.
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 on GitHub Discussions or through the contact you gave — either is fine, but terms stated publicly (a range against a scope) help every reader calibrate, which is half this category's value. An auditor who responds says in that reply that they sell audit services (the conflicts rule, Rule 3 of /legal/community-guidelines). 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: I supply no auditors and keep no list of them, so a request may sit unanswered. If it does, the cost thread's DIY tier and the checklist thread are your meanwhile.
Who's got a scope? Start the thread on GitHub Discussions.
A worked example of the template, so nobody has to guess what a filled-in one looks like — 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: the email address on my site.
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.
Follow-up question: "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.
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, send privately what an attacker could use to aim. That line is yours to hold — check a request against it before you post it publicly.
Follow-up question: "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 can legitimately ask for: a practitioner 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. The maker who did the free work first is the engagement an auditor wants — you're building your own discount.