Example ยท proof of work
Private repo proof Private repository / non-public repo

CraftedTerms Document-Preparation SaaS

A B2B document-preparation SaaS that pairs a public marketing and SEO site with an authenticated workspace. Customers submit document requests and download finished files; operators work a review queue; admins manage users, roles, and an audit view. Built on Next.js and Supabase.

Private repository. Source code is not public. Implementation details, a guided walkthrough, or a sanitized sample are available on request.

Document-preparation SaaS proof visual with a customer request intake, an operator review queue, and a finished document delivery tray

This proof shows a full B2B SaaS shape: a public site for acquisition and an authenticated workspace where real work happens across customer, operator, and admin roles. It is private-repo proof โ€” the multi-role architecture is verifiable in source, while a public deployment and live payments remain deliberately out of scope here.

Proof assets and links

Repository or technical proof boundary. Portfolio proof, not measured client metrics.

Problem

A document-preparation service needs more than a form: it needs accounts, a request intake, a fulfillment queue for the people doing the work, file delivery back to the customer, and admin controls โ€” a full multi-role application, not a single page.

Context

This is a complete SaaS application with a public side and a workspace side. The public side is a marketing and SEO site rendered from MDX content; the workspace side carries customer, operator, and admin roles. It is presented as private-repo proof. Live payment processing is currently deferred (a Stripe skeleton remains parked), so no paid-launch or revenue claim is made here.

Inputs

Technical approach

The application is a Next.js App Router project split into a public route group and a workspace route group. The public group serves marketing pages, services, guides, articles, FAQ, pricing, and legal pages from MDX content. The workspace group carries three roles: customers create and track requests and manage files; operators work a request queue with per-request detail and handling views; admins manage users, assign roles, and review an audit view. Auth, accounts, files, operator actions, admin operations, and internal maintenance jobs run through API routes. Supabase provides auth, Postgres, and storage; the UI is built on Radix primitives with a Tailwind component layer, with react-hook-form and Zod for forms. A Stripe payment seam exists but is intentionally parked.

Stack

What was built

A two-sided SaaS: a public marketing/SEO site and an authenticated workspace. Customers register, submit document requests, track status, manage files, and download finished documents. Operators handle a request queue with per-request views and deliver files. Admins manage users and roles and inspect an audit trail. Payment primitives (pricing, payment status, server-side price computation) exist as a parked seam while live payments are deferred.

Deployment

Private-repo proof. The application architecture is verifiable in source; no public live URL, live payment flow, or measured client outcome is claimed for this page.

What can be reused

Boundaries

Related

Request a task review