System Requirements Document for fullstack-websites-ai

1. Introduction

This document specifies the system requirements for fullstack-websites-ai, a business-plan workspace for a founder who sells fullstack websites built with AI. The product's purpose is to let a technical builder author, assemble, and present a complete business plan for an AI-powered fullstack website development business, and to let a reviewer read that plan and judge whether it is credible and worth acting on.

The plan itself is the artefact. The product therefore treats the business plan as a dual-natured document: an editorial half written in prose (offering, target market, operations, pricing) and a technical half expressed as structured, machine-readable content (stack, unit economics, delivery model, financials). The audience is the author — a technical builder who owns drafting, editing, and finalizing the plan — and the reviewer — an investor, partner, or advisor who reads the finished plan and evaluates its sections and financial assumptions.

The system is delivered as a first-party web application with application-owned identity, a custom interface, and backend integration that persists the durable business plan across sessions.

2. System Overview

The system is a web application composed of five pages: an anonymous Landing page that establishes the product's identity and purpose, two anonymous identity-access pages (Sign Up and Login), a role-restricted Plan Editor where the author creates and edits the plan's content, and a role-restricted Business Plan page where the assembled plan is read by both the author and the reviewer.

Actors:

• Business Plan Author — an active human persona. Self-service enrolls, establishes an account, and uses returning verification to resume protected plan work. Creates and edits the plan's offering, target market, operations, pricing, and financial content, and finalizes a complete, presentable plan document.
• Plan Reviewer — an active human persona. Establishes an account, receives authorized access, and uses returning verification to resume protected plan reading. Reads the finished plan, reviews its sections and financial assumptions, and reaches a judgment on whether the plan is credible and worth acting on.

The application owns identity and session continuity so that the durable business plan remains bound to the correct participant and can be resumed. The Plan Editor is restricted to the author; the Business Plan page is restricted to the author and the reviewer. No differentiated permission model beyond this author/reviewer distinction is established by the source.

Narrow exclusions: the system does not provide invitation-based or provisioned enrollment, does not provide provider-owned identity, and does not provide adjacent account-management capabilities beyond first-use identity establishment and returning verification. No stock photography, no third-party document-editor product, and no blue or indigo accent are part of the design.

2a. Product Interpretation and Delivery Boundary

The product is a first-party web application. All five pages are owned and served by the application itself; there is no provider-owned surface, no external destination, and no headless delivery in the current scope.

Access ownership: the Landing page is anonymously reachable and explains the product before any identity is established. Sign Up and Login are anonymously reachable identity-access surfaces — a protected destination cannot own the interaction that establishes access to itself, so enrollment and returning verification live on their own anonymous pages. The Plan Editor and Business Plan pages are protected and require an established, verified identity; the Plan Editor is further restricted to the author role and the Business Plan page is available to the author and reviewer roles.

Current versus future: everything specified in this document is current. No future-horizon requirements are established by the source; nothing in this document should be read as committing the product to capabilities beyond authoring, assembling, and reading the business plan.

2b. Source Content Inventory

Not applicable. No reference directive in this project declares a content_source, so no source content inventory is produced.

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous first impression. States the product's purpose — a business plan for building fullstack websites with AI — and its dual nature (prose plan and technical schema). No user-specific state; no loading of protected data.
• Primary action: Proceed to establish identity (Sign Up) or to returning verification (Login).
• Supporting actions: Read the hero explanation; toggle the mobile Prose/Code seam tab to view the same plan content as prose or as schema.
• Domain entities: None persisted. The hero displays a representative plan paragraph and its matching JSON schema as illustrative content.
• Component responsibilities:
  • Full-viewport split hero: left half warm paper with a large flush-left Archivo headline and the primary CTA pinned beneath it; right half a deep ink panel rendering the same plan as a live JSON document with monospace numerals and a blinking cursor.
  • A 1px accent vertical seam running the full viewport height between the halves, highlighted by a cursor-following accent highlight.
  • A single founder portrait, half-rendered as a wireframe, used once.
  • Small 1px ink line-art diagrams of the AI website delivery pipeline (brief → generation → review → deploy).
  • Mobile: a sticky labelled seam tab ('Prose' / 'Code') under the nav that swaps the halves with a 120ms crossfade.
• States: Loading — not applicable (static content). Empty — not applicable. Success — the visitor reads the purpose and chooses an entry action. Error — not applicable. Recovery — not applicable.

