System Requirements Document for indian-business-market

1. Introduction

indian-business-market is a research-to-decision-to-SaaS product for Indian founders and small-business operators. It delivers a ranked research dossier of the ten most significant problems facing Indian businesses — the problems business owners are demonstrably willing to pay to solve — presents that report for review, captures the requester's commitment to exactly one problem, and then provides a full-stack SaaS product (frontend, backend, UI/UX, payment integration, and pricing) built to solve the chosen problem.

The product intent is analytical confidence: the user must be able to trust the ranking, compare ten candidates without fatigue, and feel the weight of committing to one. The audience is the business owner/founder who commissions and evaluates the research and commits to a problem, and the small-business operator who uses the resulting SaaS workspace to carry out the solved workflow and subscribes through pricing and payment.

The specific problem and the solution scope of the SaaS are not yet determined — they are established only after the requester chooses one problem from the report. This document therefore specifies the research report, the selection commitment, the identity and access boundaries, the pricing and payment surfaces, and the workspace shell whose concrete workflow is bound to the chosen problem.

2. System Overview

The current delivery is a first-party web application with an application-owned identity boundary and custom UI, backed by a server-side API and durable storage.

Actors

• Business owner / founder (human persona) — reviews the ranked research report, compares the ten problems, and commits to exactly one problem that the SaaS will solve.
• SaaS end user (small business operator) (human persona) — uses the SaaS frontend to carry out the workflow that solves the chosen problem, and subscribes through pricing and payment.
• Payment provider (external, non-persona) — processes subscription payments initiated from Billing.
• Application backend (system, non-persona) — persists the report, the selection commitment, subscription state, and workspace data; enforces protected access.

Accepted behavior

• A research report analyzing the Indian business market, identifying the ten most significant problems businesses face that owners are willing to pay to solve.
• Presentation of that report to the requester for review and choice.
• Commitment to exactly one problem from the report, held as durable state.
• A SaaS product built on the chosen problem, including frontend, backend, UI/UX, payment integration, and pricing.
• Self-service enrollment and returning verification so protected report, selection, workspace, and billing state can be reached and resumed.
• A pricing plan chosen and payment completed before paid workspace access.

Narrow exclusions

• The SaaS solution scope (the specific problem and its workflow) is not determined in this document; it is bound only after the selection commitment.
• No adjacent account-management capabilities (profile editing, team administration, role management) are introduced; identity exists only to establish and resume the accepted journeys.
• No differentiated permissions or role-based visibility are established; both personas share the same application identity model.

2a. Product Interpretation and Delivery Boundary

This product is delivered as a first-party web application with its own identity boundary. A visitor arrives anonymously at the Landing page, which explains the research-to-SaaS proposition. Because the report, the selection commitment, the workspace, and the billing relationship are durable, actor-specific states that must be privately owned and resumed, the application owns identity: a new user establishes access through self-service Sign Up, and a returning user verifies through Login. The Landing, Sign Up, Login, and Pricing surfaces are anonymously reachable; the Market Report, Problem Selection, Workspace, and Billing surfaces require login.

The current horizon covers the research report, the problem selection commitment, the pricing and payment path, and the workspace shell for the chosen problem. The concrete workflow inside the Workspace is determined by the problem the requester selects and is therefore a downstream commitment rather than a currently fixed capability. Payment processing is owned by an external payment provider; the application owns the pricing presentation, the plan choice, the payment initiation, and the resulting subscription state.

2b. Source Content Inventory

Not applicable — no reference directive declares a content_source.

2c. Page Content and Component Coverage

Landing

