System Requirements Document for founders-due-diligence

1. Introduction

founders-due-diligence is a platform where founders run a full due diligence on their own businesses and receive guidance on where to improve before approaching funders and investors. The product is a diagnostic instrument: it examines a business across investor-critical dimensions, produces findings, and tells the founder where the business is weak so that the founder can fix those weaknesses before entering a fundraising conversation.

The audience is founders of early-stage and growth-stage companies preparing for fundraising. They are analytical, time-poor, and skeptical of flattery. They do not want encouragement; they want an objective, methodical read of their business that anticipates what a funder or investor would find.

The product intent, stated plainly: a founder should be able to start a due diligence assessment, work through it to completion, see the findings it produces, and receive guidance on where to improve — all before approaching funders and investors.

2. System Overview

founders-due-diligence is delivered as a first-party web application with application-owned identity and custom UI. A founder reaches an anonymous Landing page, establishes or verifies access through Login, and then works inside authenticated destinations: a Dashboard that gives an overview and continuation point, an Assessments list of durable assessments, a New Assessment workspace where a full due diligence is run to completion, a Findings view of what the completed due diligence produced, and a Guidance view of where the founder should improve.

Actors:

• Founder — the sole active human persona. A founder runs a full due diligence on their own business, reviews the resulting findings, and receives guidance on where to improve so they are better prepared before approaching funders and investors.
• Application (system) — owns identity, persistence of assessment progress, completed findings, and improvement guidance, and generates findings and guidance from a completed assessment.
• Funders and investors — named in the source only as the audience the founder is preparing to approach. They are not users of the platform, do not receive anything from it, and have no surface, account, or interaction in this product.

Current scope is exactly: run a full due diligence on a business; receive findings from it; receive guidance on where to improve; persist progress, findings, and guidance for later review; and let a founder enroll and return. Nothing else is in scope.

2a. Product Interpretation and Delivery Boundary

The platform is a self-service diagnostic tool owned and delivered entirely by the application. There is no provider-owned surface, no external destination, and no headless delivery in the accepted scope. Every destination a founder uses is a first-party page.

Access is split at one boundary. Landing is anonymously reachable: it explains the platform, its due diligence purpose, and its role in preparing a founder to approach funders and investors, and it is the entry point from which a founder begins. Login is also anonymously reachable, because it is the interaction that establishes access to everything else — a protected destination cannot own the interaction that grants access to itself. Login carries both self-service enrollment for a founder starting fresh and verification for a returning founder resuming existing assessments and guidance. Dashboard, Assessments, New Assessment, Findings, and Guidance are all protected and require a verified founder identity, because each of them reads or writes durable founder-specific state: assessment progress, completed findings, and improvement guidance.

Identity is application-owned because a founder must privately own and resume durable, founder-specific assessment state, and because completed findings and guidance must remain bound to the correct founder across sessions. This is the minimum continuity the accepted journeys require; it does not extend to any adjacent account-management capability.

Funders and investors are outside the delivery boundary. The platform prepares a founder to approach them; it does not contact them, share with them, or produce anything addressed to them.

Everything described in this document is current. No future-horizon requirements were accepted.

2b. Source Content Inventory

Not applicable. No reference directive in this request declares content_source, so no source content inventory is included.

2c. Page Content and Component Coverage

Landing

• Information and state. Anonymous public entry. Explains what the platform is for: founders running a full due diligence on their businesses and getting guidance on where to improve before approaching funders and investors. Presents the product as an objective diagnostic instrument, not a coach.
• Primary action. Begin — move into the access flow to start a due diligence.
• Supporting actions. Read the explanation of the due diligence purpose and the preparation-for-fundraising framing; move into the access flow as a returning founder.
• Domain entities. None persisted. This page holds no founder-specific state.
• Component responsibilities. Full-viewport asymmetric hero composition on the warm off-white ground; stacked flush-left headline; a 1px black rule spanning the headline column; a single line of body copy describing the structured assessment; one solid primary CTA pinned flush-left to the headline column; a vertical stack of three geometric shapes in the right column acting as visual counterweight; a ruled band carrying a small all-caps page label and two-digit page number.
• States. Loading: static content, no data fetch, no loading state required. Empty: not applicable — the page has no collection. Success: the founder reads the explanation and enters the access flow. Error: not applicable to page content; if the access flow cannot be reached, the CTA remains visible and retryable. Recovery: the founder can re-invoke the CTA from the same page at any time.

