Case study: RightForms

Legal documents for the emergency you did not plan for.

RightForms is self-help legal document software for California families: pick the documents you need (who can pick your child up from school, who can make a medical decision, who is a temporary guardian), fill in the details, and get PDFs ready for signature and notarization, without a lawyer. It is explicitly a document preparer, not a law firm, and it does not give legal advice. The site is deployed and answering today, ahead of its own planned public launch.

The numbers, and how to check them

From the review of the live codebase, 2026-09-18. Test count is a static count of test functions in the repository, not a live pytest run.

816

test functions in the codebase

grep -c '^def test_' tests/*.py

13

document types in the catalog

ls apps/documents/schemas/*.py

12

database models across 33 migration files

grep -c '^class .*models.Model' apps/*/models.py

219

commits, 22 April to 2 September 2026, one author

git log --oneline | wc -l

What it actually does

  1. Authentication and roles. Email and password, no invite codes or OAuth. A visitor can start an order before creating an account, and the anonymous order carries over automatically the moment they register or log in. One role exists: the owner of an order.
  2. Data. PostgreSQL behind Django, 12 models across 33 migrations. PDFs are generated server-side and written to disk; the settings configure S3-compatible storage for them, but the project's own documentation calls that path dead code today.
  3. Payments. Stripe Checkout with a webhook. The webhook is idempotent by a unique event ID inside one atomic transaction, and the follow-up task is queued only after that transaction commits, so a worker can never read an order status that has not actually been saved yet.
  4. Integrations. A pure internal API returns a generated PDF by document type, language and the people involved, without touching sessions, Stripe or the order database at all. A second internal system consumes it to request documents directly.
  5. Languages. The public site is English-only by design. Separately, the same internal API can return field labels in Russian or Spanish for the other system that consumes it: two different audiences from one codebase.
  6. Security. The internal API is protected by a shared-secret header compared in constant time; general rate-limiting or anti-abuse tooling was not found elsewhere in the project.
  7. Admin. Standard Django admin, with an inline editor for a document's participant fields, so a new document type can be added without touching code. Every generated document tracks what happens to it afterward: signed, notarized, shared, expired.

What it is not

The part that makes the rest of this page checkable.

Pre-launch, by its own documentation

The project's own docs call this "dev, not production," and keep Stripe and outbound email switched off on purpose until launch. We are not calling it a launched product here.

No rate limiting found

A search for common anti-abuse packages found none in the dependencies. Beyond Django's own CSRF protection, the internal API's shared-secret header is the main defense in place.

One contributor

All 219 commits in the repository's history are from the same author.

A demo scenario, not real client data

A gated demo route seeds a fictional client and opens the data-entry screen directly, for showing how the flow works. It is not a view into anyone's real order.

Engineering decisions worth explaining

  1. Fail-closed for sworn statements. A field whose value gets printed into a document under penalty of perjury cannot carry a default value in the code. If the person filling in the form never made an explicit choice, the generator refuses to print an assumption and raises an error instead, and the background task that catches it does not retry, because retrying would only delay the alert, not fix the missing answer.
  2. Statute text that expires on its own. The exact wording of the relevant California statutes is stored byte-for-byte as published by the state. A test tied to a "last verified" date fails on its own once that date passes 120 days old, forcing someone to re-check the law instead of trusting old memory of it.
  3. Two translation systems, on purpose. The public site is locked to English. A separate internal layer serves the same content in Russian and Spanish to the one other system that needs it: two different products served from one codebase, neither compromising the other's requirements.
  4. Idempotent generation. Before writing a multi-document order, the generator clears out anything left behind by a previous failed attempt, then writes every document inside one transaction: all of them or none, so a retry after a partial failure cannot leave a mismatched set of PDFs behind.
  5. A pure API as the integration point. The internal endpoint that generates a PDF touches nothing else in the system: no session, no Stripe, no order record. That let a second internal system reuse the same tested document engine without duplicating it or routing through the public checkout flow.

Why this matters if you are hiring us

RightForms is what "custom software" means in practice: a real legal-document generator with a fail-closed rule for anything printed under penalty of perjury, and an internal API clean enough that a second system could reuse it without touching checkout. We would rather ship it honestly labeled pre-launch than call it live before it is.

Tell us what's slowing you down.

We reply the same business day.