• Information/state: Anonymous public entry. Explains the research-to-SaaS product, its audience (Indian founders and small-business operators), and what it does: a ranked dossier of ten monetizable market problems, a committed choice, then a paid SaaS workspace. Presents the headline "TEN PROBLEMS. ONE CHOICE." and the schematic problem map.
• Primary actions: Begin self-service enrollment (to Sign Up); verify an existing identity (to Login); view pricing (to Pricing).
• Supporting actions: Read the proposition and the ten-problem framing; follow the wayfinding code legend.
• Domain entities: The ten-problem set (labels, ranks, category codes) as a schematic preview only — no report detail is exposed anonymously.
• Component responsibilities: Full-viewport schematic map (ten labelled horizontal lines in the four code colours converging into one vermilion line ending at a black square labelled "your choice"); 9-column stacked headline; hard black rectangular CTA with uppercase 11px label aligned to the grid; faint 1px black grid on warm paper ground.
• States: Loading (map and headline render immediately; no data dependency beyond static framing); Empty (not applicable); Success (map and CTA fully rendered); Error (if the schematic fails to render, the headline and CTA remain fully readable and functional); Recovery (CTA remains reachable at all viewports).

Sign Up

• Information/state: Anonymous first-use enrollment. Collects the minimum identity fields needed to establish an application-owned identity and begin the protected journey.
• Primary actions: Submit enrollment to create the identity and proceed to the Market Report.
• Supporting actions: Navigate to Login if an identity already exists.
• Domain entities: User identity (credential and identifying fields).
• Component responsibilities: Ruled form fields with zero radius and 1px black rules; uppercase 11px labels; submit control as a hard black rectangle; inline validation messaging in muted grey.
• States: Loading (submit disabled with a progress indication); Empty (blank form with labels); Success (identity created, redirect to Market Report); Error (duplicate identity, invalid or missing field — field-level message, form preserved); Recovery (correct and resubmit without losing entered values).

Login

• Information/state: Anonymous returning verification. Accepts existing credentials to restore access to protected report, selection, workspace, and billing state.
• Primary actions: Submit credentials to verify and resume the protected journey.
• Supporting actions: Navigate to Sign Up if no identity exists.
• Domain entities: User identity (credential).
• Component responsibilities: Ruled credential fields; uppercase 11px labels; hard black submit control; error region above the form.
• States: Loading (submit disabled with progress indication); Empty (blank form); Success (verified, redirect to the last protected destination or Market Report); Error (invalid credentials — generic message, no field disclosure); Recovery (retry; link to Sign Up).

Market Report

• Information/state: Protected, durable, revisitable research report of the ten most significant monetizable problems in the Indian business market, with enough detail to compare them. Each entry carries rank, willingness-to-pay band, sector, effort, a prose body, and a bold pull-quote. Persistent left rail renders the ten problems as a numbered transit line with colour-coded dots and a black connector rule.
• Primary actions: Read and compare entries; move to Problem Selection to commit.
• Supporting actions: Navigate the rail between the ten problems; revisit the report at any time.
• Domain entities: Report entry (rank, problem label, category code, willingness-to-pay band, sector, effort, prose body, pull-quote).
• Component responsibilities: Left rail (numbered 1–10 transit line, colour-coded dots, active problem marked by vermilion ring and 8px slide); ruled specimen sheet per entry (3-column metadata block separated by a vertical 1px rule from a 6-column prose body); black numbered station badge; section header rule that draws left-to-right in 200ms on entry into viewport; mobile sticky horizontal scrolling number ticker.
• States: Loading (rail skeleton with numbered placeholders); Empty (not applicable — the report always contains ten entries); Success (all ten entries readable, active entry marked); Error (entry content fails to load — ruled error row with retry, rail remains navigable); Recovery (retry reloads the entry without losing rail position).

Problem Selection

