MindPalaceX · The Workshop
The Idea Wall →

On the Idea Wall · ▲ 0 votes

SportShelf — the spec

SportShelf is a single-operator marketplace for selling branded sports footwear and apparel. Built for solo business owners who want to publish, price, and ship their own curated product catalog without stitching together separate tools, it gives Ulysse's team one place to list products, accept orders, and track every fulfillment step from sale to delivery.

---

Decisions locked

QuestionAnswer
ShapeMarketplace (single-operator, self-published)
AudienceSolo business owner and their internal team
Core loopUpload product → set price → receive order → fulfill and track
v1 success metricThe full order-to-fulfillment process runs entirely inside SportShelf within 30 days of launch

---

The core loop

  1. Operator logs in and uploads a shoe or apparel product with photos, brand, size options, and price.
  2. A customer browses the storefront, selects size and quantity, and completes checkout.
  3. Payment is captured and the order lands in the Order Management dashboard.
  4. A team member picks the order, marks it as packed, and enters a tracking number or courier reference.
  5. Fulfillment status updates automatically — the customer sees the current state; the team sees it cleared from the active queue.
  6. The operator reviews the day's completed orders from the dashboard summary.

---

v1 scope

Order Management and Fulfillment Tracking
A dedicated dashboard listing every incoming order with status lanes: Pending, Packed, Shipped, Delivered. Team members update status inline, attach tracking references, and the system timestamps each transition so nothing falls through the gap.

Product Upload and Catalog
A form-based product creation screen scoped to sports shoes and apparel only — brand, category, sizes, colorways, price, and image upload. Products publish instantly to the customer-facing storefront.

Payment Processing and Checkout
Customers complete a secure checkout with card payment; funds are captured per order and recorded against the operator account. No payout configuration is required in v1 beyond a single connected bank or payment account.

User Accounts (Operator and Team)
The operator holds an admin account and can invite team members with role-based access — team members can update fulfillment status but cannot change pricing or banking details.

File Uploads (Product Images)
Images attach directly to product records during upload, stored and served at consistent URLs. Supports multiple images per product with a primary image designation for catalog display.

---

Deliberately later

  • Drag-and-drop storefront builder with custom domain — brand customization adds real value once the operational loop is proven stable.
  • Multi-vendor catalog — opening to external sellers introduces trust, payouts, and compliance complexity that belongs in v2.
  • Seller payouts — automated split payouts require financial compliance work; single-operator payout is sufficient for v1.
  • Inventory sync across channels — cross-channel sync only matters once sales volume justifies multiple selling surfaces.
  • Built-in sports product taxonomy — a structured taxonomy accelerates discovery at scale; v1's scoped catalog is small enough to manage manually.
  • Customer analytics and sales reports — reporting becomes actionable once 30+ days of real order data exist.
  • Mobile-responsive checkout experience — mobile optimization is high-impact but should be layered onto a tested checkout flow, not built in parallel with it.

---

Data model sketch

  • users — id, name, email, password_hash, role (admin / team_member), created_at
  • products — id, brand, category (shoe / apparel), name, description, sizes_json, price, stock_count, published, created_by
  • product_images — id, product_id, file_url, is_primary, uploaded_at
  • orders — id, customer_name, customer_email, shipping_address_json, status, total_amount, created_at
  • order_items — id, order_id, product_id, size, quantity, unit_price
  • fulfillment_events — id, order_id, status, tracking_reference, updated_by, timestamp
  • payments — id, order_id, provider_reference, amount, currency, captured_at

---

Screens

  • Storefront / Catalog — public-facing grid of all published products, filterable by category.
  • Product Detail — size selector, images, price, and add-to-cart action.
  • Checkout — address form, payment entry, and order confirmation.
  • Admin: Product Management — create, edit, and publish products with image upload.
  • Admin: Order Dashboard — full order list with status lanes and inline fulfillment updates.
  • Admin: Order Detail — single order view with item breakdown, customer info, and fulfillment history log.
  • Admin: Team Management — invite team members, assign roles, revoke access.

---

How to use this document

  • Bring it into Mind Palace, where the guided platform and its AI coach pick up from exactly this document and build SportShelf with you step by step.
  • Hand it to a developer as the complete v1 brief — scope, data model, and screens are fully defined.
  • Keep it as the single source of truth to resolve any scope question during the build: if a feature is not in v1 scope, it is in "Deliberately later."

This is Ulysse's. Build yours.

A spec like this is step 3 of Mind Palace's nine — the other six take a weekend: working software, a real offer, first customers.

Want to build this with Ulysse?

Tell us who you are and we'll broker the introduction — their contact details stay private until they say yes.