System Requirements Document for quinsbuild-ai

1. Introduction

QuinsBuild AI is a platform that builds applications through text commands. A builder describes what they want in plain text, and the platform turns that description into a working SaaS application, website, dashboard, or AI tool. The product intent is a single continuous gesture: one command flows into a whole application, the way a line becomes a building.

The audience is technically fluent but visually under-served — people who live in dark IDEs and grey dashboards and who want a creation surface with a point of view. QuinsBuild AI serves two accepted human roles: the Builder / App Creator, who submits text commands and reviews the generated results, and the Platform Operator, who keeps the generation platform usable by overseeing submitted build requests, monitoring generated projects, and managing platform configuration.

2. System Overview

QuinsBuild AI is delivered as a first-party web application with application-owned identity and custom UI. Builders enroll themselves, verify on return, and work in a durable generation workspace where their commands and generated results persist and can be revisited. Platform Operators verify on return and work in an oversight workspace over the same generation activity, plus a configuration destination for the platform that supports generation.

Current delivery covers: anonymous public entry, self-service enrollment, returning verification, the builder command-and-generation workspace, a revisitable browse destination for generated applications, an operator oversight workspace, and an operator configuration destination. Generation runs as durable backend execution with persistence for text-command requests and generated application results.

Narrow exclusions: this document does not add adjacent account-management capabilities beyond first-use identity establishment and returning verification; it does not add billing, team management, marketplace, or third-party publishing surfaces; and it does not add differentiated permissions beyond the operator oversight and configuration responsibilities established by the accepted scope.

2a. Product Interpretation and Delivery Boundary

QuinsBuild AI is a first-party, application-owned product. Builders and Platform Operators reach it through the application itself; there is no provider-owned or external-only delivery boundary for the accepted work, and no headless-only delivery. Identity is application-owned because builders must privately own and resume durable, actor-specific state — their submitted commands and the applications generated from them — and because operator oversight and configuration must remain bound to the correct participant.

The anonymous entry boundary is the Landing page, which explains QuinsBuild AI, its builders, and the text-command generation workflow. Sign Up and Login are anonymously reachable identity-access surfaces: a protected destination cannot own the interaction that establishes access to itself. Build Studio, Generated Apps, Operations, and Settings are protected destinations; protected state remains unavailable until identity is established.

Current horizon: everything described in Sections 3 through 5. No future-horizon requirements are established by the authoritative source; nothing in this document is deferred.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

• Information and state: Anonymous public entry. Explains QuinsBuild AI, who it is for (builders), and the text-command application generation workflow. Presents the four generation targets — SaaS applications, websites, dashboards, and AI tools — as the outcomes a command can produce. No identity required; no protected state shown.
• Primary actions: Enter a text command in the oversized capsule command bar and submit it to begin; navigate to Sign Up to enroll; navigate to Login to verify on return.
• Supporting actions: Read the explanation of the generation workflow; move from the command bar into enrollment when not yet identified.
• Domain entities: Text command (draft), generation target type (SaaS application, website, dashboard, AI tool).
• Component responsibilities: Full-bleed dark stage; oversized three-line headline composition with the command capsule pinned directly beneath it as one composition; sweeping parametric ribbon form on the right, bleeding off the right and top edges; diagonal gold construction line linking the command bar to the form; curved section dividers overlapping the next section; procedural line diagrams as section openers.
• States: Loading — static composition renders immediately; no data fetch gates the entry. Empty — command capsule empty with a mint streaming cursor as the resting affordance. Success — a submitted command from an unidentified visitor routes into enrollment, carrying the command forward as the builder's first request. Error — a command submitted with no identity established is not silently discarded; the visitor is routed to Sign Up with the command preserved. Recovery — returning to Landing restores the command capsule; the visitor may re-enter or continue to Login.

Sign Up

• Information and state: Anonymous identity-access surface for self-service enrollment of builders. Collects the minimum identity information needed to establish an application-owned account that can privately own durable build requests and generated results.
• Primary actions: Submit enrollment details to establish a builder account; proceed into the protected generation workspace.
• Supporting actions: Move to Login if an account already exists; return to Landing.
• Domain entities: Builder account (identity), enrollment submission.
• Component responsibilities: Capsule inputs with a subtle inner glow on focus; full-pill submit control; inline validation messaging; curved surface treatment consistent with the product's shape language.
• States: Loading — submit control shows in-progress state while enrollment is processed. Empty — all fields empty with clear labels. Success — account established, builder is taken into the protected workspace with any carried-forward command preserved. Error — invalid or incomplete details are reported inline against the specific field; a duplicate-identity condition is reported without revealing unrelated account data. Recovery — the entered values remain in place so the builder can correct and resubmit, or switch to Login.

Login