• Information/state: Protected commitment surface. Presents the ten problems for a single choice and holds the durable selection state. Before selection, no problem is committed; after selection, exactly one is committed and the SaaS scope is bound to it.
• Primary actions: Select exactly one problem and confirm the commitment.
• Supporting actions: Return to the Market Report to re-read an entry before committing.
• Domain entities: Selection commitment (selected problem reference, commitment timestamp, committing identity).
• Component responsibilities: Ten ruled rows with colour chips and numbered station badges; commitment moment where the chosen line thickens to 6px and every other line dims to 30% opacity; full-width black bar reading "SELECTED — 01 OF 10" in 11px uppercase letterspacing; confirmation control as a hard black rectangle.
• States: Loading (rows render with disabled confirmation); Empty (no selection yet — confirmation disabled); Success (commitment recorded, black bar shown, continuation to Workspace/Pricing offered); Error (commitment fails to persist — explicit message, prior state preserved, retry available); Recovery (retry the commitment; the previously selected problem remains visible).

Workspace

• Information/state: Protected recurring working surface for the SaaS end user (and the business owner) to carry out the workflow that solves the chosen problem. Scope is bound to the committed problem; until a problem is committed, the workspace has no bound workflow.
• Primary actions: Carry out the workflow that solves the chosen problem.
• Supporting actions: Reach Billing to manage the subscription; return to the Market Report or Problem Selection to review the committed choice.
• Domain entities: Committed problem reference; workspace records produced by the solved workflow.
• Component responsibilities: Ruled workspace frame consistent with the report's grid; committed-problem header with its category colour chip and station badge; workflow region bound to the chosen problem; subscription status indicator linking to Billing.
• States: Loading (ruled frame with placeholder rows); Empty (no problem committed — prompt to complete Problem Selection; or committed but no workspace records yet — ruled empty state with the first action); Success (workflow records visible and actionable); Error (workflow action fails — inline ruled error with retry, entered data preserved); Recovery (retry the failed action; navigate to Billing if the failure is subscription-related).

Pricing

• Information/state: Anonymous public pricing surface presenting the SaaS plans required by the accepted constraint so prospective subscribers can evaluate cost. Rendered as a transit fare table: three ruled rows, label left and rupee figure right in tabular numerals, plan names in uppercase small caps.
• Primary actions: Choose a plan and proceed to Billing to complete payment.
• Supporting actions: Compare plan rows; return to Landing.
• Domain entities: Pricing plan (name, rupee price, included scope).
• Component responsibilities: Three ruled rows with hairline rules; tabular numerals for rupee figures; recommended plan marked only by a vermilion left rule and a black "RECOMMENDED" tag; four-colour wayfinding code reused for category labelling.
• States: Loading (ruled rows with placeholder figures); Empty (not applicable — three plans always presented); Success (all three plans readable with figures aligned right); Error (plan data fails to load — ruled error row with retry); Recovery (retry reloads plan rows).

Billing

• Information/state: Protected payment and subscription surface. Owns the required payment integration and subscription management for operators subscribing to the SaaS. Shows current subscription state and payment history.
• Primary actions: Initiate payment for the chosen plan through the payment provider; complete the subscription.
• Supporting actions: Review subscription status and payment records; return to Pricing to change plan choice.
• Domain entities: Subscription (plan reference, status, start/renewal dates); Payment record (amount, currency, status, provider reference).
• Component responsibilities: Ruled subscription summary; plan and rupee figure in tabular numerals; hard black payment control; provider handoff region; payment status rows with hairline rules.
• States: Loading (subscription summary skeleton); Empty (no subscription yet — plan choice prompt linking to Pricing); Success (payment completed, subscription active, confirmation shown); Error (payment declined or provider unavailable — explicit message, subscription remains inactive, retry available); Recovery (retry payment; return to Pricing to change plan).

3. Functional Requirements

FR-1 — Produce the market research report (explicit) As a business owner / founder, I should receive a research report analyzing the Indian business market that identifies the 10 most significant problems businesses face and that business owners are willing to pay to solve, so that I can evaluate where a SaaS product is worth building.