Sign Up

• Information and state: Anonymous self-service enrollment form. Collects the minimum identity information needed to establish an account. No protected state is available before enrollment completes.
• Primary action: Submit enrollment to establish an account.
• Supporting actions: Navigate to Login if an account already exists; return to Landing.
• Domain entities: Account (created), credential.
• Component responsibilities: Enrollment form with labeled fields; inline validation messaging; submit control; link to Login.
• States: Loading — submit in progress, control disabled. Empty — pristine form. Success — account established, session begins, and the participant is taken to the protected destination appropriate to their role. Error — invalid or incomplete input, or an account already exists for the supplied identity, shown inline with the form preserved. Recovery — correct the flagged input and resubmit without losing entered values.

Login

• Information and state: Anonymous returning-verification form. Collects the identity and credential of a returning participant.
• Primary action: Submit credentials to verify identity and resume the protected journey.
• Supporting actions: Navigate to Sign Up if no account exists; return to Landing.
• Domain entities: Account (verified), session.
• Component responsibilities: Verification form with labeled fields; inline validation messaging; submit control; link to Sign Up.
• States: Loading — verification in progress, control disabled. Empty — pristine form. Success — identity verified, session established, and the participant is routed to the protected destination appropriate to their role (Plan Editor for the author, Business Plan for the reviewer). Error — credentials do not verify, shown inline without disclosing which field failed. Recovery — re-enter credentials and resubmit; the entered identity value is preserved.

Plan Editor

• Information and state: Protected, author-restricted workspace holding the durable business plan. Displays the plan's sections — offering, target market, operations, pricing, and financial content — as editable prose on the editorial half and as structured technical content on the technical half. Shows the plan's current saved state and any unsaved changes.
• Primary action: Create or edit a plan section and save it to the durable plan.
• Supporting actions: Generate a section; move between sections; toggle the mobile Prose/Code seam tab; drag the seam to rebalance the two columns; open the assembled Business Plan page.
• Domain entities: Business plan, plan section (offering, target market, operations, pricing, financials), section content (prose and structured), saved/unsaved state.
• Component responsibilities:
  • Persistent two-column split: left half the editorial document at a single-column reading measure (68ch); right half a dark ink technical panel with monospace numerals, financial tables, and stack diagrams.
  • A full-height 1px accent seam between the halves that is interactive — dragging it rebalances the two columns.
  • Section headers using an all-caps 11px Archivo micro-label with 0.12em tracking and a small accent square bullet above a 48–64px flush-left heading.
  • A rectangular accent 'Generate section' button with a 3px hard offset shadow that depresses by 3px on press.
  • Mobile: a sticky labelled seam tab ('Prose' / 'Code') under the nav that swaps the halves with a 120ms crossfade.
• States: Loading — the durable plan is being retrieved; the workspace shows a loading state rather than empty fields. Empty — no plan exists yet; the workspace presents the sections as available to create. Success — the edited section is saved and the saved state is reflected in the workspace. Error — a save or generation attempt fails; the failure is surfaced with the unsaved content preserved. Recovery — retry the failed save or generation without losing the author's edits.

Business Plan

• Information and state: Protected, author-and-reviewer-restricted readable assembly of the completed plan. Presents the plan's sections as prose on the editorial half and the matching structured content — including the financials as a literal JSON object with tabular numerals — on the technical half, so the same numbers can be read as prose and as schema.
• Primary action: Read the assembled plan and assess its sections and financial outlook.
• Supporting actions: Toggle the mobile Prose/Code seam tab; drag the seam to rebalance the two columns; the author may navigate to the Plan Editor to continue editing.
• Domain entities: Business plan, plan section, financial figures, structured plan representation.
• Component responsibilities:
  • The same persistent two-column split as the Plan Editor, with the editorial half at 68ch and the dark ink technical half rendering the plan's financials as a literal JSON object with tabular numerals.
  • The interactive 1px accent seam between the halves.
  • Section headers using the all-caps micro-label and accent square bullet above a flush-left heading.
  • Mobile: the sticky labelled seam tab ('Prose' / 'Code') with a 120ms crossfade.
• States: Loading — the assembled plan is being retrieved. Empty — no completed plan is available to read; the page states this rather than showing blank sections. Success — the plan renders in full on both halves. Error — the plan cannot be retrieved; the failure is surfaced with a retry path. Recovery — retry retrieval; the reader's place in the document is preserved where possible.