Login

• Information and state. Anonymous access surface. Carries two cohesive purposes in one flow: self-service enrollment for a founder beginning to use the platform, and verification for a returning founder resuming existing assessments and guidance. States which purpose is active.
• Primary action. Submit credentials to enroll or to verify.
• Supporting actions. Switch between enrolling and verifying within the same flow; correct a rejected entry and resubmit.
• Domain entities. Founder identity (application-owned).
• Component responsibilities. Ruled label/value rows for credential entry rather than cards; a single primary submit control; an inline switch between the enroll and verify purposes; inline validation messaging.
• States. Loading: submit control reflects an in-flight submission and blocks duplicate submission. Empty: initial state shows empty credential fields with the active purpose labeled. Success: the founder is verified and continues into the authenticated area. Error: invalid or incomplete credentials produce an inline message identifying what must be corrected, with the entered values preserved where safe. Recovery: the founder corrects the entry and resubmits, or switches purpose, without losing their place.

Dashboard

• Information and state. Protected. Overview and continuation point for the founder's due diligence work: their assessments, their status, their scores, and their last-updated dates, plus the route into findings and guidance.
• Primary action. Open an assessment to continue or review it.
• Supporting actions. Start a new assessment; move to the full Assessments list; move to Findings; move to Guidance.
• Domain entities. Assessment (name, date, score, status, last updated); Founder identity.
• Component responsibilities. A ruled table-like grid of assessment status, score, and last-updated date — not a card grid; each assessment is a row with columns for name, date, score as a large numeral, status as an all-caps label, and a flush-right open link; geometric pictograms marking assessment dimensions; a ruled band with page label and page number.
• States. Loading: the ruled grid renders with its structure and indicates that assessment rows are being retrieved. Empty: a founder with no assessments sees the ruled grid structure with an explicit no-assessments state and the route to start one. Success: assessment rows render with name, date, score, status, and last-updated date. Error: if assessments cannot be retrieved, the page states the failure and offers retry without discarding the founder's session. Recovery: retry reloads the grid; the founder can still start a new assessment.

Assessments

• Information and state. Protected. The founder's durable due diligence assessments, listed and revisitable.
• Primary action. Open an existing assessment to revisit it.
• Supporting actions. Start a new assessment; return to the Dashboard.
• Domain entities. Assessment (name, date, score, status, last updated); Founder identity.
• Component responsibilities. Ruled rows of assessments with aligned label/value pairs; status and score presented in the signal colour system; geometric pictograms per assessment dimension; ruled band with page label and page number.
• States. Loading: ruled list structure renders while assessments are retrieved. Empty: no assessments yet — explicit empty state with the route to start one. Success: every assessment the founder owns is listed and openable. Error: retrieval failure is stated with a retry action. Recovery: retry; the founder can also start a new assessment instead.

New Assessment

• Information and state. Protected. Focused workspace where a founder runs a full due diligence on their business and reaches a completed assessment. Holds the assessment's in-progress answers and its completion state.
• Primary action. Answer the due diligence questions and complete the assessment.
• Supporting actions. Move between questions and dimensions; leave and return later with progress preserved; submit the completed assessment.
• Domain entities. Assessment (in progress → completed); Assessment dimension; Question; Answer; Founder identity.
• Component responsibilities. Questions rendered as ruled label/value rows — question label flush-left in all-caps, answer control flush-right — so the assessment reads as one continuous form on the grid, not a stack of tiles; a progress bar that fills in linear increments; geometric pictograms marking each dimension; a ruled band with page label and page number; a completion control that becomes available when the assessment is complete.
• States. Loading: the assessment form renders its ruled structure while the founder's saved progress is retrieved. Empty: a newly started assessment shows all questions unanswered with progress at its starting position. Success: answers are accepted, progress advances, and on completion the assessment is marked completed and its findings become available. Error: an answer or submission that cannot be saved is reported inline against the affected row, with the founder's entered answer preserved. Recovery: the founder retries the save or submission; previously saved progress is retained so no completed work is lost.

