Full-stack developer to design and build Chara: a B2B claims-governance SaaS

I am looking for an experienced full-stack developer to design and build Chara, a B2B web application for the cosmetics and personal-care industry. Chara lets multinational beauty companies route marketing claims (for example, "visibly reduces fine lines in 4 weeks") through a mandatory multi-stage approval chain before the claim can appear on packaging, advertising, or online. The audit trail is as much the product as the workflow is. This is not a "figure out what to build" engagement. You will receive: 1. A product requirements document (PDF). 2. An engineering requirements document covering architecture, security, reliability, and compliance. There is no existing UI design. You will design the screens yourself from the PRD, get my sign-off, and then build them. I am looking for one person who can own both the design and the implementation. WHAT THE PRODUCT DOES - Approval workflow. A claim request moves through fixed stages: R&D, Regulatory, Legal, Local Claims Forum (LCF), and Business Approval. Each stage records a decision (approve, reject, request changes) with comments. The state machine lives on the server; the UI only reflects it. - Claims and variants. A request carries one or more claims; each claim can have variants and translations per market. Claim text is immutably versioned so reviewers always see exactly what they approved. - Roles. Requester, R&D reviewer, Regulatory reviewer, Legal reviewer, LCF reviewer, Business Approver, and Admin, each scoped by country and brand. Server-side authorization decides who can see and do what. - Audit trail. Every state change is written to an append-only, hash-chained audit log in the same transaction as the change. There is an endpoint to verify chain integrity and an export (CSV/PDF) for regulators. - AI assists (Claude API). Regulatory sense-check of a claim, translation, and extraction of claims from uploaded artwork. All AI runs server-side as queued background jobs with retry, backoff, per-tenant quotas, caching, and logging. The API key never reaches the browser. Without a key, deterministic rule-based fallbacks must keep the product usable. - Screens to design and build: Login, Dashboard, Requests (kanban and list views with filters), My Requests, New Request (multi-claim form with variants, artwork extraction, AI assists), Reports, Team, Global Projects. Modals: Claim Detail (tabs for reviews, audit, translations, attachments), LCF review, Business Approval review, team member edit. DELIVERABLES Design - A short design system first: color palette, type scale, spacing, and the core components (buttons, inputs, badges, cards, tables, modals, toasts). Deliver as design tokens I can drop into a stylesheet. - Low-fidelity wireframes of every screen and modal listed above, then high-fidelity mockups (Figma or equivalent) once the wireframes are approved. Cover the main states: empty, loading, error, and each workflow stage. - Clean, professional enterprise look. Reviewers will spend hours a day in this tool; clarity beats decoration. Backend - TypeScript API (Fastify preferred; Node 20+), versioned under /v1, with an OpenAPI spec generated from the route schemas. - PostgreSQL schema with versioned migrations that run automatically on boot. No manual production schema changes, ever. - Tenant isolation enforced by PostgreSQL row-level security below the application layer, with an automated test proving a deliberately unfiltered query cannot cross tenants. - Workflow state machine, RBAC policy, immutable claim versioning, and the hash-chained audit log described above. - Idempotency keys on every state-changing endpoint; a retried request must not double-apply a transition. - Background job system (pg-boss or an equivalent Postgres-backed queue) for AI work, with a polling endpoint for job status. - Auth behind a clean interface: a development login for local use, and an adapter boundary a managed OIDC/SAML provider (WorkOS, Auth0, Entra ID) plugs into. Wiring one real provider is a separate milestone. - Health (/healthz) and readiness (/readyz) endpoints, graceful shutdown, structured logs with request IDs and secret redaction, rate limiting, security headers. Frontend - Every screen and modal from your approved designs, driven by the real API. - Real routes (one per screen), a component per screen and per repeated pattern, design tokens in a stylesheet, and an explicit state and data-fetching layer. No single-file monoliths, no screens toggled by a state variable, no inline style strings. - Stack is your call within reason (a vanilla ES-module app, React, Svelte, or similar are all fine). Justify the choice in your proposal. - No user-facing copy with mid-sentence em dashes. Use periods, commas, or colons. Quality - Unit and integration tests on the server (tenant isolation, workflow transitions, audit chain, idempotency, authorization). - Frontend unit tests plus an end-to-end suite (Playwright or similar) covering the main approval journey. - Tests must run in CI without Docker or a separately installed database (embedded PostgreSQL is acceptable). - Static analysis and dependency audit in CI. MILESTONES (2 WEEKS TOTAL) 1. Design and foundation (days 1 to 4): design tokens, wireframes of all screens, data model, migrations, RLS with isolation tests, audit log, workflow state machine, auth boundary, core API with OpenAPI. Demo: approved wireframes, and a request created via the API walked through every stage with a verified audit chain. 2. Core UI (days 5 to 9): high-fidelity designs signed off, then Login, Dashboard, Requests, My Requests, New Request, Claim Detail and the two review modals, all on the real API. Demo: the full approval journey end to end in the browser, E2E test green. 3. AI and reporting (days 10 to 12): job queue, the three AI assists with fallbacks and quotas, Reports, exports, Team screen wired to the real user endpoints. 4. Hardening (days 13 to 14): security review against the engineering requirements, CI green, test coverage on every guarantee listed above. The schedule is tight on purpose. If you think it is unrealistic, say so in your proposal and tell me what you would cut or reorder. EXPLICITLY OUT OF SCOPE FOR THIS CONTRACT (QUOTE SEPARATELY IF INTERESTED) - Real file storage with virus scanning and signed URLs (the initial build may stub attachments, clearly labeled). - Email or in-app notifications. - Configurable workflow stages per customer. - Global Projects as a persisted feature (it may ship as a labeled demo). - Wiring a specific SSO provider. - Right-to-left layout. WHO I AM LOOKING FOR - Prior experience building multi-tenant or regulated B2B software (audit logs, RBAC, compliance requirements). Pharma, cosmetics, fintech, or legal-tech backgrounds are a plus. - Experience integrating an LLM API into a backend with proper job queuing and cost control. Familiarity with the Anthropic Claude API is a plus but not required. - Clear written English. Short written progress notes every other day, and a demo at each milestone. - Able to work independently from written specs and to ask precise questions when the specs conflict (they will, in places). TO APPLY AND TERMS - Include your proposed milestone breakdown and total: fixed price, or hourly with an estimate. - Payment is tied to the milestones above, released on demo and passing CI. - All design files, code, and configuration are delivered to my repository under my ownership. NDA required before the PRD is shared. - Long-term maintenance and the Phase 2 items above are available to the right person after delivery. - Start your proposal with the word "Regulatory" so I know you read this far.