3. Functional Requirements

FR-1 — Author produces a business plan for an AI fullstack website business (explicit) As a Business Plan Author, I should create and maintain a business plan for a business that builds fullstack websites using AI, so that I have a complete, presentable plan document.

• Trigger/input: the author, having established and verified identity, opens the Plan Editor.
• Observable result: a durable business plan exists and is persisted against the author's account.
• Access state: protected; author role only.
• Failure/recovery: if the plan cannot be created or saved, the failure is surfaced and the author's input is preserved for retry.
• Continuation: the author proceeds to populate the plan's sections.

FR-2 — Plan covers the core business-plan content areas (explicit) As a Business Plan Author, I should populate the plan's core content areas — the offering, the target market, and the financial outlook — so that the plan addresses what a reader needs to evaluate it.

• Trigger/input: the author edits a section in the Plan Editor.
• Observable result: the offering, target market, and financial outlook are present in the durable plan and visible in the assembled Business Plan page.
• Access state: protected; author role only.
• Failure/recovery: a failed section save is surfaced and the section content is preserved for retry.
• Continuation: the author moves to the next section until the plan is complete.

FR-3 — Author edits plan sections in a dual prose/technical workspace (required_inference) As a Business Plan Author, I should edit each plan section as prose on the editorial half while its structured technical counterpart is shown on the technical half, so that the narrative and the machinery of the plan stay consistent.

• Trigger/input: the author selects a section and edits its content.
• Observable result: the edited prose and its structured counterpart are both reflected in the workspace and saved to the durable plan.
• Access state: protected; author role only.
• Failure/recovery: a failed save or generation is surfaced with the author's edits intact.
• Continuation: the author continues editing or opens the assembled plan.

FR-4 — Author generates a section (required_inference) As a Business Plan Author, I should generate a plan section from the workspace, so that I can produce a first draft of a section and then refine it.

• Trigger/input: the author activates the 'Generate section' control for a section.
• Observable result: generated content appears in the section and can be edited and saved.
• Access state: protected; author role only.
• Failure/recovery: a failed generation is surfaced and the section's existing content is preserved.
• Continuation: the author edits the generated content and saves it.

FR-5 — Author assembles and reads the completed plan (required_inference) As a Business Plan Author, I should open the assembled Business Plan page and read the plan as a finished document, so that I can confirm it is complete and presentable.

• Trigger/input: the author navigates from the Plan Editor to the Business Plan page.
• Observable result: the assembled plan renders with prose on the editorial half and structured content, including financials as a literal JSON object with tabular numerals, on the technical half.
• Access state: protected; author and reviewer roles.
• Failure/recovery: if the plan cannot be retrieved, the failure is surfaced with a retry path.
• Continuation: the author returns to the Plan Editor to make further edits, or treats the plan as final.

FR-6 — Author completes self-service enrollment (required_inference) As a Business Plan Author, I should complete self-service enrollment before creating or editing the durable business plan, so that my plan is bound to my own account and can be resumed.

• Trigger/input: the author submits the Sign Up form.
• Observable result: an account is established, a session begins, and the author reaches the protected Plan Editor.
• Access state: anonymous entry on Sign Up; protected state remains unavailable until enrollment completes.
• Failure/recovery: invalid or incomplete input, or an existing account for the supplied identity, is shown inline with the entered values preserved.
• Continuation: the author begins creating the plan.

FR-7 — Author resumes protected plan work with returning verification (required_inference) As a Business Plan Author, I should verify my identity on return, so that I can resume editing my durable plan.

• Trigger/input: the author submits the Login form.
• Observable result: identity is verified, a session is established, and the author is routed to the Plan Editor with the durable plan available.
• Access state: anonymous entry on Login; protected state remains unavailable until verification succeeds.
• Failure/recovery: failed verification is shown inline without disclosing which field failed; the entered identity value is preserved for retry.
• Continuation: the author resumes editing.

FR-8 — Reviewer establishes an account and receives authorized access (required_inference) As a Plan Reviewer, I should establish an account and receive authorized access before reading the completed plan, so that the plan is only read by an authorized participant.

• Trigger/input: the reviewer submits the Sign Up form.
• Observable result: an account is established, a session begins, and the reviewer reaches the protected Business Plan page.
• Access state: anonymous entry on Sign Up; the Business Plan page remains unavailable until identity is established.
• Failure/recovery: invalid or incomplete input, or an existing account for the supplied identity, is shown inline with the entered values preserved.
• Continuation: the reviewer reads the plan.