Findings

• Information and state. Protected. The findings generated from the founder's completed due diligence, presented as a scored, colour-coded list.
• Primary action. Read the findings for a completed assessment.
• Supporting actions. Move to Guidance for the same assessment; return to the assessment or the Assessments list.
• Domain entities. Finding (dimension, severity, score, description); Assessment; Founder identity.
• Component responsibilities. Finding rows colour-coded by a strict three-colour signal system — critical findings carry a red left border and red score numerals, caution findings a yellow left border and yellow score numerals, pass findings a green left border and green score numerals, with no other colour used in the list; findings revealed in a staggered left-to-right sequence; geometric pictograms per dimension; ruled band with page label and page number.
• States. Loading: the findings list renders its ruled structure while findings are retrieved. Empty: an assessment that is not yet completed has no findings — the page states this and routes the founder back to complete the assessment. Success: findings render with dimension, severity, score, and description. Error: retrieval failure is stated with a retry action. Recovery: retry; the founder can return to the assessment and re-open Findings.

Guidance

• Information and state. Protected. Guidance on where the founder should improve, derived from the due diligence findings for a completed assessment.
• Primary action. Read the improvement guidance.
• Supporting actions. Move to Findings for the same assessment; return to the assessment or the Assessments list.
• Domain entities. Guidance item (dimension, improvement area, recommended action); Finding; Assessment; Founder identity.
• Component responsibilities. Guidance presented as ruled rows aligned to the same grid as findings, with the same signal colour system tying each guidance item to the severity of the finding it addresses; geometric pictograms per dimension; ruled band with page label and page number.
• States. Loading: the guidance list renders its ruled structure while guidance is retrieved. Empty: an assessment that is not yet completed has no guidance — the page states this and routes the founder back to complete the assessment. Success: guidance renders with the improvement area and the recommended action for each dimension. Error: retrieval failure is stated with a retry action. Recovery: retry; the founder can return to Findings or the assessment.

3. Functional Requirements

FR-1 — Run a full due diligence on the founder's business. (explicit) As a Founder, I should be able to run a full due diligence on my business on the platform.

• Trigger/input: the founder starts a new assessment from the authenticated area.
• Observable result: a due diligence assessment exists in progress, covering the full set of investor-critical dimensions, and advances as the founder answers.
• Access state: requires a verified founder identity; the assessment is private to that founder.
• Failure/recovery: if an answer or the assessment cannot be saved, the failure is reported against the affected row and the founder's entered answer is preserved so it can be retried.
• Continuation: the founder can leave and return, with progress preserved, until the assessment is completed.

FR-2 — Reach a completed assessment. (explicit) As a Founder, I should be able to work my due diligence through to completion.

• Trigger/input: the founder answers the remaining questions and submits the assessment.
• Observable result: the assessment is marked completed and its findings become available.
• Access state: requires a verified founder identity.
• Failure/recovery: a submission that cannot be saved is reported and retryable; previously saved progress is retained.
• Continuation: the founder moves to the findings produced by the completed assessment.

FR-3 — See the findings from the due diligence. (explicit) As a Founder, I should be able to see the findings generated from my completed due diligence.

• Trigger/input: the founder opens Findings for a completed assessment.
• Observable result: findings render per dimension with severity, score, and description, colour-coded by the signal system.
• Access state: requires a verified founder identity; findings are private to the founder who owns the assessment.
• Failure/recovery: retrieval failure is stated with a retry action.
• Continuation: the founder moves to Guidance for the same assessment, or back to the assessment.

