System Requirements Document for follower-smm

1. Introduction

follower-smm is a React frontend for a social-media follower storefront. Visitors browse follower services and packages, choose one, supply the target account or link and a quantity, and submit the order — which is fulfilled through the Indo SMM API, the site's external backend/order provider. The site owner operates the storefront on top of their Indo SMM API credentials.

The product intent is a single, focused storefront: present the follower services available through Indo SMM, let a customer place an order against a target account or link, and let that customer check the status of the order afterwards. The frontend is the deliverable; order execution, service inventory, and order state are owned by the Indo SMM provider.

Audience: young creators, small businesses, and resellers who want fast, visible follower growth, plus the site owner/operator who runs the storefront.

2. System Overview

follower-smm is a React single-page frontend with four destinations: Landing, Services, Order, and Order Status. All four are publicly reachable — no account, login, or signup exists in this product. The customer's order is identified by the order identifier returned by Indo SMM, which the customer carries forward to check status.

Actors:

• SMM Panel Customer — the visitor who browses follower services, places an order, and checks its status.
• Site Owner / Operator — the person who owns the Indo SMM API credentials and operates the storefront.
• Indo SMM API — external provider (non-persona actor) that supplies the service catalog, receives orders, and holds order state.

Accepted behavior: browse follower services and packages retrieved from Indo SMM; select a service; enter the target account or link and quantity; submit the order to Indo SMM; retain the returned order identifier; check order status.

Narrow exclusions: no user accounts, authentication, or login; no payment processing UI beyond what the accepted order flow requires; no admin/operator console; no analytics, messaging, or social features. Order execution and order state remain with Indo SMM.

2a. Product Interpretation and Delivery Boundary

The frontend is first-party and custom-built in React. Everything the customer touches — the landing presentation, the service catalog, the order workspace, and the status view — is owned by this application. Everything behind it — the list of available follower services, the acceptance of an order, and the order's progress — is owned by the Indo SMM API, an external provider. The frontend does not reimplement provider behavior; it retrieves services from Indo SMM, submits orders to Indo SMM, and displays the provider's responses.

Access is deliberately open. The accepted journeys are anonymous: a visitor can land, browse, order, and check status without creating an identity. No destination in this product is protected, and no account-management capability is in scope. The order identifier returned by Indo SMM is the continuity mechanism — it is what lets a customer return to Order Status and retrieve their order.

Current horizon: the four destinations above, the Indo SMM integration for service retrieval, order submission, and status retrieval, and the React frontend itself.

Future horizon: nothing beyond the current scope has been accepted. Any operator console, customer accounts, payment UI, or additional provider integrations would be new commitments, not part of this document.

2c. Page Content and Component Coverage

Landing

• Information/state: the storefront's proposition — buy social-media followers, delivered through Indo SMM; the platforms and follower services available; the two entry paths (browse services, start an order).
• Primary actions: "Start an order" (pink pill CTA) → Order; "See all services" (lime text link) → Services.
• Supporting actions: header navigation to Services, Order, and Order Status; footer.
• Domain entities: follower service (name, platform, price per 1000), platform (Instagram, TikTok, YouTube).
• Component responsibilities: full-bleed blush hero field with oversized three-line Comfortaa headline ("GROW YOUR FOLLOWERS", with "FOLLOWERS" in bubblegum pink) occupying 7 of 12 columns; floating glossy 3D follower-counter orb on the right, wrapped in a slowly morphing pink blob and bleeding slightly off the right edge; capsule platform chips; a short "how it works" strip (choose a service → enter your link and quantity → order runs through Indo SMM); shared footer.
• States:
  • Loading: hero renders immediately; the orb's counter shows a neutral placeholder until service data resolves.
  • Empty: if no services are retrievable from Indo SMM, the hero still renders and the services strip shows a plain "services are temporarily unavailable" note with a retry control.
  • Success: hero, orb, and platform chips render with live service data.
  • Error: provider unreachable — hero remains fully usable, a non-blocking notice appears, and the CTA still routes to Services.
  • Recovery: retry control re-requests the service list without leaving the page.

Services