• Trigger/input: the product's research corpus on the Indian business market.
• Observable result: a durable report containing exactly ten problem entries, each with rank, willingness-to-pay band, sector, effort, prose body, and pull-quote.
• Access state: protected (login required) on the Market Report page.
• Failure/recovery: if an entry fails to load, a ruled error row with retry appears and the rail remains navigable.
• Continuation: the founder proceeds to compare entries and to Problem Selection.
• Acceptance: the Market Report presents ten distinct, ranked, comparable entries.

FR-2 — Present the report for review and choice (explicit) As a business owner / founder, I should be able to review the presented report and choose one problem from it, so that the SaaS scope is grounded in my own decision.

• Trigger/input: opening the Market Report after verification.
• Observable result: all ten entries are readable and comparable; the founder can move to Problem Selection.
• Access state: protected.
• Failure/recovery: entry load failure shows a retryable ruled error row.
• Continuation: the founder commits a selection on Problem Selection.
• Acceptance: every entry is fully readable and the path to selection is available.

FR-3 — Commit to exactly one problem (required_inference) As a business owner / founder, I should commit to exactly one problem from the report, so that the SaaS product scope is determined by a durable, unambiguous decision.

• Trigger/input: selecting one of the ten problems and confirming.
• Observable result: a durable selection commitment is recorded; the chosen line thickens to 6px, the others dim to 30%, and a full-width black bar reads "SELECTED — 01 OF 10".
• Access state: protected.
• Failure/recovery: if the commitment fails to persist, an explicit message appears, prior state is preserved, and retry is available.
• Continuation: the founder proceeds to Workspace and Pricing.
• Acceptance: exactly one problem is committed and remains committed on revisit.

FR-4 — Build the SaaS product on the chosen problem (explicit) As a business owner / founder, I should have a SaaS product built to solve the problem I chose, so that the research converts into a working solution.

• Trigger/input: a committed problem selection.
• Observable result: the Workspace is bound to the committed problem and exposes the workflow that solves it.
• Access state: protected.
• Failure/recovery: if no problem is committed, the Workspace shows a prompt to complete Problem Selection.
• Continuation: the operator uses the Workspace; the founder reviews the committed choice.
• Acceptance: the Workspace reflects the committed problem and no other.

FR-5 — Full-stack SaaS delivery (explicit) As a SaaS end user (small business operator), I should use a SaaS product that includes frontend, backend, UI/UX, payment integration, and pricing, so that the solved workflow is usable end to end.

• Trigger/input: verified access to the Workspace and Pricing/Billing.
• Observable result: the frontend, backend persistence, designed UI, pricing presentation, and payment integration are all present and coherent.
• Access state: protected for Workspace and Billing; anonymous for Pricing.
• Failure/recovery: workflow action failures show inline ruled errors with retry; payment failures show explicit messages with retry.
• Continuation: the operator continues working in the Workspace under an active subscription.
• Acceptance: each of the five required components is present and reachable.

FR-6 — Self-service enrollment (required_inference) As a business owner / founder or SaaS end user, I should establish my own identity through Sign Up, so that I can reach the protected report, selection, workspace, and billing state.

• Trigger/input: submitting the enrollment form on Sign Up.
• Observable result: an application-owned identity is created and the user is taken to the Market Report.
• Access state: anonymous entry on Sign Up.
• Failure/recovery: duplicate identity or invalid field shows a field-level message and preserves entered values.
• Continuation: the user proceeds to the Market Report.
• Acceptance: a new identity can be created without invitation or provisioning.

FR-7 — Returning verification (required_inference) As a business owner / founder or SaaS end user, I should verify my identity through Login, so that I can resume my protected report, selection, workspace, and billing state.

• Trigger/input: submitting credentials on Login.
• Observable result: access is restored and the user reaches the last protected destination or the Market Report.
• Access state: anonymous entry on Login.
• Failure/recovery: invalid credentials show a generic message; retry or navigate to Sign Up.
• Continuation: the user resumes the protected journey.
• Acceptance: a returning user reaches protected state after verification.