FR-4 — Get guidance on where to improve. (explicit) As a Founder, I should be able to get guidance on where to improve based on my due diligence, so I am prepared before approaching funders and investors.

• Trigger/input: the founder opens Guidance for a completed assessment.
• Observable result: guidance renders per dimension, naming the improvement area and the recommended action, tied to the severity of the finding it addresses.
• Access state: requires a verified founder identity; guidance is private to the founder who owns the assessment.
• Failure/recovery: retrieval failure is stated with a retry action.
• Continuation: the founder returns to Findings or the assessment, or leaves and resumes later.

FR-5 — Self-service enrollment. (required_inference) As a Founder, I should be able to enroll myself on the platform to begin using it.

• Trigger/input: the founder enters the access flow from Landing and selects the enroll purpose.
• Observable result: a founder identity is established and the founder continues into the authenticated area.
• Access state: the access flow is anonymously reachable; the destinations it grants access to are not.
• Failure/recovery: invalid or incomplete entries produce an inline message identifying what must be corrected, with entered values preserved where safe; the founder corrects and resubmits.
• Continuation: the founder lands in the authenticated area and can start a due diligence.

FR-6 — Returning verification. (required_inference) As a Founder, I should be able to verify myself on return and resume my existing assessments and guidance.

• Trigger/input: the founder enters the access flow and selects the verify purpose.
• Observable result: the founder is verified and their own assessments, findings, and guidance are available again.
• Access state: the access flow is anonymously reachable; the resumed state is private to that founder.
• Failure/recovery: rejected credentials produce an inline message; the founder corrects and resubmits or switches purpose without losing their place.
• Continuation: the founder resumes from the Dashboard or the Assessments list.

FR-7 — Persistent storage of progress, findings, and guidance. (required_inference) As a Founder, I should be able to leave the platform and return later to find my assessment progress, completed findings, and improvement guidance exactly as I left them.

• Trigger/input: the founder saves answers, completes an assessment, or returns in a later session.
• Observable result: in-progress answers, completed assessments, findings, and guidance persist and are bound to the correct founder.
• Access state: requires a verified founder identity; persisted state is private to its owner.
• Failure/recovery: a failed save is reported against the affected row and retryable without losing prior saved state.
• Continuation: the founder resumes from the Dashboard or the Assessments list at any time.

FR-8 — Overview and continuation point. (required_inference) As a Founder, I should be able to see an overview of my due diligence work and continue from it.

• Trigger/input: the founder reaches the authenticated area.
• Observable result: assessments render as ruled rows with name, date, score, status, and last-updated date, each openable.
• Access state: requires a verified founder identity.
• Failure/recovery: retrieval failure is stated with a retry action; the founder can still start a new assessment.
• Continuation: the founder opens an assessment, starts a new one, or moves to Findings or Guidance.

FR-9 — Revisit durable assessments. (required_inference) As a Founder, I should be able to list and revisit my durable due diligence assessments.

• Trigger/input: the founder opens the Assessments list.
• Observable result: every assessment the founder owns is listed and openable.
• Access state: requires a verified founder identity.
• Failure/recovery: retrieval failure is stated with a retry action.
• Continuation: the founder opens an assessment to continue or review it, or starts a new one.

4. User Personas

Founder

Product context. The founder runs an early-stage or growth-stage company and is preparing to approach funders and investors. They are analytical and time-poor, and they are skeptical of encouragement — what they need is an objective read of their own business that anticipates what a funder or investor would find. They come to the platform before a fundraising conversation, not during one.

Primary goal. Complete a full due diligence on their business and come away with a clear picture of where to improve, so they are better prepared before approaching funders and investors.

Distinct accepted responsibilities. The founder is the only human actor, and their work is specific: they start a due diligence assessment on their own business, work it through to completion across the full set of investor-critical dimensions, read the findings it produces, and read the guidance on where to improve. They also own the continuity of that work — enrolling themselves, verifying on return, and resuming assessments, findings, and guidance exactly as they left them.