• Information and state: Anonymous identity-access surface for returning verification. Serves both builders resuming durable build requests and generated results, and Platform Operators resuming oversight and configuration access.
• Primary actions: Submit credentials to verify identity and resume access.
• Supporting actions: Move to Sign Up if no account exists; return to Landing.
• Domain entities: Builder account, Platform Operator account, verification submission.
• Component responsibilities: Capsule credential inputs; full-pill verify control; inline error region; curved surface treatment.
• States: Loading — verify control shows in-progress state. Empty — credential fields empty with clear labels. Success — identity verified; the participant lands in the destination appropriate to their accepted responsibilities (builder workspace or operator workspace). Error — failed verification is reported without disclosing which element was wrong; repeated failure keeps the participant on the surface. Recovery — fields remain editable for retry; the participant may switch to Sign Up.

Build Studio

• Information and state: Protected builder workspace for entering and submitting text commands and initiating generation of SaaS applications, websites, dashboards, or AI tools. Two-pane split: left column holds the command capsule and the generation target selector; right pane holds the streaming generation preview. Shows the current command, the selected target type, and the live generation state of the submitted request.
• Primary actions: Type a text command; select the generation target type (SaaS / Website / Dashboard / AI Tool) via the horizontal segmented control; submit the command to initiate generation; observe the streaming generation preview.
• Supporting actions: Refine and resubmit a command to continue developing a generated result; move to Generated Apps to browse prior results.
• Domain entities: Text command, generation target type, build request, generation run, generated application result.
• Component responsibilities: Oversized capsule command bar (min-height 72px desktop, 56px mobile) with a mint streaming cursor and a gold Generate pill; horizontal segmented control for target type; dark rounded preview panel with a mint progress arc; monospace metadata strip on the preview panel; travelling gold stroke on the capsule edge at submit.
• States: Loading — on submit, the capsule's gold edge travels around the pill once before the preview panel opens with a curved wipe; the preview panel then shows a mint progress arc while generation runs. Empty — no command entered; preview pane shows an idle dark panel with no result. Success — generation completes; the preview panel presents the generated application result and the request is recorded as a durable build request. Error — a generation that fails reports the failure in the preview pane with the originating command preserved and a clear retry affordance. Recovery — the builder can edit the command and resubmit; the failed request remains visible so the builder can see what was attempted.

Generated Apps

• Information and state: Protected, revisitable browse and result destination for viewing applications generated from the builder's commands. Presents each generated application as a large curved card in a horizontal scroll-snap rail, each with a monospace metadata strip and a 1px champagne top edge. Restricted to the builder's own generated results.
• Primary actions: Browse the rail of generated applications; open a generated application to view its result.
• Supporting actions: Move to Build Studio to create a new application or continue refining an existing one.
• Domain entities: Generated application result, build request, generation target type, generation timestamp and metadata.
• Component responsibilities: Horizontal scroll-snap rail of large curved cards (28–40px radius); monospace metadata strip per card; 1px champagne top edge per card; dark framed preview treatment with a thin gold border and mint progress arc for in-progress items.
• States: Loading — rail shows placeholder card frames while results are fetched. Empty — no generated applications yet; the destination explains that results appear here after a command is submitted in Build Studio and offers a direct route there. Success — cards render with their metadata strips; selecting a card opens the generated result. Error — a failed fetch reports the failure and offers a retry without losing the builder's place. Recovery — retry reloads the rail; the builder can also return to Build Studio and resubmit.

Operations

• Information and state: Protected operator workspace for overseeing submitted build requests and monitoring generated projects. Persistent left rail of curved icon buttons with a wide content area using tabular gold-ruled rows. Restricted to Platform Operators.
• Primary actions: Review submitted build requests across the platform; monitor the state of generated projects.
• Supporting actions: Move to Settings to manage platform configuration; move between oversight views via the left rail.
• Domain entities: Build request (platform-wide), generation run, generated project, request state, operator account.
• Component responsibilities: Persistent curved-icon left rail; wide content area with tabular gold-ruled rows; status indicators for request and project state; monospace metadata where identifiers and timestamps are shown.
• States: Loading — table region shows an in-progress state while platform activity is fetched. Empty — no submitted build requests or generated projects yet; the destination states this plainly rather than showing an empty table. Success — requests and projects render with their states; the operator can read the current condition of platform generation activity. Error — a failed fetch reports the failure and offers retry. Recovery — retry reloads the oversight view; the operator can switch views via the left rail.

Settings