FR-8 — Choose a pricing plan (required_inference) As a SaaS end user (small business operator), I should evaluate the pricing plans and choose one, so that I can subscribe to the SaaS.

• Trigger/input: reviewing the three ruled plan rows on Pricing and selecting one.
• Observable result: the chosen plan is carried into Billing.
• Access state: anonymous on Pricing.
• Failure/recovery: plan data load failure shows a retryable ruled error row.
• Continuation: the operator proceeds to Billing to pay.
• Acceptance: three plans are presented with rupee figures aligned right in tabular numerals and a recommended plan marked by a vermilion left rule and black "RECOMMENDED" tag.

FR-9 — Complete payment before paid workspace access (required_inference) As a SaaS end user (small business operator), I should complete payment for my chosen plan through the payment provider, so that I gain paid workspace access.

• Trigger/input: initiating payment on Billing for the chosen plan.
• Observable result: the payment provider processes the payment; on success the subscription becomes active and paid workspace access is granted.
• Access state: protected on Billing.
• Failure/recovery: a declined or unavailable payment shows an explicit message, the subscription remains inactive, and retry is available; the operator may return to Pricing to change plan.
• Continuation: the operator uses the Workspace under the active subscription.
• Acceptance: paid workspace access is granted only after payment completes.

FR-10 — Carry out the solved workflow (explicit) As a SaaS end user (small business operator), I should use the Workspace to carry out the workflow that solves the chosen problem, so that I complete the outcome the product promises.

• Trigger/input: opening the Workspace with a committed problem and active subscription.
• Observable result: workspace records produced by the solved workflow are visible and actionable.
• Access state: protected.
• Failure/recovery: a failed workflow action shows an inline ruled error with retry and preserves entered data; subscription-related failures link to Billing.
• Continuation: the operator continues working and can revisit the committed choice.
• Acceptance: the operator can complete the solved workflow and see its result.

4. User Personas

Business owner / founder

Product context. The founder is the requester who wants to understand the most painful, monetizable problems in the Indian business market. They arrive at the Landing page, establish identity through Sign Up, and reach the Market Report.

Primary goal. Evaluate candidate problems against willingness to pay and commit to a single problem that the SaaS will solve.

Distinct accepted responsibilities.

• Review the ranked research report of the ten most significant monetizable problems.
• Compare entries using rank, willingness-to-pay band, sector, and effort.
• Commit to exactly one problem on Problem Selection, producing durable selection state.
• Review the committed choice and the resulting Workspace.

Relevant inputs or decisions. The choice of one problem among ten; the willingness-to-pay band and effort trade-off; the commitment confirmation.

Interactions with other accepted participants. The founder's commitment determines the Workspace scope that the SaaS end user operates. The founder may also enter the Workspace to review the committed choice.

Observable success. Exactly one problem is committed, the black "SELECTED — 01 OF 10" bar confirms it, and the Workspace reflects that problem.

What makes this role different. The founder's work is evaluative and committing — reading a dossier and making a single binding decision — rather than recurring operational use of the solved workflow.

SaaS end user (small business operator)

Product context. The operator is the working user of the SaaS built on the chosen problem. They arrive at the Landing page or Pricing, establish identity through Sign Up or verify through Login, and use the Workspace.

Primary goal. Carry out the workflow that solves the chosen problem and complete the outcome the product promises, under an active subscription.

Distinct accepted responsibilities.

• Evaluate the three pricing plans and choose one.
• Complete payment through the payment provider on Billing.
• Use the Workspace to carry out the solved workflow and produce workspace records.
• Manage the subscription and review payment records.

Relevant inputs or decisions. Plan choice; payment confirmation; workflow inputs within the Workspace.

Interactions with other accepted participants. The operator's workspace is scoped by the founder's committed problem. The operator interacts with the external payment provider during payment.

Observable success. An active subscription is shown on Billing and the operator completes the solved workflow with visible results.