Relevant inputs and decisions. The founder supplies their own business information as answers to the due diligence questions. Their decisions are which assessment to open or continue, whether an assessment is complete enough to submit, and which improvement areas to act on first based on the guidance.

Interactions with other accepted participants. The founder interacts only with the platform. Funders and investors are named in the source as the audience the founder is preparing to approach; they are not users of the platform, receive nothing from it, and have no account, surface, or interaction in this product. The founder's preparation is entirely self-directed.

Observable success. A completed due diligence with a clear picture of improvement areas: findings rendered per dimension with severity and score, and guidance naming where to improve and what to do — all still available when the founder returns.

5. Core User Flows

Flow 1 — A founder enrolls and runs a first due diligence to completion

1. The founder arrives at Landing anonymously and reads what the platform is for: running a full due diligence on their business and getting guidance on where to improve before approaching funders and investors.
2. The founder activates the primary CTA and enters Login, selecting the enroll purpose.
3. The founder submits their credentials. If an entry is rejected, an inline message identifies what to correct, the founder corrects it, and resubmits without losing their place.
4. On success, a founder identity is established and the founder continues into the authenticated area.
5. The founder reaches Dashboard, which shows the ruled grid of assessments. With no assessments yet, it shows the explicit no-assessments state and the route to start one.
6. The founder starts a new assessment and lands in New Assessment, where the due diligence questions render as ruled label/value rows across the full set of investor-critical dimensions, with progress at its starting position.
7. The founder answers the questions. Progress advances in linear increments. If an answer cannot be saved, the failure is reported against that row and the founder's entered answer is preserved for retry.
8. The founder leaves before finishing. Their progress persists and is bound to them.
9. The founder returns later, enters Login, selects the verify purpose, and is verified. Their in-progress assessment is exactly as they left it.
10. The founder resumes in New Assessment, completes the remaining questions, and submits.
11. The assessment is marked completed and its findings become available. The founder continues to Findings.

Flow 2 — A founder reviews findings from a completed due diligence

1. The founder is verified and opens Findings for a completed assessment, either from Dashboard, from Assessments, or directly after completing the assessment.
2. The findings list renders its ruled structure while findings are retrieved.
3. Findings appear per dimension with severity, score, and description, colour-coded by the signal system: critical findings carry a red left border and red score numerals, caution findings a yellow left border and yellow score numerals, pass findings a green left border and green score numerals. Rows reveal in a staggered left-to-right sequence.
4. If findings cannot be retrieved, the page states the failure and offers retry; the founder retries and the list loads.
5. If the founder opens Findings for an assessment that is not yet completed, the page states that there are no findings yet and routes them back to complete the assessment.
6. The founder reads the findings and continues to Guidance for the same assessment.

Flow 3 — A founder gets guidance on where to improve

1. The founder is verified and opens Guidance for a completed assessment, from Findings, from Dashboard, or from Assessments.
2. The guidance list renders its ruled structure while guidance is retrieved.
3. Guidance appears per dimension, naming the improvement area and the recommended action, tied by the signal colour system to the severity of the finding it addresses.
4. If guidance cannot be retrieved, the page states the failure and offers retry; the founder retries and the guidance loads.
5. If the founder opens Guidance for an assessment that is not yet completed, the page states that there is no guidance yet and routes them back to complete the assessment.
6. The founder reads where to improve and what to do, and leaves with a clear picture of improvement areas — prepared, before approaching funders and investors.
7. The founder can return to Findings or the assessment, or leave and resume later.

Flow 4 — A returning founder resumes existing work