FR-9 — Reviewer resumes plan reading with returning verification (required_inference) As a Plan Reviewer, I should verify my identity on return, so that I can resume reading the completed plan.

• Trigger/input: the reviewer submits the Login form.
• Observable result: identity is verified, a session is established, and the reviewer is routed to the Business Plan page.
• Access state: anonymous entry on Login; protected state remains unavailable until verification succeeds.
• Failure/recovery: failed verification is shown inline without disclosing which field failed; the entered identity value is preserved for retry.
• Continuation: the reviewer continues reading and evaluating the plan.

FR-10 — Reviewer reads the plan and assesses its financial outlook (required_inference) As a Plan Reviewer, I should read the finished plan's sections and financial assumptions, so that I can reach a judgment on whether the plan is credible and worth acting on.

• Trigger/input: the reviewer opens the Business Plan page.
• Observable result: the plan's sections render as prose on the editorial half and the financials render as a literal JSON object with tabular numerals on the technical half, so the same numbers can be read both ways.
• Access state: protected; author and reviewer roles.
• Failure/recovery: if the plan cannot be retrieved, the failure is surfaced with a retry path.
• Continuation: the reviewer completes their assessment; the author may continue editing.

FR-11 — Anonymous visitor understands the product before establishing identity (required_inference) As an anonymous visitor, I should understand what the product is and what it produces before I establish identity, so that I can decide whether to enroll or verify.

• Trigger/input: the visitor opens the Landing page.
• Observable result: the product's purpose and its dual prose/technical nature are presented, with entry actions to Sign Up and Login.
• Access state: anonymous; no protected state is exposed.
• Failure/recovery: not applicable to static content.
• Continuation: the visitor proceeds to Sign Up or Login.

FR-12 — Participant toggles between prose and code on a narrow viewport (required_inference) As a Business Plan Author or Plan Reviewer, I should toggle between the prose and code halves on a narrow viewport, so that the dual nature of the plan is preserved at mobile widths.

• Trigger/input: the participant activates the sticky labelled seam tab ('Prose' / 'Code').
• Observable result: the two halves swap with a 120ms crossfade, and the selected half is fully readable.
• Access state: inherits the access state of the containing page.
• Failure/recovery: not applicable.
• Continuation: the participant continues reading or editing.

4. User Personas

Business Plan Author

Product context. The author is a technical builder who sells fullstack websites built with AI. They are the originator of the business plan and the only participant who writes it. Their work is inherently dual: they must argue the business in prose (offering, target market, pricing) and simultaneously prove it in structure (stack, unit economics, delivery model, financials). The product's split-screen workspace exists because of this duality — the author's narrative and their numbers must stay in dialogue.

Primary goal. Reach a complete, presentable business plan document for an AI-powered fullstack website business.

Distinct accepted responsibilities. The author self-service enrolls and establishes an account; uses returning verification to resume protected work; creates the durable plan; edits the plan's sections — offering, target market, operations, pricing, and financial content — as prose on the editorial half with their structured counterparts on the technical half; generates sections to produce first drafts; saves section content to the durable plan; and opens the assembled Business Plan page to confirm the plan is complete and presentable.

Relevant inputs and decisions. The author decides what the offering is, who the target market is, how operations and delivery work, how the service is priced, and what the financial outlook is. The author decides when a section is finished and when the plan as a whole is presentable.

Interactions with other accepted participants. The author produces the artefact that the Plan Reviewer reads. The author does not control the reviewer's access beyond the fact that the plan is available to the reviewer role on the Business Plan page.

Observable success. A durable plan exists against the author's account, all core content areas are populated, and the assembled Business Plan page renders the plan in full on both halves.

Plan Reviewer

Product context. The reviewer is a stakeholder — an investor, partner, or advisor — who evaluates the plan rather than writing it. Their work is evaluative and read-only: they must be able to read the plan's argument and independently check its financial assumptions. The product's technical half exists in part for them, because it lets them read the same numbers as prose and as schema.

Primary goal. Reach a judgment on whether the plan is credible and worth acting on.

Distinct accepted responsibilities. The reviewer establishes an account and receives authorized access before reading the completed plan; uses returning verification to resume protected reading; reads the finished plan's sections; reviews its financial assumptions as presented on the technical half; and reaches a judgment on the plan's credibility.