• Information and state: Protected operator destination for managing the platform configuration that supports application generation. Persistent left rail of curved icon buttons with a wide content area using tabular gold-ruled rows. Restricted to Platform Operators.
• Primary actions: Review and update the platform configuration that supports application generation; save configuration changes.
• Supporting actions: Move to Operations to return to oversight; move between configuration views via the left rail.
• Domain entities: Platform configuration, configuration change, operator account.
• Component responsibilities: Persistent curved-icon left rail; wide content area with tabular gold-ruled rows; capsule inputs and full-pill save control; inline validation and confirmation messaging.
• States: Loading — configuration region shows an in-progress state while current values are fetched. Empty — a configuration area with no values yet states this plainly and offers the fields to set them. Success — saved changes are confirmed and the updated values are shown. Error — invalid values are reported inline against the specific field; a failed save reports the failure without discarding the operator's edits. Recovery — edits remain in place for correction and resave; the operator can leave and return without losing unsaved work silently.

3. Functional Requirements

FR-1 — Generate a SaaS application from a text command (explicit) As a Builder / App Creator, I should describe a SaaS application in a text command and submit it, so that QuinsBuild AI produces a working SaaS application from my description.

• Trigger/input: A text command entered in the Build Studio command capsule with the generation target set to SaaS.
• Observable result: A build request is recorded durably and a generated SaaS application result becomes available in the preview pane and in Generated Apps.
• Access state: Requires an established builder identity; the protected workspace is unavailable until identity is verified.
• Failure/recovery: If generation fails, the failure is reported in the preview pane with the originating command preserved and a retry affordance.
• Continuation: The builder can refine the command and resubmit, or open the result in Generated Apps.

FR-2 — Generate a website from a text command (explicit) As a Builder / App Creator, I should describe a website in a text command and submit it, so that QuinsBuild AI produces a working website from my description.

• Trigger/input: A text command entered in the Build Studio command capsule with the generation target set to Website.
• Observable result: A build request is recorded durably and a generated website result becomes available in the preview pane and in Generated Apps.
• Access state: Requires an established builder identity.
• Failure/recovery: If generation fails, the failure is reported in the preview pane with the originating command preserved and a retry affordance.
• Continuation: The builder can refine the command and resubmit, or open the result in Generated Apps.

FR-3 — Generate a dashboard from a text command (explicit) As a Builder / App Creator, I should describe a dashboard in a text command and submit it, so that QuinsBuild AI produces a working dashboard from my description.

• Trigger/input: A text command entered in the Build Studio command capsule with the generation target set to Dashboard.
• Observable result: A build request is recorded durably and a generated dashboard result becomes available in the preview pane and in Generated Apps.
• Access state: Requires an established builder identity.
• Failure/recovery: If generation fails, the failure is reported in the preview pane with the originating command preserved and a retry affordance.
• Continuation: The builder can refine the command and resubmit, or open the result in Generated Apps.

FR-4 — Generate an AI tool from a text command (explicit) As a Builder / App Creator, I should describe an AI tool in a text command and submit it, so that QuinsBuild AI produces a working AI tool from my description.

• Trigger/input: A text command entered in the Build Studio command capsule with the generation target set to AI Tool.
• Observable result: A build request is recorded durably and a generated AI tool result becomes available in the preview pane and in Generated Apps.
• Access state: Requires an established builder identity.
• Failure/recovery: If generation fails, the failure is reported in the preview pane with the originating command preserved and a retry affordance.
• Continuation: The builder can refine the command and resubmit, or open the result in Generated Apps.

FR-5 — Select the generation target type (explicit) As a Builder / App Creator, I should choose among SaaS, Website, Dashboard, and AI Tool before submitting my command, so that the platform generates the kind of application I intend.

• Trigger/input: Selection on the horizontal segmented control in Build Studio.
• Observable result: The selected target type is visibly active and is bound to the submitted build request.
• Access state: Requires an established builder identity.
• Failure/recovery: If no target is selected, submission is blocked with a clear indication of what is missing.
• Continuation: The builder selects a target and submits.

FR-6 — Observe streaming generation progress (explicit) As a Builder / App Creator, I should see the generation of my application progress in the preview pane, so that I know the platform is working on my command.

• Trigger/input: Submission of a text command in Build Studio.
• Observable result: The preview panel opens with a curved wipe and shows a mint progress arc while generation runs, then presents the completed result.
• Access state: Requires an established builder identity.
• Failure/recovery: If the generation stream fails, the preview pane reports the failure and offers retry.
• Continuation: On completion the builder reviews the result and may refine and resubmit.

FR-7 — Browse generated applications (explicit) As a Builder / App Creator, I should browse the applications generated from my commands in a revisitable destination, so that I can return to and review what I have built.

• Trigger/input: Navigating to Generated Apps.
• Observable result: A horizontal scroll-snap rail of large curved cards renders, each with a monospace metadata strip and a 1px champagne top edge.
• Access state: Restricted to the builder's own generated results; requires an established builder identity.
• Failure/recovery: If the results cannot be loaded, the destination reports the failure and offers retry without losing the builder's place.
• Continuation: The builder opens a card to view the generated result, or moves to Build Studio to create another.

