There is, as ever, a certain impatience with abstraction. One can discourse at length on the capabilities of Claude Code—its facility with structure, its fluency in language, its rather unnerving ability to translate intent into execution—but such discussion risks becoming ornamental unless tethered to something demonstrable.

So, instead, I have taken a more direct route.

What follows is a product outline for a modest but instructive application: an automated NDA web tool. Nothing grandiose, nothing overwrought—simply a clear articulation of requirements, written in the manner one might expect from a disciplined product manager.

The exercise is intentionally unadorned. One pastes the outline into Claude Code, and from that description alone, the application begins to take shape. No elaborate scaffolding, no intricate orchestration—just a well-formed statement of intent, translated into working software.

That, I think, is the point worth observing.

For what reveals itself in this process is that a great many systems—particularly in the legal domain—are not as structurally complex as they present themselves to be. They are, in essence, organized expressions of rules, language, and variation. And when those elements can be specified with sufficient clarity, they can be constructed with surprising ease.

So there is no need here for further elaboration. The outline is the demonstration.

Paste it in, and watch what happens.

Product Specification: Automated NDA Web Application Prepared for: Claude Code (AI Coding Agent) Date: 2026-03-23 --- 1. Problem Framing What problem is being solved? Non-disclosure agreements are a high-frequency, low-complexity contract that nonetheless consume disproportionate legal, operational, and calendar time. Sales reps wait days for legal review. Legal teams manually draft boilerplate. Counterparties print, scan, and email PDFs. Signed copies are lost in inboxes. Expiry dates are missed. Why does it matter? Deals stall while NDAs sit in queues. Unsigned or expired NDAs create unenforceable confidentiality obligations. Legal spends hours per week on work that should require zero human intervention. Implicit assumptions: The NDA templates are pre-approved by legal and the system enforces guardrails, not bespoke negotiation. The primary signing method is electronic, legally valid in most jurisdictions under ESIGN and eIDAS. The organization wants self-service so that business users initiate NDAs without involving legal for standard cases. Both mutual and one-way NDA variants are required. --- 2. User and Stakeholder Model Business User (Initiator): Wants to send an NDA quickly without involving legal. Not a lawyer. Needs a simple form, not contract software. Counterparty (External Signer): Wants to sign without creating an account or installing software. May be on mobile. Has low trust in new software and must be able to complete the flow in under three minutes. Legal and Admin: Wants to maintain approved templates, review escalations, and audit signed documents. Needs visibility into all active and expired agreements. Compliance and Risk: Needs to ensure NDAs are executed before sensitive information is shared. Requires audit trail, expiry alerts, and full-text search. Executive: Wants dashboard visibility into contract volume and risk exposure with minimal time investment. --- 3. Core Use Case Definition Primary workflow from initiation to countersignature: Step 1. Initiator logs in and clicks New NDA. Step 2. Initiator fills an intake form capturing: NDA type (mutual or one-way), counterparty name and email, counterparty company, purpose and description, effective date, expiry duration, and governing law jurisdiction. Step 3. System selects the matching approved template based on NDA type. Step 4. System populates the template with form data and generates a PDF preview for the initiator to review. Step 5. Initiator signs first, then confirms send. Step 6. System emails the counterparty a unique signing link that requires no account creation. Step 7. Counterparty opens the link, reads the rendered NDA in-browser, and signs by typing their name, drawing a signature, or uploading an image. Step 8. Counterparty checks an acknowledgment checkbox and submits. Step 9. System captures signature along with IP address, timestamp, and browser metadata. Step 10. Both parties immediately receive the countersigned PDF via email. Step 11. NDA is stored in the repository with full-text search, status tracking, and expiry monitoring. Edge cases and failure modes: If the counterparty requests changes, the system escalates to legal and flags the NDA as in negotiation. Legal can upload a redlined version and the system re-sends it. If the counterparty never signs, automated reminders are sent at 48 hours and 5 days. The NDA is auto-voided after a configurable timeout. If the initiator enters the wrong counterparty email, the NDA can be re-sent to a corrected address and the audit log preserves both attempts. As an NDA approaches expiry, alerts are sent to both parties at 30 days and 7 days before the expiry date. When an NDA expires, the system marks it expired and prompts the initiator to renew. If a new NDA is created for a counterparty domain that already has an active NDA, the system warns the initiator of the duplicate. --- 4. Functional Requirements Template Management Admin can create, edit, and version NDA templates using variable placeholders such as counterparty_name and effective_date. Templates are tagged by type: mutual, one-way, employee, vendor, or partner. Template versioning ensures that signed NDAs always reference the exact version used at the time of signing. Templates can be activated and deactivated. Intake and Generation The web intake form collects: NDA type, counterparty details, purpose, effective date, expiry duration, jurisdiction, and optional custom clauses drawn from an approved clause library. The system auto-populates the selected template and renders a PDF preview before the initiator sends. Sending and Counterparty Experience The system sends a branded email with a unique, expiring signing link. The counterparty portal is mobile-responsive and requires no login. The counterparty reads the NDA in-browser and can also download a PDF. Signature options are: typed name, drawn signature via canvas, or uploaded image. The counterparty must check an acknowledgment checkbox before submitting. Upon signing, both parties immediately receive the countersigned PDF. Signature and Audit Trail Each signing event captures: UTC timestamp, IP address, browser and device information, email confirmation, and signature image or text. The audit trail is embedded in PDF metadata and also stored separately in the database. Signed PDFs are hashed using SHA-256 and the hash is stored so integrity can be verified at any time. Repository and Search All NDAs are stored with one of the following statuses: Draft, Sent, Signed, Expired, Voided, or In Negotiation. Full-text search is available by counterparty name, company, purpose, date range, and status. Filters are available for NDA type, initiator, jurisdiction, and expiry window. Signed PDFs can be downloaded at any time. Lifecycle and Alerts Expiry duration is configurable with defaults of one year, two years, three years, or a custom value. Automated reminders are sent to the counterparty at 48 hours and 5 days if unsigned. Expiry alerts go to initiator and counterparty at 30 days, 7 days, and on the expiry date. A one-click renewal workflow re-sends an updated NDA to the same counterparty. Escalation and Negotiation Counterparties can click Request Changes, which triggers a notification to the initiator and legal team. Legal can upload a redlined version and the system re-sends it. Each negotiation round is tracked and reflected in the NDA status. Admin and Reporting The admin dashboard shows: NDAs by status, volume by month, average time to sign, and the expiry pipeline. User management supports inviting users and assigning roles of initiator, legal, or admin. The audit log records all system actions including who sent what, when, and from which IP. Admins can export NDA metadata as CSV and download PDFs in bulk. Integrations (Phase 2) Webhook on NDA signed event for CRM and Slack integration. Zapier and Make compatible webhook triggers. REST API for programmatic NDA creation and status queries. SSO and SAML for enterprise login. --- 5. Non-Functional Requirements Performance: Page load under 2 seconds. PDF generation under 5 seconds. Signing link loads in under 3 seconds on a 4G mobile connection. Availability: 99.9% uptime target. Signing links must remain functional even during admin maintenance windows. Security: HTTPS everywhere. Signing links are single-use UUID tokens with a 30-day TTL. PDFs are stored encrypted at rest. No PII is written to application logs. Compliance: Signature capture is compliant with the ESIGN Act in the US and eIDAS in the EU. The system is GDPR-ready with support for data deletion on request. Usability: The counterparty signing flow must be completable in under 3 minutes with zero training. The interface meets WCAG 2.1 AA accessibility standards. Scalability: The system must support 10,000 active NDAs and 1,000 new NDAs per month without architectural changes. Email deliverability: Transactional email is sent via a provider such as Resend, SendGrid, or Mailgun with SPF and DKIM configured. --- 6. Data Model Key entities and their fields: users: id, email, name, role (initiator, legal, or admin), org_id, created_at, last_login organizations: id, name, logo_url, brand_color, default_jurisdiction, created_at templates: id, org_id, name, type (mutual, one_way, employee, or vendor), body_html, variables_json, version, is_active, created_by, created_at ndas: id, org_id, template_id, template_version, initiator_id, counterparty_name, counterparty_email, counterparty_company, purpose, effective_date, expiry_date, jurisdiction, status, signed_pdf_url, signed_pdf_hash, sent_at, signed_at, voided_at, created_at, updated_at signing_tokens: id, nda_id, token (UUID), counterparty_email, expires_at, used_at, created_at signatures: id, nda_id, signer_type (initiator or counterparty), signer_email, signature_data (base64 image), ip_address, user_agent, signed_at audit_log: id, nda_id, user_id (nullable), action, detail_json, ip_address, created_at reminders: id, nda_id, type (unsigned_followup or expiry_warning), scheduled_at, sent_at Relationships: An organization has many users, many templates, and many NDAs. An NDA belongs to one template at a pinned version, one initiator, and has many signatures, signing tokens, audit log entries, and reminders. --- 7. System Design Outline The application is a Flask web app with SQLite as the database. It has three route groups: admin routes, initiator routes, and counterparty routes. Business logic is separated into discrete modules. A background scheduler handles reminders and expiry checks. An external email provider handles transactional delivery. Signed PDFs are stored on local disk for MVP and migrated to object storage in Phase 2. Key modules: app.py handles all Flask routes, auth middleware, and session management. database.py manages the SQLite schema and all CRUD operations. template_engine.py performs Jinja2 variable substitution into NDA HTML. pdf_engine.py converts HTML to PDF using WeasyPrint. signing.py handles token generation, signature capture, PDF finalization, and hash computation. mailer.py dispatches email via the Resend API. scheduler.py runs APScheduler background jobs for reminders and expiry checks. auth.py manages login, sessions, and role-based access control. --- 8. AI and Automation Opportunities Clause risk flagging: When a counterparty requests changes, AI highlights non-standard or high-risk clauses. This is a classification and extraction task. Planned for Phase 2. Auto-fill from URL or business card: Populate counterparty fields from a LinkedIn URL or uploaded image. This is an extraction task. Planned for Phase 2. Purpose suggestion: As the initiator types the purpose field, AI suggests completions drawn from prior NDA purposes. This is a generation task. Planned for Phase 2. Duplicate and conflict detection: AI checks whether a new NDA conflicts with or duplicates existing signed agreements. This is a reasoning task. Planned for Phase 2. Expiry risk digest: A weekly email summarizing NDAs expiring soon, flagging those tied to active deals. This is a generation task. Planned for Phase 2. Smart template selection: Based on intake form answers, the system selects the best-fit template. This starts as a rule-based classifier in Phase 1 and can be upgraded to AI in Phase 2. --- 9. Claude Code Execution Plan Tech stack: Backend is Python 3 with Flask. Database is SQLite using the stdlib sqlite3 module. PDF generation uses WeasyPrint with xhtml2pdf as a fallback. Email is sent via the Resend API. Background jobs use APScheduler. Authentication uses Flask-Login with bcrypt. The frontend is pure HTML, CSS, and vanilla JavaScript with no Bootstrap or jQuery. Drawn signatures use the browser Canvas API. File and module structure: [prompt me for a directory location to build web application] app.py database.py to template_engine.py pdf_engine.py signing.py mailer.py scheduler.py auth.py requirements.txt nda.db (auto-created) uploads/ (signed PDFs) static/css/main.css static/js/main.js static/js/signature_pad.js templates/base.html templates/login.html templates/dashboard.html templates/nda_new.html templates/nda_preview.html templates/nda_detail.html templates/sign.html templates/sign_complete.html templates/admin_templates.html templates/admin_template_edit.html templates/admin_dashboard.html Key functions: template_engine.py exposes render_nda(template, variables) which Jinja2-renders the template body with a variables dictionary and returns an HTML string. pdf_engine.py exposes html_to_pdf(html, output_path) which converts an HTML string to a PDF and returns the file path. It also exposes embed_signatures(pdf_path, signatures) which overlays signature images onto the PDF and returns a new file path. signing.py exposes generate_token(nda_id, email, ttl_days) which creates a UUID token in the signing_tokens table. It exposes validate_token(token) which checks that the token exists, has not been used, and has not expired. It exposes finalize_nda(nda_id, signature_data, ip, user_agent) which captures the signature, rebuilds the PDF with both signatures embedded, hashes it, stores it, and returns the PDF URL. It exposes compute_hash(file_path) which returns the SHA-256 hash of the file. mailer.py exposes send_signing_request(nda, token), send_signed_copies(nda), send_reminder(nda, token), and send_expiry_warning(nda, days_remaining). scheduler.py runs check_reminders() and check_expiry() on an hourly interval. check_reminders sends 48-hour and 5-day unsigned follow-ups. check_expiry sends 30-day and 7-day expiry warnings and marks overdue NDAs as expired. Build order: 1. database.py with full schema and all CRUD functions 2. auth.py with login, registration, and role-based access control 3. Login and registration templates 4. template_engine.py and admin template CRUD routes and templates 5. nda_new.html intake form and NDA creation route 6. pdf_engine.py HTML to PDF conversion 7. mailer.py Resend integration 8. signing.py token generation and counterparty signing portal 9. sign.html counterparty experience with canvas signature drawing 10. Signed PDF finalization, storage, and hashing 11. dashboard.html NDA list with search and status filters 12. nda_detail.html with audit trail, download, void, and renew 13. scheduler.py reminders and expiry background jobs 14. admin_dashboard.html with analytics 15. CSS polish and branded email templates --- 10. Open Questions and Risks E-signature legal validity: Jurisdiction requirements vary. Assumption made is that capturing timestamp, IP address, user agent, and an explicit acknowledgment checkbox satisfies ESIGN in the US and eIDAS in the EU. Risk level is medium. PDF generation reliability: WeasyPrint can have complex system dependencies. Assumption is WeasyPrint is used with xhtml2pdf as a pure-Python fallback. Risk level is low. Email deliverability: Resend requires domain verification. The user must configure a Resend API key and verify their sending domain before emails will deliver. Risk level is low. Multi-party NDAs: Three or more signers are out of scope for MVP. The data model is designed to support this extension later. Risk level is low. Template negotiation: Inline redlining is not in scope for MVP. Legal manually uploads a revised version and the system re-sends it. Risk level is medium. GDPR compliance: A data deletion endpoint is planned but not scoped for MVP. Risk level is medium. File storage: The MVP uses local disk for signed PDFs. Phase 2 will migrate to S3-compatible object storage. Risk level is low for MVP. Initiator signature: Assumption is that the initiator signs first via the web UI before the NDA is sent to the counterparty. Both signatures are embedded in the final countersigned PDF. Risk level is low. --- Ready for Claude Code implementation. Start at step 1 of the build order in section 9.