What makes this role different. The operator's work is recurring operational execution and subscription management, not the one-time research evaluation and commitment.

5. Core User Flows

Flow A — Founder reviews the report and commits to a problem

1. The founder arrives anonymously at Landing and reads the proposition and the schematic problem map.
2. The founder selects the hard black CTA and is taken to Sign Up.
3. On Sign Up, the founder enters the required identity fields and submits. The application creates the identity and redirects to Market Report.
4. On Market Report, the founder reads the ten ranked entries. The left rail shows the numbered transit line; selecting an entry slides its colour chip and rule 8px right in 140ms and marks it with a vermilion ring. Each entry presents rank, willingness-to-pay band, sector, and effort in the 3-column metadata block, and a prose body with a bold pull-quote in the 6-column body.
5. The founder compares candidates and proceeds to Problem Selection.
6. On Problem Selection, the founder selects one problem. The chosen line thickens to 6px, the other nine dim to 30% opacity, and a full-width black bar slides in reading "SELECTED — 01 OF 10".
7. The founder confirms the commitment. The application records the durable selection commitment.
8. Result: exactly one problem is committed. Continuation: the founder proceeds to Workspace to see the bound workflow, or to Pricing to review the subscription path.
9. Failure/recovery: if the commitment fails to persist, an explicit message appears, the previously selected problem remains visible, and the founder retries.

Flow B — Founder returns to review the committed choice

1. The founder arrives at Login and submits credentials.
2. The application verifies the identity and restores access.
3. The founder reaches Market Report or Problem Selection, where the committed problem remains marked.
4. Result: the durable selection is confirmed on revisit. Continuation: the founder returns to Workspace.

Flow C — Operator subscribes and gains paid workspace access

1. The operator arrives anonymously at Pricing (from Landing or directly) and reviews the three ruled plan rows: plan names in uppercase small caps, rupee figures right-aligned in tabular numerals, the recommended plan marked by a vermilion left rule and a black "RECOMMENDED" tag.
2. The operator chooses a plan and proceeds to Billing.
3. Because Billing is protected, the operator establishes identity through Sign Up (or verifies through Login if returning), then returns to Billing.
4. On Billing, the operator reviews the subscription summary and initiates payment. The application hands off to the external payment provider.
5. The payment provider processes the payment and returns the result.
6. Result: on success, the subscription becomes active and paid workspace access is granted; the confirmation is shown on Billing. Continuation: the operator proceeds to Workspace.
7. Failure/recovery: if the payment is declined or the provider is unavailable, an explicit message appears, the subscription remains inactive, and the operator retries or returns to Pricing to change plan.

Flow D — Operator carries out the solved workflow

1. The operator verifies through Login and reaches Workspace.
2. The Workspace header shows the committed problem with its category colour chip and station badge, and the subscription status indicator.
3. The operator carries out the workflow bound to the chosen problem, producing workspace records.
4. Result: the workflow records are visible and actionable. Continuation: the operator continues working, or opens Billing to manage the subscription.
5. Failure/recovery: a failed workflow action shows an inline ruled error with retry and preserves entered data; a subscription-related failure links to Billing.
6. Empty state: if no problem is committed, the Workspace prompts the operator to complete Problem Selection; if committed but no records exist, a ruled empty state presents the first action.

6. Visuals Colors and Theme

Muse and headline. Massimo Vignelli — Systematic clarity: a research dossier that reads like a subway map.

Mode. Light mode only.

Colour tokens (exact hex by role).

• Background (warm paper ground): #F7F4EE
• Surface (data panels): #FFFFFF
• Text (primary type and 1px rules): #111111
• Primary / signal (active problem line, ranking numeral, primary CTAs): #D7261E (vermilion)
• Accent (wayfinding code): #F2B300 (yellow)
• Wayfinding code: #1F7A5C (teal-green) and #111111 (black)
• Muted (metadata and secondary labels): #6B6B6B
• Blue and indigo are deliberately absent from the system.