Relevant inputs and decisions. The reviewer's inputs are the plan's sections and its financial figures. Their decision is whether the plan is credible and worth acting on.

Interactions with other accepted participants. The reviewer reads the artefact the Business Plan Author produced. The reviewer does not edit the plan.

Observable success. The reviewer can read the plan's sections and financial assumptions in full and has formed a judgment on its credibility.

5. Core User Flows

Flow A — Business Plan Author: first use, enrollment, and plan creation

1. The author opens the Landing page as an anonymous visitor and reads the product's purpose: a business plan for building fullstack websites with AI, presented as a split between prose and schema.
2. The author chooses the primary CTA and arrives at Sign Up.
3. The author completes the enrollment form and submits it. The form shows a loading state while the submission is in progress.
4. On success, an account is established, a session begins, and the author is routed to the protected Plan Editor. If the input is invalid or an account already exists for the supplied identity, the error is shown inline and the entered values are preserved so the author can correct and resubmit.
5. In the Plan Editor, the author sees the plan's sections — offering, target market, operations, pricing, and financial content — presented as prose on the editorial half and as structured content on the technical half. Because no plan exists yet, the workspace presents the sections as available to create.
6. The author selects a section and activates the rectangular accent 'Generate section' control to produce a first draft. The button depresses by 3px on press. If generation fails, the failure is surfaced and the section's existing content is preserved.
7. The generated content appears in the section. The author edits it as prose on the editorial half while its structured counterpart is shown on the technical half.
8. The author saves the section. On success, the saved state is reflected in the workspace. If the save fails, the failure is surfaced with the author's edits intact, and the author retries without losing work.
9. The author repeats steps 6–8 for the remaining sections until the offering, target market, operations, pricing, and financial content are all populated.
10. The author opens the Business Plan page and reads the assembled plan: prose on the editorial half, and the financials as a literal JSON object with tabular numerals on the technical half. If the plan cannot be retrieved, the failure is surfaced with a retry path.
11. The author confirms the plan is complete and presentable, or returns to the Plan Editor to make further edits.

Flow B — Business Plan Author: returning to resume plan work

1. The author opens the Login page as an anonymous visitor.
2. The author submits their identity and credential. The form shows a loading state while verification is in progress.
3. On success, identity is verified, a session is established, and the author is routed to the Plan Editor with the durable plan available. If verification fails, the error is shown inline without disclosing which field failed, and the entered identity value is preserved so the author can retry.
4. The author resumes editing the plan's sections, saving as they go, with the same success and failure behavior as Flow A steps 8–9.
5. The author opens the Business Plan page to re-read the assembled plan, or continues editing.

Flow C — Plan Reviewer: enrollment, authorized access, and reading the plan

1. The reviewer opens the Landing page as an anonymous visitor and reads the product's purpose.
2. The reviewer chooses the entry action and arrives at Sign Up.
3. The reviewer completes the enrollment form and submits it. The form shows a loading state while the submission is in progress.
4. On success, an account is established, a session begins, and the reviewer is routed to the protected Business Plan page. If the input is invalid or an account already exists for the supplied identity, the error is shown inline and the entered values are preserved so the reviewer can correct and resubmit.
5. The reviewer reads the finished plan: the sections as prose on the editorial half, and the financial assumptions as a literal JSON object with tabular numerals on the technical half, so the same numbers can be read both ways. If the plan cannot be retrieved, the failure is surfaced with a retry path.
6. The reviewer reaches a judgment on whether the plan is credible and worth acting on.

Flow D — Plan Reviewer: returning to resume reading

1. The reviewer opens the Login page as an anonymous visitor.
2. The reviewer submits their identity and credential. The form shows a loading state while verification is in progress.
3. On success, identity is verified, a session is established, and the reviewer is routed to the Business Plan page. If verification fails, the error is shown inline without disclosing which field failed, and the entered identity value is preserved so the reviewer can retry.
4. The reviewer resumes reading the plan's sections and financial assumptions and completes their assessment.

Flow E — Either participant: reading the plan on a narrow viewport

1. On a narrow viewport, the participant is on the Plan Editor or Business Plan page and sees a sticky labelled seam tab ('Prose' / 'Code') under the nav.
2. The participant activates the tab. The two halves swap with a 120ms crossfade.
3. The participant reads or edits the selected half, which is fully readable at the narrow width, and toggles back as needed.

6. Visuals, Colors, and Theme