FR-8 — Open a generated application result (explicit) As a Builder / App Creator, I should open a generated application from the rail, so that I can inspect the result the platform produced from my command.

• Trigger/input: Selecting a card in the Generated Apps rail.
• Observable result: The generated application result is presented in a dark framed panel with a thin gold border.
• Access state: Restricted to the builder's own generated results.
• Failure/recovery: If the result cannot be opened, the destination reports the failure and returns the builder to the rail.
• Continuation: The builder returns to the rail or moves to Build Studio to refine the command.

FR-9 — Self-service enrollment for builders (required_inference) As a Builder / App Creator, I should establish my own account on first use, so that my build requests and generated applications are privately owned and can be resumed later.

• Trigger/input: Submitting enrollment details on Sign Up, or submitting a command from Landing without an established identity.
• Observable result: A builder account is established and the builder enters the protected workspace, with any carried-forward command preserved as the first request.
• Access state: Sign Up is anonymously reachable; protected state remains unavailable until enrollment completes.
• Failure/recovery: Invalid or incomplete details are reported inline against the specific field; a duplicate-identity condition is reported without revealing unrelated account data; entered values remain for correction.
• Continuation: The builder proceeds into Build Studio, or switches to Login.

FR-10 — Returning verification for builders and platform operators (required_inference) As a Builder / App Creator or Platform Operator, I should verify my identity on return, so that I can resume access to my durable build requests, generated results, or oversight and configuration work.

• Trigger/input: Submitting credentials on Login.
• Observable result: Identity is verified and the participant reaches the destination appropriate to their accepted responsibilities.
• Access state: Login is anonymously reachable; protected destinations remain unavailable until verification succeeds.
• Failure/recovery: Failed verification is reported without disclosing which element was wrong; fields remain editable for retry.
• Continuation: The participant proceeds into their workspace, or switches to Sign Up.

FR-11 — Durable execution and persistence of generation (required_inference) As a Builder / App Creator, I should have my submitted commands and their generated results persist, so that I can leave and return to them without losing work.

• Trigger/input: Submission of a text command in Build Studio.
• Observable result: The build request and its generated application result are recorded durably and remain available in Generated Apps across sessions.
• Access state: Bound to the submitting builder's identity.
• Failure/recovery: If persistence fails, the failure is surfaced to the builder rather than silently dropping the request.
• Continuation: The builder resumes the request or result on a later visit.

FR-12 — Operator oversight of submitted build requests and generated projects (required_inference) As a Platform Operator, I should review submitted build requests and monitor generated projects across the platform, so that I can keep the generation platform usable for builders.

• Trigger/input: Navigating to Operations.
• Observable result: Platform-wide build requests and generated projects render with their states in tabular gold-ruled rows.
• Access state: Restricted to Platform Operators; requires verified identity.
• Failure/recovery: If the oversight data cannot be loaded, the destination reports the failure and offers retry.
• Continuation: The operator switches oversight views via the left rail, or moves to Settings.

FR-13 — Operator management of platform configuration (required_inference) As a Platform Operator, I should review and update the platform configuration that supports application generation, so that builders can keep producing apps, sites, dashboards, and AI tools.

• Trigger/input: Navigating to Settings and editing configuration values.
• Observable result: Updated configuration values are saved and confirmed, and the changed values are shown.
• Access state: Restricted to Platform Operators; requires verified identity.
• Failure/recovery: Invalid values are reported inline against the specific field; a failed save reports the failure without discarding the operator's edits.
• Continuation: The operator corrects and resaves, or returns to Operations.

FR-14 — Role assignment and authorization for platform operators (required_inference) As a Platform Operator, I should hold the operator role that grants oversight and configuration access, so that platform-wide build activity and platform configuration are controlled by the correct participant.

• Trigger/input: Assignment of the operator role to an account.
• Observable result: The operator account can reach Operations and Settings; builder accounts cannot.
• Access state: Role-restricted destinations remain unavailable to accounts without the operator role.
• Failure/recovery: An account without the operator role attempting a restricted destination is denied access and returned to its own workspace.
• Continuation: The operator proceeds with oversight or configuration work.

4. User Personas

Builder / App Creator

Product context. The Builder is the person who wants to create SaaS applications, websites, dashboards, and AI tools. They are technically fluent and comfortable describing systems in prose, but they do not want to hand-assemble the scaffolding of each new application. They arrive at QuinsBuild AI with an idea already formed in words.

Primary goal. Turn a text description into a working application — a SaaS application, a website, a dashboard, or an AI tool — and then keep refining it.