Typography.

• Headings: Archivo, heavy 800/900 weights for display, flush-left ragged-right, tight tracking (-0.02em) at large sizes, sentence case for headlines, uppercase 11px letterspaced small caps for all labels, section numbers, and table headers.
• Body: Archivo.
• Scale: 1.333 modular on a 12/16/24/32/48/72/112 rhythm — display 40px mobile → 112px desktop via clamp(); section heads 28 → 48; body 16 → 18; labels 11px uppercase; tabular numerals for all ranks and figures.

Shape language. Hard edges only: zero border radius on panels, buttons, and inputs. Structure comes from 1px black rules, full-width horizontal dividers between problems, and square colour chips 10px wide standing in for line markers on a transit map. Numbered circular badges (28px, black stroke, white fill) mark each of the ten problems like station stops.

Layout. A strict 12-column grid with a persistent left rail on desktop: the rail holds the numbered 1–10 list of problems as a vertical transit line with colour-coded dots; the right 9 columns hold the full report entry. Report entries are asymmetric — a 3-column metadata block (rank, willingness-to-pay band, sector, effort) ruled off from a 6-column prose body with a bold pull-quote. On mobile the rail collapses into a sticky horizontal scrolling ticker of the ten numbers. Tables align label left, value right, tabular numerals, hairline rules between rows.

Imagery style. No photography. The image is the information: a full-bleed schematic "problem map" — ten horizontal lines in the four code colours converging into a single vermilion line that ends at a black square labelled "your choice". Small diagrammatic pictograms (a rupee glyph, a calendar grid, a filing drawer) drawn as 2px-stroke line art at 24px, used as section markers.

Readability constraint. Headlines, wordmarks, labels, numbers, card text, and controls stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling to fit; no other element covers any part of them. Body text never below 16px; labels never below 11px.

7. Signature Design Concept

The public entry is a full-viewport schematic map, not a headline-and-button stack. A black 1px grid is faintly ruled across the warm paper ground #F7F4EE. Ten labelled horizontal lines in red, yellow, teal, and black run edge-to-edge across the upper two-thirds, each tagged with an uppercase 11px problem label and a rank numeral at its left terminus. All ten converge diagonally into one thick vermilion line that drops to a black square in the lower-right third, labelled "your choice".

Overlapping the grid at the left, flush to the viewport edge, a 9-column stacked headline "TEN PROBLEMS. ONE CHOICE." is set in 40px mobile → 112px desktop Archivo Black, black, ragged right, sitting on the paper ground with no card or gradient behind it. The CTA is a hard black rectangle with a white uppercase 11px label pinned beneath the headline's last line, aligned to the grid, not centred.

On mobile the map reflows to a vertical stack of ten ruled rows with their colour chips, and the headline sits above it at 40px. The concept recomposes only accepted content — the ten-problem framing, the proposition, and the enrollment CTA — and introduces no new behaviour.

8. Interaction Model & Motion Direction

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

Landing Hero Motion Brief

• Focal subject: the schematic problem map — ten colour-coded horizontal lines converging into one vermilion line ending at a black square labelled "your choice".
• Input → transformation → outcome thesis: the visitor's attention moves along the ten lines; the convergence into a single vermilion line and the black square expresses the product's accepted arc — ten candidate problems, one committed choice, then the SaaS. No state changes on the hero itself; the CTA is the only interactive element.
• Motion vocabulary: still by default. Only two gestures exist in the system: the colour chip and rule for the active problem slide 8px to the right in 140ms on selection, and a section header rule that draws left-to-right in 200ms when a report entry enters the viewport. No parallax, no hover lift, no fades on text.
• Composed first frame: faint 1px black grid on #F7F4EE; ten labelled lines across the upper two-thirds with rank numerals at their left termini; convergence into a thick vermilion line dropping to the black square in the lower-right third; the stacked headline flush to the left edge; the hard black CTA beneath the headline's last line, grid-aligned.
• Reduced-motion state: both gestures are removed, leaving instant state — the active problem is marked by the vermilion ring and 8px offset applied immediately, and section header rules render fully drawn. The hero is unchanged because it is already still.

