What Archer runs on, and what leaves it

The short version

Archer is a multi-tenant web application. A contractor uploads a solicitation, Archer reads it, prices it against that company’s own model, and produces the deliverables the bid needs. It runs on Vercel, stores everything in Supabase, and sends the solicitation to Anthropic’s API to be read.

The trust boundary is the org. Every piece of bid data belongs to exactly one, and the section on tenancy below says precisely what enforces that — including the part that is application code rather than database policy, because that distinction is the first thing a security review asks about and the answer should not be buried.

External dependencies

Four services, plus two that every page load touches without holding any bid data. Nothing else is called at runtime.

One bid, end to end

Each step is a separate package, and the boundary between them is deliberate: the pricing engine performs no I/O at all, which is what makes the arithmetic testable in isolation and keeps a network failure from ever producing a wrong number.

• Upload. The file is stored, and parsed to text — PDF, Word or Excel. Size-capped per document type.
• Extract. The text or the PDF goes to Claude, constrained to a schema. If that fails for any reason, a keyword pre-scan runs instead and the bid is flagged as a starting point rather than a reading of the document.
• Review. A person corrects the requirements. Nothing is priced from an extraction nobody has looked at.
• Price. The engine turns requirements plus that company’s pricing model into hours, cost, and a price. Pure arithmetic, no I/O.
• Deliver. Excel with live formulas, a PDF summary, a technical proposal, or the customer’s own bid form filled in.

How one company’s pricing is kept from another’s

This is the question that matters most, so here is the unvarnished answer. Archer reaches its own database with a service-role credential, which bypasses Postgres’s row-level security. That means database policies are not the thing separating one company’s bids from another’s. Application code is.

That code is deliberately small and does one thing: every route resolves the caller’s organization from their signed session, and never from anything in the URL or the request body. There is no org identifier a caller can tamper with, because none is ever read from the request. A bid belonging to another organization answers “not found” rather than “forbidden”, so probing cannot confirm that an id exists.

Storage follows the same shape: objects are filed under the organization’s id, the bucket is private, and files are served only through a signed, expiring URL issued after the same check.

Access

Invite-only. Access is granted by email address before a person has ever signed in, and claimed automatically when they first do. Sign-in is Google only. There are no passwords to steal, and no password reset flow to attack.

What Archer does not have

A vendor page that lists only strengths is not useful to anyone doing this job properly. These are true today.

• No SOC 2 report and no third-party penetration test. Neither has been started.
• No SSO beyond Google. No SAML, no SCIM, no directory sync.
• No customer-managed encryption keys. Data is encrypted at rest and in transit by the platform defaults.
• No Content-Security-Policy yet. Other security headers are set; a meaningful CSP needs the app's inline styles and third-party font loading moved first, and a policy widened until it passes would prove nothing.
• No formal data-residency guarantee. Infrastructure is US-based, but it is not contractually pinned.
• Audit logging covers authentication, not per-record reads.

If one of these is a blocker for your review, say so and we will tell you straight whether it is on the roadmap or not.