Distinct accepted responsibilities. The Builder is the only role that authors text commands and initiates generation. They select the generation target type, submit the command, watch the generation stream, and review the result. They are also the only role that browses and opens their own generated applications. Their work is authoring and iterating; it is not oversight of other people's requests.

Relevant inputs and decisions. The text command itself; the choice among SaaS, Website, Dashboard, and AI Tool; the decision to accept a result or refine the command and resubmit; the decision to open a prior result from the rail.

Interactions with other accepted participants. The Builder does not interact directly with the Platform Operator, but their submitted build requests and generated projects are the material the Operator oversees. The Builder's ability to keep producing depends on the Operator keeping the generation platform usable and its configuration sound.

Observable success. A generated application result appears in the preview pane and persists in Generated Apps, where the Builder can return to it later and open it.

Platform Operator

Product context. The Platform Operator is the person responsible for keeping the QuinsBuild AI generation platform usable. They do not author the applications; they watch the platform that produces them. Their working context is platform-wide rather than personal — they see submitted build requests and generated projects across all builders.

Primary goal. Keep builders able to produce apps, sites, dashboards, and AI tools by overseeing generation activity and managing the platform configuration that supports it.

Distinct accepted responsibilities. The Operator reviews submitted build requests and monitors generated projects in Operations, and reviews and updates the platform configuration that supports application generation in Settings. They hold the operator role that grants this access. Their work is oversight and configuration; it is not authoring commands or owning generated results.

Relevant inputs and decisions. The state of platform-wide build requests and generated projects; the decision to adjust platform configuration; the decision to save or correct configuration values.

Interactions with other accepted participants. The Operator's oversight material is produced by Builders submitting commands. The Operator's configuration work is what keeps the Builder's generation path usable. The Operator does not author commands on the Builder's behalf.

Observable success. Platform-wide build requests and generated projects render with their states in Operations, and configuration changes are saved and confirmed in Settings.

5. Core User Flows

Flow 1 — A builder enrolls and generates their first application

1. The Builder arrives at Landing without an identity. The page explains QuinsBuild AI, who it is for, and the text-command generation workflow, and presents the four generation targets.
2. The Builder types a text command into the oversized capsule command bar and submits it. Because no identity is established, the command is not silently discarded — the Builder is routed to Sign Up with the command preserved.
3. On Sign Up, the Builder submits enrollment details. The submit control shows an in-progress state while enrollment is processed.
4. Enrollment succeeds. A builder account is established, and the Builder enters the protected workspace with the carried-forward command preserved as the first request.
5. In Build Studio, the Builder confirms the generation target on the horizontal segmented control — SaaS, Website, Dashboard, or AI Tool — and submits the command. The capsule's gold edge travels around the pill once, then the preview panel opens with a curved wipe.
6. The preview panel shows a mint progress arc while generation runs. The Builder observes the streaming generation progress.
7. Generation completes. The generated application result is presented in the dark framed preview panel, and the build request and its result are recorded durably.
8. Continuation: The Builder moves to Generated Apps to see the result in the rail, or refines the command in Build Studio and resubmits.
9. Failure/recovery: If generation fails, the preview pane reports the failure with the originating command preserved and a retry affordance. The Builder edits the command and resubmits; the failed request remains visible so they can see what was attempted.

Flow 2 — A returning builder resumes and refines a generated application

1. The Builder arrives at Login and submits credentials. Failed verification is reported without disclosing which element was wrong, and the fields remain editable for retry.
2. Verification succeeds and the Builder reaches their protected workspace.
3. The Builder navigates to Generated Apps. The rail of large curved cards renders, each with a monospace metadata strip and a 1px champagne top edge.
4. The Builder browses the rail and selects a card. The generated application result opens in a dark framed panel with a thin gold border.
5. The Builder returns to the rail, then moves to Build Studio to continue developing the application.
6. In Build Studio, the Builder edits the command and resubmits. The gold edge travels around the capsule once and the preview panel opens with a curved wipe.
7. Observable result: The refined result is presented in the preview pane and recorded durably alongside the earlier request.
8. Failure/recovery: If the results rail cannot be loaded, the destination reports the failure and offers retry without losing the Builder's place. If the result cannot be opened, the Builder is returned to the rail.
9. Continuation: The Builder keeps iterating, or leaves and returns later to the same durable results.

Flow 3 — A builder generates each of the four application kinds