The creative direction is authoritative for this section. The muse is Adham Dannaway; the headline idea is two halves in dialogue: the plan written in prose, the plan proven in code.

Color tokens (light mode):

Proportion: 60% paper, 25% white sheets, 10% ink panels, 5% accent. No blue anywhere; the ink is near-black navy, not indigo.

Typography:

• Headings: Archivo, weights 700–800, tight tracking -0.02em. Sentence case for section titles; all-caps for micro-labels with 0.12em tracking. Headlines run large and flush-left, never centred.
• Body: Source Serif 4.
• Type scale: 1.333 modular — 64 / 48 / 36 / 24 / 18 / 16.
• Body 18px with 1.65 line-height on the reading half; 14px tabular on the code half.

Shape language: Sharp corners (2px radius maximum) on plan sheets and code panels, with a single 1px ink rule acting as the seam between halves. Buttons are rectangular with a 3px offset shadow in accent. No pills, no blobs, no soft cards; the only rounded element is the small circular avatar chip in the nav.

Layout: A persistent two-column split on the Plan Editor and Business Plan pages — left half the editorial document at a single-column reading measure (68ch), right half the technical panel on a dark ink surface with monospace numerals, financial tables, and stack diagrams. On mobile the split becomes a stacked pair with a labelled seam tab that toggles between 'Prose' and 'Code'. The Landing page uses the same split as its hero, so the product's identity is established before sign-up.

Imagery: No stock photography. The visual content is the product itself — a rendered split-screen showing a plan paragraph on the left and its matching JSON schema on the right, plus small diagrams of the AI website delivery pipeline (brief → generation → review → deploy) drawn as 1px ink line art. One portrait of the founder half-rendered as a wireframe, used once on the Landing page.

7. Signature Design Concept

The public entry is a full-viewport split that is the product's thesis rendered as layout.