• Information/state: the catalog of follower services and packages available through Indo SMM, each with platform, service name, and price per 1000.
• Primary actions: "Order" pill on each service card → Order with that service preselected.
• Supporting actions: platform filter chips; sort by price; header navigation; footer.
• Domain entities: follower service (id, name, platform, price per 1000, min/max quantity where the provider supplies them), platform.
• Component responsibilities: 2-up grid at mobile, 3-up at desktop, of capsule service cards with a glossy top highlight, a platform colour chip, a lime price-per-1000 chip that flips to pink on hover, and a pink "Order" pill; filter chip row; shared footer.
• States:
  • Loading: skeleton capsule cards in the grid shape.
  • Empty: no services returned, or no services match the active filter — a plain message plus a "clear filter" control when a filter caused it.
  • Success: populated card grid with prices in lime.
  • Error: provider request failed — an inline error panel with a retry control replaces the grid; navigation stays usable.
  • Recovery: retry re-requests the catalog; clearing the filter restores the full list.

Order

• Information/state: the selected service, the target account or link, the quantity, and the live computed price.
• Primary actions: "Place order" (pink pill pinned to the base of the price preview card) → submits to Indo SMM and returns an order identifier.
• Supporting actions: service picker (change service); quantity stepper; target link/account field; header navigation; footer.
• Domain entities: follower service, target account or link, quantity, computed price, order identifier, provider order response.
• Component responsibilities: two-column workspace — left, a white glossy panel holding the service picker and the link/quantity form; right, a live price preview card with a large lime quantity number that springs when the stepper changes and the "Place order" pill pinned to its base; quantity stepper with 120ms number pop; inline validation messaging.
• States:
  • Loading: service picker shows a loading state while the catalog resolves; the form is disabled until a service is available.
  • Empty: no service selected — the preview card shows a neutral prompt instead of a price.
  • Success: order accepted by Indo SMM — the returned order identifier is displayed prominently with a copy control and a link to Order Status.
  • Error: validation failure (missing or malformed target link, quantity outside the service's allowed range) shown inline against the offending field; provider rejection or network failure shown as an error panel above the "Place order" pill with the form values preserved.
  • Recovery: correcting the field or retrying submission re-sends the same order without re-entering data.

Order Status

• Information/state: the status of a previously submitted order, retrieved from Indo SMM by order identifier.
• Primary actions: "Check status" (capsule search) → retrieves the order from Indo SMM.
• Supporting actions: paste/copy of the order identifier; header navigation; footer.
• Domain entities: order identifier, order status, order progress timeline, service, quantity, target link.
• Component responsibilities: centred capsule search field for the order identifier; a status timeline built from capsule chips connected by a curved pink line whose progress animates as the order advances; order summary block (service, quantity, target, submitted time).
• States:
  • Loading: the timeline shows an indeterminate state while the provider responds.
  • Empty: no identifier entered — a plain prompt explaining that the order identifier comes from the order confirmation.
  • Success: order found — timeline chips and order summary render with the provider's current status.
  • Error: identifier not found, or provider unreachable — a distinct message for each, with the entered identifier preserved for correction or retry.
  • Recovery: editing the identifier and re-checking, or retrying after a provider failure, without losing the entered value.

3. Functional Requirements

FR-1 — Browse the follower service catalog (explicit) As an SMM Panel Customer, I should see the follower services and packages available through the Indo SMM API so that I can choose what to buy.

• Trigger: opening Services (or the services strip on Landing).
• Input: the service catalog retrieved from Indo SMM.
• Observable result: a grid of service cards, each showing platform, service name, and price per 1000.
• Access state: public, no identity required.
• Failure/recovery: if Indo SMM is unreachable, an inline error panel with a retry control replaces the grid; retry re-requests the catalog.
• Continuation: selecting a card's "Order" pill moves to Order with that service preselected.

FR-2 — Filter and sort the catalog (required_inference) As an SMM Panel Customer, I should be able to narrow the service list by platform and sort by price so that I can find a suitable service quickly.

• Trigger: selecting a platform filter chip or a sort control on Services.
• Observable result: the grid re-renders to the matching subset, or to the sorted order.
• Failure/recovery: if no service matches, an empty message appears with a "clear filter" control.
• Continuation: the customer selects a service and proceeds to order.

FR-3 — Select a service for ordering (required_inference) As an SMM Panel Customer, I should be able to choose a specific follower service so that my order is placed against the right package.

• Trigger: the "Order" pill on a service card, or the service picker on Order.
• Observable result: the chosen service is shown as the active selection on Order, and the price preview reflects its price per 1000.
• Failure/recovery: if the catalog cannot be loaded, the picker shows a loading or error state and the form stays disabled.
• Continuation: the customer enters the target link and quantity.

FR-4 — Enter the target account or link and quantity (required_inference) As an SMM Panel Customer, I should be able to supply the target account or link and the quantity of followers I want so that the order is placed against the correct destination.

• Trigger: typing or pasting into the target field and adjusting the quantity stepper on Order.
• Observable result: the live price preview card updates as the quantity changes, with the quantity number springing on each step.
• Failure/recovery: a missing or malformed target link, or a quantity outside the service's allowed range, is flagged inline against the offending field and submission is blocked until corrected.
• Continuation: the customer places the order.

FR-5 — Submit the order to Indo SMM (explicit) As an SMM Panel Customer, I should be able to place my order so that the follower delivery is started through the Indo SMM API.

• Trigger: the "Place order" pill on Order.
• Input: the selected service, the target account or link, and the quantity, passed to the Indo SMM API.
• Observable result: Indo SMM accepts the order and returns an order identifier.
• Access state: public, no identity required.
• Failure/recovery: a provider rejection or network failure shows an error panel above the "Place order" pill with all form values preserved; retrying re-sends the same order without re-entering data.
• Continuation: the returned order identifier is displayed with a copy control and a link to Order Status.

FR-6 — Retain the order identifier (required_inference) As an SMM Panel Customer, I should receive and be able to copy the order identifier returned by Indo SMM so that I can look the order up later.

• Trigger: a successful order submission.
• Observable result: the order identifier is shown prominently on Order with a copy control.
• Failure/recovery: if the provider response omits an identifier, the customer is told the order could not be confirmed and is given the option to retry.
• Continuation: the customer follows the link to Order Status, or returns later with the copied identifier.

FR-7 — Check order status (required_inference) As an SMM Panel Customer, I should be able to check the status of a submitted order so that I know whether my followers are being delivered.

• Trigger: entering an order identifier into the capsule search on Order Status and submitting.
• Input: the order identifier, sent to the Indo SMM API.
• Observable result: the order's current status renders as a timeline of capsule chips connected by a curved pink line, alongside an order summary (service, quantity, target, submitted time).
• Access state: public, no identity required.
• Failure/recovery: an unknown identifier and an unreachable provider produce distinct messages, and the entered identifier is preserved so the customer can correct it or retry.
• Continuation: the customer re-checks later as the order advances.

FR-8 — Present the storefront proposition (required_inference) As an SMM Panel Customer, I should understand on arrival what this site sells and how ordering works so that I can decide to browse or order.

• Trigger: opening Landing.
• Observable result: the hero headline, the follower-counter orb, the platform chips, and the two entry paths (Start an order, See all services) are visible.
• Failure/recovery: if service data cannot be loaded, the hero remains fully usable and a non-blocking notice appears; the CTAs still route correctly.
• Continuation: the customer follows either entry path.

FR-9 — Operate the storefront on Indo SMM credentials (explicit) As a Site Owner / Operator, I should have the frontend present the follower services and route orders to the Indo SMM API so that the business can take orders.

• Trigger: the site being deployed and reachable.
• Observable result: the storefront serves the catalog from Indo SMM, submits orders to Indo SMM, and displays provider order status.
• Failure/recovery: provider outages surface as recoverable error states on the affected page rather than breaking the whole site.
• Continuation: the operator's business takes and fulfills follower orders through the provider.

4. User Personas

SMM Panel Customer

Product context: a visitor who wants to buy social-media followers. They arrive from a link or a search, usually on a phone, and they want to see what is on offer and get an order placed quickly. They may be a young creator, a small business, or a reseller buying on someone else's behalf.

Primary goal: complete an order for followers against a specific account or link, and be able to confirm afterwards that it is running.

Distinct accepted responsibilities: browsing the follower services and packages retrieved from Indo SMM; narrowing the list to a platform and a price; selecting one service; supplying the target account or link and the quantity; placing the order; keeping the order identifier; returning to check the order's status.

Relevant inputs and decisions: which platform and which service to buy; how many followers; which account or link the followers should go to; whether the computed price is acceptable before committing.

Interactions with other accepted participants: the customer's order is executed by the Indo SMM API, which supplies the catalog, accepts the order, returns the identifier, and holds the status the customer later reads. The customer never interacts with the operator directly; the operator's role is to keep the storefront and its provider credentials working.

Observable success: the order is accepted by Indo SMM, an order identifier is shown and copyable, and the status view later shows the order's progress.

What makes this role distinct: the customer is the only actor who initiates and completes a purchase, and the only one who reads order state. Their work is a short, transactional loop — browse, choose, enter a link and quantity, commit, then check back — and every screen exists to shorten that loop.

Site Owner / Operator

Product context: the person who requested the site and owns the Indo SMM API credentials. They are not a daily user of the storefront UI; they are the party responsible for the storefront existing and for the provider connection behind it.

Primary goal: run a working follower storefront that takes orders and has them fulfilled through Indo SMM.

Distinct accepted responsibilities: owning the Indo SMM API credentials the frontend uses; ensuring the storefront presents the follower services the provider offers; ensuring orders placed on the site reach Indo SMM and that their status is visible to the customer.

Relevant inputs and decisions: the provider account and credentials; which services the provider exposes; whether the storefront is live and reachable.

Interactions with other accepted participants: the operator's provider account is what the SMM Panel Customer's orders are executed against. The operator does not act inside the customer's order flow.

Observable success: the storefront serves the catalog from Indo SMM, orders submitted on the site are accepted by Indo SMM, and customers can retrieve their order status.

What makes this role distinct: the operator's responsibility is operational and external to the customer journey — credentials, provider connection, and availability — rather than any in-product task. No operator-facing console, dashboard, or admin surface is part of this product.

5. Core User Flows

Flow A — SMM Panel Customer: browse the follower services

1. The customer opens Landing and reads the hero: "GROW YOUR FOLLOWERS", the follower-counter orb, and the platform chips.
2. They choose "See all services" (lime text link) and arrive at Services.
3. Services requests the follower catalog from the Indo SMM API. While it resolves, skeleton capsule cards hold the grid shape.
4. The catalog renders as a 2-up (mobile) / 3-up (desktop) grid of capsule service cards, each with a platform colour chip, the service name, and a lime price-per-1000 chip.
5. The customer optionally selects a platform filter chip or sorts by price; the grid re-renders to the matching subset.
6. If no service matches the filter, an empty message appears with a "clear filter" control; clearing restores the full list.
7. If Indo SMM is unreachable, an inline error panel with a retry control replaces the grid; the customer retries and the catalog loads.
8. Next step: the customer picks a service.

Flow B — SMM Panel Customer: place a follower order

1. From Services, the customer selects the "Order" pill on a service card. They arrive at Order with that service already active in the picker.
2. The left panel shows the service picker and the link/quantity form; the right panel shows the live price preview card with the service's price per 1000.
3. The customer enters the target account or link for the followers.
4. The customer adjusts the quantity stepper. The large lime quantity number springs on each step, and the price preview recomputes live.
5. If the target link is missing or malformed, or the quantity falls outside the service's allowed range, the field is flagged inline and submission is blocked until corrected.
6. The customer reviews the computed price on the preview card and presses the pink "Place order" pill pinned to its base.
7. The frontend submits the selected service, the target account or link, and the quantity to the Indo SMM API.
8. Indo SMM accepts the order and returns an order identifier. The identifier is displayed prominently on Order with a copy control and a link to Order Status.
9. If Indo SMM rejects the order or the request fails, an error panel appears above the "Place order" pill with every form value preserved; the customer retries and the same order is re-sent without re-entering data.
10. If the provider response carries no identifier, the customer is told the order could not be confirmed and is offered a retry.
11. Next step: the customer copies the identifier and continues to Order Status, or returns later with it.

Flow C — SMM Panel Customer: check an order's status

1. The customer opens Order Status, either from the link on the order confirmation or by navigating there later with the identifier they copied.
2. They paste the order identifier into the centred capsule search and submit "Check status".
3. The frontend queries the Indo SMM API for that order. The timeline shows an indeterminate state while the provider responds.
4. Indo SMM returns the order's current status. The status renders as a timeline of capsule chips connected by a curved pink line whose progress animates to the current stage, alongside an order summary showing the service, quantity, target, and submitted time.
5. If the identifier is not recognised, a distinct "order not found" message appears with the entered value preserved so the customer can correct it.
6. If the provider is unreachable, a separate error message appears and the customer can retry without re-entering the identifier.
7. Next step: the customer re-checks later as the order advances, or places another order.

Flow D — Site Owner / Operator: operate the storefront

1. The operator holds the Indo SMM API credentials the frontend uses and confirms the provider account exposes the follower services to be sold.
2. The operator makes the React storefront reachable.
3. A customer's order placed on Order is routed to the Indo SMM API under the operator's credentials and accepted by the provider.
4. The operator's observable result: the storefront serves the catalog from Indo SMM, orders submitted on the site are accepted by Indo SMM, and customers can retrieve their order status on Order Status.
5. If the provider is unavailable, the affected page shows a recoverable error state with a retry control rather than breaking the rest of the site; the operator restores the provider connection and customers retry.

6. Visuals Colors and Theme

Muse and headline: Karim Rashid — sensual pop minimalism for a follower storefront. Organic curves, candy colour, and glossy surfaces treated as material. The product is social, visual, and aspirational, so buying followers should feel like picking a flavour, not filing a ticket. No blue anywhere; the generic indigo/blue-on-white SaaS template is forbidden for this project.

Colour tokens (light mode):

Pink and lime are used in large flat fields, never as gradients. Primary carries CTAs, active tabs, and the hero blob; accent is the single hot colour for prices, quantity steppers, and success states; muted plum carries secondary labels.

Typography:

• Headings: Comfortaa 700/600, rounded geometric, tracking -0.02em, sentence case for headlines, ALL-CAPS only for micro-labels.
• Body: Quicksand.
• Scale: 1.333 modular — 96 / 72 / 48 / 32 / 24 / 18 / 16 / 14.
• Hero headline: clamp(40px, 8vw, 96px). Section titles: clamp(28px, 5vw, 48px).
• Body 16–18px at 1.6 line-height; labels 14px uppercase with 0.08em tracking.
• Inter, Roboto, Arial, Helvetica, Open Sans, Lato, Poppins, and system-ui are excluded for headings and body.

Shape language: blobs and capsules everywhere — pill buttons (border-radius: 999px), cards at 28–40px radii, curved section dividers built from SVG blobs, glossy highlights as thin white inner strokes. Buttons carry a soft 2px top highlight so they read as glossy plastic. No sharp 90° corners on buttons or cards; the only exception is data table cells, which use a 12px radius to keep rows readable.

Spacing rhythm: a 4px base unit with generous section padding; mobile-first single column that opens into an asymmetric two-column editorial grid at 768px and a 12-column grid at 1280px.

Imagery style: glossy 3D props rendered in CSS/WebGL — a floating follower-count orb, candy-coloured platform chips (Instagram, TikTok, YouTube) as rounded 3D tokens, and a soft pink-to-lime gradient blob behind the hero. No stock photography, no human faces. Icons are thick-line rounded pictograms in pink, lime, and plum.

7. Signature Design Concept

The glossy follower orb on a blush field.

The first screen is a full-bleed #FFF3F6 field. On the left, an oversized Comfortaa headline — GROW YOUR FOLLOWERS — set at clamp(40px, 8vw, 96px) in #1A0A14, stacked in three lines, with the word FOLLOWERS in #FF2D7A. Beneath it, a single pink pill CTA, "Start an order", and a lime text link, "See all services".

On the right, a floating glossy 3D orb shows a live-looking follower counter in #1A0A14 on white, wrapped in a soft pink blob that slowly morphs. The composition is asymmetric: the type block occupies 7 of 12 columns and the orb bleeds slightly off the right edge. There is no centred headline, no gradient blob behind the text, and no blue button.

The orb is the product's defining state made visible — a follower count going up — and it is the one crafted real-time object the whole page is built around. Everything else on the page is flat, glossy, and quiet around it.

8. Interaction Model & Motion Direction

Interaction Model: Animated Motion Tempo: expressive Hero Dimensionality: webgl

Landing Hero Motion Brief

• Focal subject: the floating glossy 3D follower-counter orb, wrapped in a slowly morphing pink blob, positioned right of the headline and bleeding slightly off the right edge.
• Input → transformation → outcome thesis: as the page settles, the orb's counter ticks upward toward the live follower figure retrieved from the Indo SMM service data, while the pink blob behind it morphs on an 8s ease-in-out loop. The transformation is the product's promise made literal — a number that climbs — and the outcome is a first frame the visitor reads as "followers go up here".
• Motion vocabulary: slow blob morph (8s ease-in-out loop); a 45° white glossy highlight sweeping across the primary CTA on hover over 400ms; service cards scaling to 1.02 with a soft spring on hover; quantity stepper numbers popping with a 120ms scale; page transitions using a pink wipe from the left.
• Composed first frame: blush #FFF3F6 field; three-line Comfortaa headline left, "FOLLOWERS" in #FF2D7A; pink pill CTA and lime text link beneath; glossy orb right with the counter mid-tick and the blob at a soft, rounded rest shape.
• Reduced-motion state: all motion is disabled or reduced to opacity fades under prefers-reduced-motion. The orb renders as a static glossy sphere with the follower counter at its final value, the blob holds a fixed rounded shape, the CTA highlight does not sweep, and page transitions become instant.

Landing Hero 3D Scene Brief — DIRECTION-DERIVED

One crafted real-time object: a glossy, slightly translucent sphere — the follower-counter orb — rendered in WebGL/R3F, sitting inside a soft pink blob that morphs on a slow loop. The orb's surface carries a white glossy highlight and a thin inner stroke; the follower counter is set in #1A0A14 on a white face and ticks upward to the live figure. The scene is lit softly from the upper left so the highlight reads as candy sheen, and the orb bleeds slightly past the right viewport edge. Under prefers-reduced-motion, the scene renders a single static frame with the counter at its final value.

9. Non-Functional Requirements

• NFR-1 — React frontend (explicit): the frontend must be built with React. Rationale: explicit hard constraint in the authoritative user evidence.
• NFR-2 — Indo SMM as the API/backend (explicit): the site's API/backend is Indo SMM, an external provider. Service inventory, order acceptance, and order state are owned by Indo SMM and are not reimplemented in the frontend. Rationale: explicit hard constraint in the authoritative user evidence.
• NFR-3 — Provider failure is recoverable (required_inference): every page that depends on Indo SMM must degrade to a recoverable error state with a retry control rather than an unusable page, because the provider is external and outside the frontend's control.
• NFR-4 — Readable text and controls stay whole (explicit, from the creative direction): headlines, wordmarks, labels, numbers, card text, and controls must stay entirely inside the viewport and their container at 375px, 768px, and 1280px, wrapping or scaling (for example font-size: clamp(...) with its mobile size) to fit, 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 direction asks, provided they cover no readable text or control.
• NFR-5 — Reduced motion (explicit, from the creative direction): all motion must be disabled or reduced to opacity fades under prefers-reduced-motion, including the hero blob morph, the CTA highlight sweep, card hover springs, stepper pops, and page transitions.
• NFR-6 — No blue (explicit, from the creative direction): no blue or indigo accent (#0057FF, #2563EB, #4F46E5, #6366F1) may appear; the palette is pink, lime, and plum only.

10. Tech Stack

• Frontend: React (explicit user choice).
• Styling: CSS with the token set in Section 6 — Comfortaa and Quicksand, pill and blob radii, the pink/lime/plum palette.
• Hero rendering: WebGL/R3F for the follower-counter orb, per the creative direction's webgl hero dimensionality.
• Backend / API: Indo SMM API, external provider (explicit user choice) — supplies the follower service catalog, accepts orders, and holds order state.
• Storage: none in the frontend beyond the in-memory order identifier carried from Order to Order Status; order state lives with Indo SMM.

11. Assumptions and Constraints

• Assumption: the Indo SMM API exposes the follower service catalog, order submission, and order status retrieval that the accepted journeys depend on. (required_inference — the provider is named explicitly but its endpoint surface is not specified.)
• Assumption: the operator supplies and configures the Indo SMM API credentials; the frontend consumes them and does not manage them. (required_inference.)
• Assumption: the order identifier returned by Indo SMM is the sole continuity mechanism for Order Status; no customer account exists. (required_inference.)
• Constraint: the frontend is built with React. (explicit.)
• Constraint: the API/backend is Indo SMM, an external provider. (explicit.)
• Constraint: no user accounts, authentication, login, or signup are in scope; all four destinations are publicly reachable. (explicit via the page contract's access_requirement: none.)
• Constraint: no operator/admin console, payment UI, analytics, or messaging capability is in scope. (explicit exclusion — none was accepted.)
• Constraint: the palette, typography, shape language, and motion rules in Sections 6–8 are binding, including the prohibition on blue and on the generic indigo/blue-on-white SaaS template. (explicit, from the creative direction.)

12. Glossary

• Indo SMM API — the external provider that supplies the follower service catalog, accepts orders, and holds order state. The site's backend.
• Follower service — a purchasable package of social-media followers offered through Indo SMM, identified by platform, name, and price per 1000.
• Price per 1000 — the provider's unit price for a follower service, shown in lime on service cards and used to compute the live order price.
• Target account or link — the social-media account or URL the ordered followers are delivered to.
• Order identifier — the reference returned by Indo SMM when an order is accepted; the customer's key for checking status.
• Order status — the provider-held progress of a submitted order, rendered as a capsule-chip timeline on Order Status.
• SMM Panel Customer — the visitor who browses follower services, places an order, and checks its status.
• Site Owner / Operator — the person who owns the Indo SMM API credentials and operates the storefront.