1. The Builder is verified and working in Build Studio.
2. The Builder selects SaaS on the segmented control, enters a command describing a SaaS application, and submits. A generated SaaS application result appears in the preview pane and persists in Generated Apps.
3. The Builder selects Website, enters a command describing a website, and submits. A generated website result appears and persists.
4. The Builder selects Dashboard, enters a command describing a dashboard, and submits. A generated dashboard result appears and persists.
5. The Builder selects AI Tool, enters a command describing an AI tool, and submits. A generated AI tool result appears and persists.
6. Observable result: All four generated results are individually revisitable in Generated Apps, each with its own metadata strip.
7. Failure/recovery: If any single generation fails, only that request reports failure in the preview pane; the other results remain intact and available.
8. Continuation: The Builder opens any of the four results from the rail, or continues creating.

Flow 4 — A platform operator oversees generation activity

1. The Platform Operator arrives at Login and submits credentials. Verification succeeds and the Operator reaches their protected workspace.
2. The Operator navigates to Operations. The persistent left rail of curved icon buttons is present, and the wide content area shows tabular gold-ruled rows.
3. The Operator reviews the submitted build requests produced by Builders across the platform, reading each request's state.
4. The Operator monitors the generated projects, reading their current condition.
5. Observable result: The Operator can see the current state of platform generation activity and identify requests or projects that need attention.
6. Failure/recovery: If the oversight data cannot be loaded, the destination reports the failure and offers retry. If there are no submitted build requests or generated projects yet, the destination states this plainly rather than showing an empty table.
7. Continuation: The Operator switches oversight views via the left rail, or moves to Settings.

Flow 5 — A platform operator manages platform configuration

1. The verified Platform Operator navigates to Settings from the left rail.
2. The configuration region shows an in-progress state while current values are fetched, then presents the platform configuration that supports application generation.
3. The Operator reviews the current values and edits the configuration.
4. The Operator saves the changes using the full-pill save control.
5. Observable result: The saved changes are confirmed and the updated values are shown.
6. Failure/recovery: Invalid values are reported inline against the specific field. If the save fails, the failure is reported without discarding the Operator's edits, and the edits remain in place for correction and resave.
7. Continuation: The Operator returns to Operations to continue oversight, or remains in Settings for further configuration work.

Flow 6 — An account without the operator role attempts a restricted destination

1. A verified Builder attempts to reach Operations or Settings.
2. The role-restricted destination denies access because the account does not hold the operator role.
3. Observable result: The Builder is returned to their own workspace rather than shown platform-wide oversight data or platform configuration.
4. Continuation: The Builder continues their own authoring work in Build Studio or Generated Apps.

6. Visuals Colors and Theme

The creative direction is authoritative for this section. The muse is Zaha Hadid, and the headline idea is fluid parametric grandeur for a text-to-app engine: form emerging from a single continuous gesture, the way one text command flows into a whole application.

Mode. Dark-first. There is no light mode and no white-first hero.

Color tokens (dark mode).

Color proportion. 70% dark ground, 20% surface panels, 8% gold, 2% mint. Champagne gold is reserved for the wordmark underline, key CTAs, active nav, and the single luminous edge on curved surfaces. Mint-teal is reserved for live and generative states: the streaming command cursor, generating progress arcs, and success confirmations. No blue, no indigo, no violet.

Typography. Headings and body both use Jost. Headings are wide, light-to-regular weights, with generous tracking on display sizes, sentence case with occasional all-caps micro-labels. Headlines are set large and airy with tight leading on multi-line stacks so the curves of the layout can breathe around them.

Type scale (1.333 modular). Mobile: 40 / 30 / 22 / 16 / 14 px. Desktop: 72 / 54 / 36 / 18 / 15 px. Hero display: clamp(56px, 9vw, 128px) with line-height: 0.95 and letter-spacing: -0.02em.

Shape language. Continuous sweeping curves are the primary geometry. Section boundaries are large-radius arcs, not straight rules. Cards are soft capsules or rounded rectangles with 28–40px radii and a single 1px luminous top edge in champagne. Buttons are full pills. Inputs are capsules with a subtle inner glow on focus. Diagonal flow lines and thin gold hairlines run across the layout like architectural section cuts. No hard 90° corners on interactive surfaces; hard corners are reserved for the dark code and preview panels, which sit in deliberate contrast to the curves around them.

Spacing rhythm. An asymmetric editorial grid on a 12-column base. Section transitions use curved dividers that overlap the next section by 40–80px, so the page reads as one continuous surface rather than stacked rectangular bands.

Imagery style. No stock photography and no generic gradient blobs. Imagery is architectural: sweeping parametric line fields, topographic contours, and luminous curved surfaces rendered as SVG or CSS gradients on the dark ground. Generated-app previews are shown as dark framed panels with a thin gold border and a mint progress arc, never as flat screenshots. Small procedural line diagrams appear as section openers, like architectural section drawings.

Accessibility note. Readable text and controls stay whole at every viewport. 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. 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.

7. Signature Design Concept