1. The founder returns to the platform and enters Login anonymously, selecting the verify purpose.
2. The founder submits their credentials. If they are rejected, an inline message is shown and the founder corrects and resubmits, or switches purpose, without losing their place.
3. On success, the founder reaches Dashboard, where their assessments render as ruled rows with name, date, score, status, and last-updated date.
4. If assessments cannot be retrieved, the page states the failure and offers retry; the founder retries, or starts a new assessment instead.
5. The founder opens an assessment from the grid, or moves to Assessments to see the full list and open one from there.
6. The founder continues an in-progress assessment in New Assessment, or reviews a completed one through Findings and Guidance — all state exactly as previously saved.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Josef Müller-Brockmann, and the headline idea is Swiss geometric rigour for founders under scrutiny: the visual language of objective systems — grid-locked information, mathematical precision, a refusal to decorate. A due diligence platform is fundamentally a grid of questions, scores, and findings, so the muse's core idiom is the product's core idiom. The register is high-stakes, methodical, and slightly anxious: the product must read as a diagnostic instrument, not a coach.

Colour tokens — light mode

Proportion: 70% off-white ground, 20% black type and rules, 7% red, 3% yellow and green combined. Blue and indigo are forbidden in any form.

Typography

• Family: Archivo for headings, body, and data — the only family in the product.
• Headings: flush-left, ragged-right, weights 600–700, tracking -0.02em, sentence case for section headings, all-caps for micro-labels with +0.08em tracking. No italics, no decorative ligatures.
• Scale: 1.25 modular scale — 64 / 48 / 32 / 24 / 18 / 16 / 14.
• Hero: 96px desktop, 40px mobile. Section headings: 32px desktop, 24px mobile. Body: 16px with 1.6 line-height. Micro-labels: 12px all-caps, +0.08em tracking.

Shape language

• Hard edges only: zero border-radius on all containers, buttons, inputs, and cards. Rectangles and squares are the only shapes.
• Thin 1px black rules divide sections horizontally; 2px black rules frame key data panels.
• Geometric shapes (circles, squares, triangles) appear as content markers, never as decoration.
• Buttons are solid black rectangles with white text, or solid red rectangles with white text for the single primary action per screen.

Layout

• Strict 12-column modular grid, 24px gutters, 48px outer margins on desktop; 4 columns, 16px gutters, 20px margins on mobile.
• Asymmetric composition: a narrow left rail (3 columns) for navigation and metadata, a wide right field (9 columns) for content.
• Every screen carries a visible horizontal rule at the top of the content area with a small all-caps label and a two-digit page number (e.g. 02 — ASSESSMENTS).
• Assessment questions are aligned label/value pairs in ruled rows, not cards. The dashboard is a ruled table-like grid of assessment status, score, and last-updated date, not a card grid.

Imagery

• Abstract geometry only: circles, squares, and triangles as section markers and data indicators. No photography, no illustration, no 3D renders.
• Diagrams are drawn with 1px black lines on the off-white ground.
• The only "image" on the landing page is a large geometric composition — a red square, a black circle, and a yellow triangle arranged on the grid.
• Assessment dimension pictograms are simple geometric marks drawn in 2px black stroke — circle, square, triangle, half-circle, cross, chevron, ring, dot — used consistently across Dashboard, New Assessment, and Findings.

Avoid

• Any border-radius greater than 0px.
• Blue or indigo in any form.
• Card grids with hover-lift or drop shadows of any kind; depth comes from rules and colour blocks, not elevation.
• Centred hero compositions or centred headlines — everything is flush-left on the grid.
• Gradient fills, glassmorphism, translucent panels — surfaces are opaque and flat.
• Photography, stock imagery, or 3D renders.
• Decorative motion: bounces, fades, parallax, or anything that draws attention to itself rather than the content.
• Rounded or friendly display typefaces — Archivo only.

Readable text and controls. Headlines, wordmarks, labels, numbers, and card text and controls 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 covers any part of them. Imagery, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut exactly as the direction asks, as long as they cover no readable text or control.

7. Signature Design Concept

