System Requirements Document for shoe-nigeria

1. Introduction

Product intent. Shoe Nigeria is a Nigerian custom made shoe app. It is not only about finding customers for shoe makers in Nigeria: it also makes payment easy, makes delivery easy, and makes the delivery fee less expensive than the alternative a buyer would otherwise pay. Every current capability serves one of those four commitments — connecting Nigerian shoe makers with customers, easy in-app payment, easy delivery, and a lower delivery fee.

Audience. The product serves two accepted human roles in Nigeria: Shoe Maker (Artisan), who needs a steady stream of customers for made-to-order work without having to source buyers or arrange logistics, and Customer (Shoe Buyer), who wants to find a Nigerian shoe maker, place a custom order, pay easily, and receive delivery affordably.

Scope of the current release. Shoes on Shoe Nigeria are custom made (made-to-order), not off-the-shelf. The app is focused on the Nigerian market. Ordering, payment, maker fulfillment, delivery arrangement and a reduced delivery fee are all current commitments.

2. System Overview

Current delivery. A first-party custom web application with application-owned identity. Both accepted human roles enroll themselves and choose their role before any protected work. Anonymous visitors can read the public entry surface and can begin enrollment or returning verification. After identity is established, each role reaches only its own working destinations: the customer's discovery, ordering, checkout and order-tracking surfaces, and the maker's listing, order, payout and delivery surfaces. Delivery status is shared between the customer and the maker.

Accepted actors.

• Customer (Shoe Buyer) — accepted, closed persona catalog.
• Shoe Maker (Artisan) — accepted, closed persona catalog.
• Non-persona actors — the payment provider that executes in-app payment, the delivery/logistics provider that carries the parcel, and the platform system process that computes grouped-delivery savings, applies the reduced delivery fee, and releases maker payout after delivery.

Accepted behavior. Enroll with a role, verify returning identity, discover Nigerian shoe makers and their made-to-order offerings, place a custom order specifying made-to-order requirements, pay in the app including the reduced delivery fee, see fulfillment advance through PAID → MAKING → READY → ON THE WAY → DELIVERED, arrange and view delivery at the reduced fee for both the customer and the maker, and release the maker's payout for completed orders.

Ownership. The customer and maker working surfaces are application-owned custom pages. Payment execution is provider-owned; parcel movement is delivery-provider-owned; the reduced-fee computation, order state, and payout sequencing are platform system processes exposed through the app's own pages.

Narrow exclusions. No off-the-shelf or ready-made shoe catalog, no non-Nigerian market, no social feed or messaging product, no account-management surface beyond first-use identity establishment and returning verification, no shopping cart spanning multiple makers, no returns/refund workflow, no subscription or loyalty program, and no delivery-route administration by either persona. These are not implied anywhere by the accepted thread.

2a. Product Interpretation and Delivery Boundary

Shoe Nigeria is delivered as a first-party web application that both roles log into, alongside two external ownership boundaries the app depends on: the payment provider that actually moves the buyer's money, and the delivery provider that actually moves the parcel. The app owns the relationship — enrollment with a role, maker listings, the custom order and its made-to-order requirements, the checkout ticket and fee breakdown, order status, delivery visibility for both sides, and the payout rail for the maker.

Identity is application-owned and role-selected at first use. Anonymous entry is limited to the public entry surface and to the two identity-access surfaces (enrollment and returning verification); everything else is reached only after identity is established, and customer-only and maker-only surfaces remain restricted to the correct role. Signing up or logging in never itself publishes a listing, places an order, or moves money — it only opens the working destination for the chosen role.

Delivery fee is a first-class, visible outcome rather than a hidden backend detail: wherever a delivery fee appears, the lower fee and its grouped-delivery saving are shown to the buyer on the checkout ticket and to both parties on the delivery surface. Nothing in the current release is deferred: all accepted capabilities — connecting makers to customers, easy payment, easy delivery, and the reduced delivery fee — are in the current delivery horizon. Future additions live only in Section 11 and carry no acceptance weight here.

2b. Source Content Inventory

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

2c. Page Content and Component Coverage

Landing

Information and State

• Anonymous public entry surface; no session required; no protected data rendered.
• States the marketplace proposition: custom made shoes, made in Nigeria, made for your feet.
• Full-width stamped route ribbon showing active city pairings (Lagos → Abuja → Port Harcourt), grouped delivery savings, and moving dotted parcel paths.
• Mustard "LOWER DELIVERY FEE" seal attached to the route strip.

Primary Actions

• Find a shoemaker — cream CTA ticket. Anonymous visitors are routed to Sign Up (role choice) or Login; once identity is established as a customer, the visitor continues to Discover.
• Sell your shoes — routes an anonymous visitor to Sign Up with the maker role selected; once established, continues to My Listings.

Supporting Actions

• Log in link to Login.
• Route ribbon and delivery-saving figures are illustrative public information, not an order.

Domain Entities

• City route pairing, grouped-delivery saving sample, MADE BY maker seal, platform proposition copy.

Component Responsibilities

• Kraft-tan workbench field divided by a heavy black horizontal rule; stacked Alfa Slab One statement with MADE IN set as a huge orange-red stamped block; right third as a vertical field-notes label containing one tightly cropped documentary photograph of a maker's hands finishing a leather shoe; bottom ink delivery strip with dotted route, mustard seal and cream CTA ticket.

States

• Loading: no blocking load; the hero is static first paint, and the route ribbon may populate after paint.
• Empty: not applicable — public proposition copy is always present.
• Success: CTA ticket navigates to Sign Up or Login without losing the chosen role intent.
• Error: if route-ribbon data is unavailable, the strip falls back to the static Lagos → Abuja → Port Harcourt pairing and the CTA remains fully usable.
• Recovery: retry affordance on the ribbon restores live city pairings and grouped-savings figures.

Sign Up

Information and State

• Anonymous identity-access surface; no session required; the entry point for both accepted roles.
• Role selection is the first decision: Customer (Shoe Buyer) or Shoe Maker (Artisan).
• States plainly that customer accounts open discovery and ordering, and maker accounts open listings, orders and payouts.

Primary Actions

• Choose role, supply credentials, submit to establish identity.
• On success: a customer continues to Discover; a shoe maker continues to My Listings.

Supporting Actions

• Switch the selected role before submitting without losing entered credential values.
• Link to Login for a returning user who arrived here by