The public entry — Landing — is a full-bleed deep-charcoal stage (#0B0D12) composed as one continuous swept surface.

Left five columns. An oversized Jost headline in pearl white (#F2F0EB), clamp(56px, 9vw, 128px), stacked in three lines with tight leading, reading "Type it. Build it." with a second line "QuinsBuild AI" in champagne gold (#C9A96A). The headline is not centred and carries no subtext-under-button stack.

Pinned directly beneath the headline. An oversized capsule command bar (min-height 72px desktop, 56px mobile) with a mint streaming cursor and a gold Generate pill on the right. The headline and the input are one composition, not a hero plus a separate form.

Right seven columns. A single sweeping parametric ribbon form, rendered as layered SVG curves with a champagne-to-mint lit edge, rotating slowly and bleeding off the right and top edges of the viewport.

The linking gesture. A thin gold hairline runs diagonally from the command bar up into the form, like a construction line — the visual statement that a command becomes a structure.

Below the fold. Curved section dividers overlap the next section by 40–80px, so the landing page reads as one continuous swept surface. Procedural line diagrams open each section like architectural section drawings.

What this concept does not do. It does not centre the headline, does not place a subtext block under a blue button, does not use a gradient blob, and does not use blue, indigo, or violet on a white ground. It recomposes only accepted content, states, and controls — the explanation of QuinsBuild AI, the four generation targets, the command input, and the routes into Sign Up and Login.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: cinematic Hero Dimensionality: dimensional_css

Landing Hero Motion Brief

Focal subject. The single continuous parametric ribbon form on the right of the Landing stage — layered SVG curves with a champagne-to-mint lit edge, bleeding off the right and top edges of the viewport.

Input → transformation → outcome thesis. The visitor types a text command into the capsule command bar; the gold hairline linking the command bar to the ribbon form carries that gesture into the form; the form's slow rotation and the travelling gold stroke on the capsule edge express the transformation of one command into a whole application. The outcome is the visitor's command carried forward into enrollment and generation — the same continuous gesture the product performs.

Motion vocabulary. A slow 20s continuous rotation of the parametric form (CSS 3D, not WebGL). A scroll-linked parallax where the form drifts 60px behind the headline. A light sweep that travels along the gold hairline on the active command capsule. On submit, the command capsule's gold edge travels around the pill once (a 900ms travelling stroke) before the generation preview opens with a curved wipe. Nothing bounces; everything eases with cubic-bezier(0.22, 1, 0.36, 1).

Composed first frame. Deep charcoal ground. Three-line Jost headline stacked left in pearl white and champagne gold. The oversized capsule command bar pinned directly beneath it with a mint streaming cursor at rest. The parametric ribbon form mid-rotation on the right, its lit edge catching champagne and mint, bleeding off the right and top edges. The diagonal gold construction line running from the command bar up into the form.

Reduced-motion state. The form freezes to a static composition and the curved wipe is replaced with a 200ms opacity fade. The headline, command capsule, and all controls remain whole and fully readable; the composition is usable without any motion.

9. Non-Functional Requirements

NFR-1 — Durable persistence of build requests and generated results (required_inference) Build requests and their generated application results must persist durably so that builders can leave and return to them across sessions. Rationale: the accepted builder journey includes revisiting generated applications in a dedicated browse destination, which is only meaningful if the results survive the session.

NFR-2 — Durable backend execution of generation (required_inference) Text-command generation must run as durable backend execution rather than as a transient client-side operation, so that a submitted command is not lost if the builder's session ends mid-generation. Rationale: the accepted journey requires the builder to observe streaming progress and then find the completed result recorded.

NFR-3 — Application-owned identity and session continuity (required_inference) Identity must be application-owned, with self-service enrollment for builders and returning verification for both builders and platform operators. Rationale: builders must privately own and resume durable, actor-specific state, and operator oversight and configuration must remain bound to the correct participant.

NFR-4 — Role-restricted access to operator destinations (required_inference) Operations and Settings must be restricted to accounts holding the operator role, and Generated Apps must be restricted to the builder's own generated results. Rationale: platform-wide oversight and platform configuration are differentiated control over shared product state, and generated results are actor-specific durable state.

NFR-5 — Readable text and controls at every viewport (explicit) Headlines, wordmarks, labels, numbers, and card text and controls must 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, decoration, and motion may be cropped, bled off an edge, rotated, overlapped, or cut as the creative direction asks, as long as they cover no readable text or control.

NFR-6 — Reduced-motion support (explicit) With prefers-reduced-motion, the product must provide a usable static arrangement: the hero form freezes to a static composition, the curved wipe is replaced with a 200ms opacity fade, and any horizontally scrollable content must allow each item to be brought fully into view.

NFR-7 — Horizontal scroll-snap rail behavior (explicit) The Generated Apps rail is a horizontally scrollable, scroll-snap row. It may cross the viewport or container edge by design; every item must become fully readable as it passes. In reduced-motion mode, items must still be bringable fully into view.

NFR-8 — No blue, indigo, or violet primaries on a light ground (explicit) The product is dark-first with champagne and mint. The generic indigo/blue-on-white SaaS template is forbidden for this project.

10. Tech Stack

Frontend. React, delivered as a first-party web application with custom UI. The Landing hero's parametric ribbon form is rendered with layered SVG and CSS 3D — not WebGL — per the creative direction's dimensional_css hero dimensionality.

Backend. Python with FastAPI, providing the generation API, durable build-request and generated-result persistence, identity and session handling, and the operator oversight and configuration endpoints. This is a single shared backend process serving all of the above; no separate service is required for the accepted scope.

Storage. A persistent datastore for builder accounts, operator accounts and roles, build requests, generation runs, generated application results, and platform configuration.

Packaging and deployment. Docker with docker-compose for local and single-host deployment. Kubernetes is not required by the accepted scope and is not included.

Typography. Jost for headings and body, loaded as a web font.

11. Assumptions and Constraints

Assumptions.

• A-1 (required_inference) — Builders enroll themselves; no invitation or provisioning path is established by the source, so self-service enrollment is the bootstrap.
• A-2 (required_inference) — The operator role is assigned to an account rather than self-selected during enrollment; the source establishes operator oversight and configuration responsibilities but no self-service path to them.
• A-3 (required_inference) — A command submitted from Landing by an unidentified visitor is carried forward into enrollment rather than discarded, because the accepted journey begins with a command and the product's promise is that a command becomes an application.
• A-4 (required_inference) — Generated results are owned by the builder who submitted the originating command, and are not visible to other builders.
• A-5 (required_inference) — Platform Operators see platform-wide build requests and generated projects in Operations, because their accepted responsibility is oversight of the generation platform rather than of their own authoring.

Constraints.

• C-1 (explicit) — The platform builds applications through text commands. SaaS applications, websites, dashboards, and AI tools are the four accepted generation targets.
• C-2 (explicit) — The product is dark-first. Blue, indigo, and violet primaries on a white or near-white ground are excluded, and the generic indigo/blue-on-white SaaS template is forbidden.
• C-3 (explicit) — Headings and body use Jost. Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are excluded for headings and body.
• C-4 (explicit) — No hard 90° corners on interactive surfaces, buttons, or inputs; curves only, except on code and preview panels.
• C-5 (explicit) — No photographic stock imagery and no flat clip-art illustration; imagery must be architectural and procedural.
• C-6 (explicit) — No bouncy or springy easing; motion is slow, continuous, and architectural.
• C-7 (explicit) — No glassmorphism panels with blur-heavy multicolour gradients; surfaces are opaque charcoal with a single luminous edge.
• C-8 (explicit) — Generated Apps is not a grid of identical hover-lift cards; it is a curved scroll-snap rail.
• C-9 (explicit) — Readable text and controls stay whole at every viewport; where the direction asks for a readable element to be cropped, clipped, covered, or run off an edge, the element is kept whole and the gesture is carried by imagery or decoration instead.
• C-10 (required_inference) — No adjacent account-management capabilities beyond first-use identity establishment and returning verification are included.
• C-11 (required_inference) — No billing, team management, marketplace, or third-party publishing surfaces are included.

12. Glossary

AI Tool — One of the four accepted generation targets: an AI-powered tool produced from a builder's text command.

Build request — A durable record of a submitted text command together with its selected generation target type, owned by the builder who submitted it.

Builder / App Creator — The accepted human role that authors text commands, selects generation targets, submits commands, and reviews and revisits generated applications.

Command capsule — The oversized capsule input in Build Studio (and on Landing) where a builder types a text command, with a mint streaming cursor and a gold Generate pill.

Dashboard — One of the four accepted generation targets: a dashboard produced from a builder's text command.

Generated application result — The application, website, dashboard, or AI tool produced by a generation run from a build request, persisted durably and revisitable in Generated Apps.

Generation run — The durable backend execution that transforms a build request into a generated application result.

Generation target type — The builder's selection among SaaS, Website, Dashboard, and AI Tool, made on the horizontal segmented control in Build Studio and bound to the submitted build request.

Operator role — The role that grants access to Operations and Settings; held by Platform Operators and not by builders.

Platform Operator — The accepted human role responsible for overseeing submitted build requests, monitoring generated projects, and managing the platform configuration that supports application generation.

SaaS application — One of the four accepted generation targets: a SaaS application produced from a builder's text command.

Text command — The plain-text description a builder writes to specify the application, website, dashboard, or AI tool they want QuinsBuild AI to build.

Website — One of the four accepted generation targets: a website produced from a builder's text command.