The left half is warm paper (#F4F2ED) carrying an Archivo headline at 72px–128px — "A business plan for building websites with AI" — set flush-left, three lines deep, with the primary CTA pinned beneath it as an accent rectangle with a 3px offset shadow. The right half is a deep ink (#0E1B2A) panel showing the same plan as a live JSON document with monospace numerals and a blinking cursor. A 1px accent (#E4572E) vertical seam runs the full height of the viewport between them, and the cursor highlights it as it moves.

The concept recomposes only accepted content: the headline states the product's purpose, the CTA leads to the accepted identity-access surfaces, and the JSON panel illustrates the plan's structured half. No centred headline, no gradient, no blue button. On mobile the split stacks and the sticky labelled seam tab ('Prose' / 'Code') preserves the dual-nature idea at 375px.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: restrained Hero Dimensionality: layered_2d

Landing Hero Motion Brief

• Focal subject: the 1px accent seam between the paper half and the ink half, with the JSON document on the ink side as its counterpart.
• Input → transformation → outcome thesis: as the visitor moves the cursor, the accent seam tracks the pointer across the split and highlights the boundary; the JSON panel's blinking cursor continues its own rhythm. The outcome is that the visitor perceives the product's dual nature — prose and schema — before any identity is established.
• Motion vocabulary: 180ms ease-out reveals on scroll; a cursor-following accent highlight that tracks across the seam; a 120ms crossfade when toggling Prose/Code on mobile. No bounce, no particles.
• Composed first frame: the paper half with the flush-left headline and the accent CTA on the left, the ink JSON panel with its blinking cursor on the right, and the accent seam running the full viewport height between them.
• Reduced-motion state: all motion collapses to instant state changes with no cursor tracking; the seam remains visible as a static 1px accent rule and the JSON panel renders without the blinking cursor.

9. Non-Functional Requirements

NFR-1 — Readable text and controls stay whole at every viewport (explicit, from creative direction) Headlines, wordmarks, labels, numbers, cards' text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, and no other element may cover any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the direction asks, as long as they cover no readable text or control. Where the direction asks readable text or a control to be cropped, clipped, covered, or run off an edge, the text or control is kept whole and the gesture is carried by imagery or decoration instead; for readable text and controls this rule takes precedence.

NFR-2 — Reduced motion (explicit, from creative direction) With prefers-reduced-motion, motion stops and shows whole items: moving or scrollable content wraps into rows or sits in a horizontally scrollable row (overflow-x: auto) whose further items are reached by scrolling. The hero collapses to instant state changes with no cursor tracking.

NFR-3 — No blue or indigo accent (explicit, from creative direction) The generic indigo/blue-on-white SaaS template is forbidden for this project. The ink is near-black navy (#0E1B2A) and the only hot colour is burnt orange (#E4572E).

NFR-4 — Durable plan persistence (required_inference) The business plan and its sections must persist against the author's account so that the author can resume editing and the reviewer can read the completed plan across sessions. Rationale: the accepted journeys require resuming protected plan work and reading a completed plan, which is only possible if the plan is durable.

NFR-5 — Access protection for the plan (required_inference) The Plan Editor must be reachable only by an authenticated author, and the Business Plan page only by an authenticated author or reviewer. Rationale: the accepted journeys require that the plan be bound to the correct participant and that the reviewer receive authorized access before reading.

NFR-6 — Backend integration (explicit, from planning scope) The application requires backend integration to support identity, session continuity, and durable plan storage.

10. Tech Stack

No technology choices are specified by the user. The following are coherent defaults for the accepted scope, labeled as defaults.

• Frontend: React — a single-page web application serving the five accepted pages. [Default — not specified by user]
• Backend: Python with FastAPI — serving identity, session continuity, and durable plan persistence. [Default — not specified by user]
• Storage: A relational database for accounts, sessions, plans, and plan sections. [Default — not specified by user]
• Containerization: Docker and docker-compose for local and single-host deployment. [Default — not specified by user]
• Orchestration: Kubernetes is not required by the accepted scope and is not included. [Default — not specified by user]

11. Assumptions and Constraints

Assumptions

• A1: The business plan is a single durable plan owned by the author's account. The source describes "a business plan," not a collection of plans. (required_inference)
• A2: The plan's sections are the core content areas implied by the request — offering, target market, operations, pricing, and financial content. (explicit for offering, target market, and financial outlook; required_inference for operations and pricing as the remaining core areas of a business plan for a service business)
• A3: The author and reviewer are distinct roles over the same plan; the author writes and the reviewer reads. (required_inference)
• A4: Self-service enrollment is the identity-establishment path, because the source establishes no invitation, provisioning, provider, or pre-existing-account boundary. (required_inference)
• A5: The reviewer's account is established through the same self-service enrollment as the author's, and authorized access to the Business Plan page follows from the reviewer role. (required_inference)

Constraints

• C1: The Plan Editor is restricted to the Business Plan Author. (explicit, from planning scope)
• C2: The Business Plan page is restricted to the Business Plan Author and the Plan Reviewer. (explicit, from planning scope)
• C3: The Landing, Sign Up, and Login pages are anonymously reachable. (explicit, from planning scope)
• C4: No blue or indigo accent anywhere in the interface. (explicit, from creative direction)
• C5: No stock photography of people at laptops; no gradient blobs, glassmorphism, or frosted panels; no identical hover-lift cards in a grid; no pill buttons or 16px+ corner radii; no Inter, Roboto, Poppins, or system-ui for headings or body. (explicit, from creative direction)
• C6: No invitation-based or provisioned enrollment, no provider-owned identity, and no adjacent account-management capabilities beyond first-use identity establishment and returning verification. (explicit, from planning scope)
• C7: No future-horizon requirements are established by the source; nothing in this document commits the product to capabilities beyond authoring, assembling, and reading the business plan. (explicit, from planning scope)

12. Glossary

• Business plan — the durable artefact the author produces: a document covering the offering, target market, operations, pricing, and financial outlook for a business that builds fullstack websites using AI.
• Plan section — one of the plan's core content areas: offering, target market, operations, pricing, or financial content.
• Editorial half — the left column of the split layout, presenting plan content as prose at a single-column reading measure (68ch).
• Technical half — the right column of the split layout, a dark ink surface presenting the plan's structured content, financial tables, and stack diagrams with monospace numerals.
• Seam — the 1px accent vertical rule between the editorial and technical halves; interactive on the Plan Editor and Business Plan pages, where dragging it rebalances the two columns.
• Prose / Code tab — the sticky labelled seam tab shown on narrow viewports that swaps the two halves with a 120ms crossfade.
• Business Plan Author — the active human persona who writes and finalizes the plan.
• Plan Reviewer — the active human persona who reads the finished plan and judges its credibility.
• Returning verification — the Login interaction by which a returning participant verifies identity and resumes their protected journey.
• Self-service enrollment — the Sign Up interaction by which a participant establishes an account without invitation or provisioning.