9. Non-Functional Requirements

• NFR-1 — Durable state (required_inference): the report, the selection commitment, subscription state, and workspace records persist across sessions and are bound to the correct identity. Rationale: the accepted journeys require revisiting and resuming protected state.
• NFR-2 — Protected access (required_inference): Market Report, Problem Selection, Workspace, and Billing are reachable only after verification; Landing, Sign Up, Login, and Pricing are anonymously reachable. Rationale: actor-specific durable state must be privately owned.
• NFR-3 — Payment integrity (explicit): payment is processed by the external payment provider; the application records the resulting subscription state and grants paid workspace access only after payment completes. Rationale: the accepted constraint requires payment integration.
• NFR-4 — Readability and accessibility (explicit, from design direction): body text at least 16px, labels at least 11px; all readable text and controls remain whole within the viewport and container at 375px, 768px, and 1280px; reduced-motion preference removes both motion gestures and leaves instant state.
• NFR-5 — Colour discipline (explicit, from design direction): no more than four accent colours in use at once; colour always encodes a problem category, never decoration; blue and indigo are absent.
• NFR-6 — Tabular alignment (explicit, from design direction): all ranks and rupee figures use tabular numerals, label left and value right, with hairline rules between rows.

10. Tech Stack

• Frontend: React web application with custom UI implementing the Vignelli-derived design system (Archivo typography, hard edges, 12-column grid, four-colour wayfinding code).
• Backend: Python / FastAPI service providing the report, selection commitment, identity, subscription, and workspace APIs, extending a single shared backend process.
• Storage: relational database for identities, report entries, selection commitments, subscriptions, payment records, and workspace records.
• Payments: external payment provider integration for subscription payment processing.
• Deployment: Docker / docker-compose for the frontend, backend, and database services.

11. Assumptions and Constraints

• Constraint (explicit): the SaaS product is built only after the requester chooses one problem from the report; the specific problem and its solution scope are not yet determined.
• Constraint (explicit): the SaaS must include frontend, backend, UI/UX, payment integration, and pricing.
• Assumption (required_inference): application-owned identity is established through self-service Sign Up with returning verification through Login; no invitation or provisioning boundary is established.
• Assumption (required_inference): exactly one problem may be committed at a time; the commitment is durable and revisitable.
• Assumption (required_inference): paid workspace access requires a completed payment for a chosen plan.
• Assumption: the report always contains exactly ten entries; there is no empty-report state.
• Assumption: both personas share the same application identity model; no differentiated permissions or role-based visibility are established.
• Out of scope: adjacent account-management capabilities (profile editing, team administration, role management); the concrete workflow inside the Workspace, which is bound only after the selection commitment.

12. Glossary

• Market Report: the durable, revisitable research dossier of the ten most significant monetizable problems in the Indian business market.
• Problem Selection: the commitment surface where the founder chooses exactly one problem from the report.
• Selection commitment: the durable record binding the SaaS scope to one chosen problem.
• Workspace: the protected recurring working surface where the operator carries out the workflow that solves the chosen problem.
• Wayfinding code: the four-colour system (vermilion #D7261E, yellow #F2B300, teal-green #1F7A5C, black #111111) that labels problem categories consistently across report, selection, and pricing.
• Transit line / rail: the persistent left-rail rendering of the ten problems as a numbered, colour-coded vertical line.
• Fare table: the pricing presentation of three ruled rows with label left and rupee figure right in tabular numerals.
• Willingness-to-pay band: the report metadata field expressing how much business owners are willing to pay to solve a problem.
• Station badge: the 28px numbered circular badge marking each of the ten problems.