The public entry is a full-viewport asymmetric composition on the warm off-white ground (#F4F2ED), built on the 12-column grid with 48px outer margins.

The left 9 columns carry a stacked headline in Archivo 700 at 96px desktop / 40px mobile, flush-left and ragged-right:

RUN THE DUE DILIGENCE. BEFORE THEY DO.

The second line is set in signal red (#D42A1E). Below the headline, a 1px black rule spans the full 9 columns. Beneath the rule, a single line of 18px body copy: "A structured assessment of your business across 8 investor-critical dimensions." The CTA is a solid black rectangle, 240px wide and 56px tall, pinned flush to the left edge of the headline column, reading START ASSESSMENT in 14px all-caps white text.

The right 3 columns hold a vertical stack of three geometric shapes — a red square, a black circle, a yellow triangle — each 80px, aligned to the top of the headline, acting as a visual counterweight.

No gradient, no blob, no centred composition. The composition reads as a printed system, not a web app: the headline states the founder's own task, the rule and body copy state the instrument's scope, and the single CTA is the only action on the screen. The concept recomposes only accepted content — the platform's purpose, its due diligence scope, and the entry into the access flow — and introduces no new behaviour, page, or destination.

8. Interaction Model & Motion Direction

Interaction Model: Static Motion Tempo: restrained Hero Dimensionality: flat

Landing Hero Motion Brief

• Focal subject: the asymmetric hero composition — the stacked flush-left headline with its red second line, the 1px rule and body copy beneath it, the single black CTA, and the right-column stack of a red square, a black circle, and a yellow triangle.
• Input → transformation → outcome thesis: the founder's arrival composes the first frame; the only transformation is the 120ms horizontal rule wipe from left to right as the page settles, after which the composition is still. Nothing moves in response to hover or scroll. The outcome is a founder reading the platform's purpose and activating the single CTA into the access flow.
• Motion vocabulary: geometric and precise. Instant swaps. A 120ms horizontal rule wipe from left to right on page transition. Hover states are instant colour inversions (black to red, white to black) with no transition. No bounces, no fades, no parallax.
• Composed first frame: the full-viewport composition described in Section 7, fully legible at 375px, 768px, and 1280px, with the headline, body copy, and CTA entirely inside the viewport and their containers.
• Reduced-motion state: with prefers-reduced-motion, the rule wipe is omitted and the composition renders as a static arrangement. All content, the CTA, and every control remain fully visible and usable; nothing depends on motion to become readable.

Motion across authenticated screens. Page transitions are instant swaps with the 120ms horizontal rule wipe. Assessment progress bars fill in 200ms linear increments with no easing curve. Findings reveal in a staggered sequence: each finding row slides in from the left in 80ms steps, offset by 40ms. Hover states are instant colour inversions with no transition. With prefers-reduced-motion, the staggered reveal is replaced by a static list in which every finding row is fully readable.

9. Non-Functional Requirements

NFR-1 — Objective, non-flattering register. (explicit, from creative direction) The interface must read as a diagnostic instrument, not a coach. Copy and presentation must not flatter the founder; findings and guidance are stated objectively. Rationale: the audience is analytical and skeptical of encouragement.

NFR-2 — Grid-locked legibility. (explicit, from creative direction) All content must sit on the 12-column desktop / 4-column mobile grid with the specified gutters and margins. Every screen carries the ruled band with an all-caps page label and two-digit page number. Rationale: the interface must read like a printed system.

NFR-3 — Strict signal colour discipline. (explicit, from creative direction) Red is reserved for critical findings, the active navigation bar, and the single primary CTA per screen. Yellow is reserved for caution states and the assessment progress bar. Green is reserved exclusively for pass findings and must not be used decoratively. Blue and indigo are forbidden. Rationale: findings must read as wayfinding, not decoration.

NFR-4 — Zero border-radius, no elevation. (explicit, from creative direction) No border-radius greater than 0px on any container, button, input, or card. No drop shadows or hover-lift. Depth comes from rules and colour blocks only.

NFR-5 — Readable text and controls at every viewport. (explicit, from creative direction) Headlines, wordmarks, labels, numbers, and card text and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit, with no other element covering any part of them. Imagery and decoration may be cropped or bled off an edge; readable text and controls may not.

NFR-6 — Reduced-motion usability. (explicit, from creative direction) With prefers-reduced-motion, provide a usable static arrangement: the rule wipe and staggered finding reveal are omitted, and every item remains fully readable and every control fully usable.

NFR-7 — Private, founder-bound durable state. (required_inference) Assessment progress, completed findings, and improvement guidance must persist and remain bound to the founder who owns them, and must not be reachable without a verified founder identity. Rationale: the accepted journeys require a founder to leave and resume their own work, and findings and guidance are founder-specific.

NFR-8 — No loss of completed work on failure. (required_inference) A failed save or submission must not discard previously saved progress or the founder's currently entered answer. Rationale: a full due diligence is long-running work; losing it would make the accepted journey unusable.

10. Tech Stack

No technology choices were specified by the user. The following are coherent defaults for the accepted delivery shape — a first-party web application with application-owned identity, custom UI, and backend integration — and are labeled as defaults.

• Frontend: React. [Default — not specified by user]
• Backend: Python with FastAPI. [Default — not specified by user]
• Storage: A relational database for founder identities, assessments, answers, findings, and guidance. [Default — not specified by user]
• Packaging and local orchestration: Docker and docker-compose. [Default — not specified by user]
• Deployment: Kubernetes is not required by any accepted requirement and is not included. [Default — not specified by user]
• Typography: Archivo, self-hosted or served as a webfont. (explicit, from creative direction)

11. Assumptions and Constraints

Assumptions

• A1. The founder runs the due diligence on their own business; no third party supplies answers on their behalf. (Source: the source names founders running due diligence on their businesses.)
• A2. The due diligence covers a defined set of investor-critical dimensions, presented as a structured assessment. (Source: the creative direction's hero copy names "8 investor-critical dimensions" and its pictogram list names eight geometric marks.)
• A3. Funders and investors are the audience the founder prepares to approach; they are not users, recipients, or participants in the platform. (Source: the source names them only as the party the founder approaches after preparing.)
• A4. Application-owned identity is the minimum continuity required for a founder to privately own and resume durable assessment state, findings, and guidance. (required_inference)
• A5. Self-service enrollment and returning verification are carried in one cohesive access flow, since both are the same interaction of establishing a verified founder identity. (required_inference)

Constraints

• C1. The platform must let a founder run a full due diligence on their business. (explicit)
• C2. The platform must give the founder guidance on where to improve, so they are prepared before approaching funders and investors. (explicit)
• C3. Dashboard, Assessments, New Assessment, Findings, and Guidance require a verified founder identity. Landing and Login are anonymously reachable. (from the page contract)
• C4. No border-radius greater than 0px; no blue or indigo; no drop shadows or hover-lift; no gradients, glassmorphism, or translucent panels; no photography, stock imagery, or 3D renders; no centred hero compositions; no decorative motion; Archivo is the only typeface. (explicit, from creative direction)
• C5. The generic indigo/blue-on-white SaaS template is forbidden for this project. (explicit, from creative direction)
• C6. No future-horizon requirements were accepted; everything in this document is current scope.

12. Glossary

• Due diligence — the structured assessment a founder runs on their own business across investor-critical dimensions, producing findings and improvement guidance.
• Assessment — a single due diligence run by a founder, with a name, date, score, status, and last-updated date; it moves from in progress to completed.
• Dimension — one investor-critical area of the due diligence, marked by a geometric pictogram and carrying its own questions, findings, and guidance.
• Finding — a result produced by a completed assessment for a dimension, with a severity (critical, caution, or pass), a score, and a description.
• Guidance — the improvement direction derived from a completed assessment's findings, naming the improvement area and the recommended action per dimension.
• Founder — the sole active human persona; the owner of the business being assessed and of the resulting assessments, findings, and guidance.
• Funder / investor — the party a founder prepares to approach after improving; not a user of the platform.
• Signal system — the strict three-colour coding of findings: red for critical, yellow for caution, green for pass, with no other colour used in the findings list.