This specification was generated by PostIdea from a plain English description of a handmade goods marketplace. The idea took under 5 minutes of Socratic dialogue to fully specify — target users, core workflows, scale expectations, and data relationships. What follows is the complete functional and non-functional requirements breakdown: machine-verifiable, implementation-ready, and structured so your AI coding tool can act on it directly.
If you're looking for an ecommerce app software specification example that goes beyond bullet points and actually tells you what "done" looks like in code, this is it.
Version: 1
Generated by: PostIdea pipeline — Socratic discovery → constraint extraction → spec generation
Acceptance Criteria:
product_id, when GET /api/products/{product_id} is called, then HTTP 200 is returned with {product_name, description, price, images}.product_id, when GET /api/products/{product_id} is called, then HTTP 404 is returned with {error: 'product not found'}.Testable Signals: ProductRepository, get_product_details
Acceptance Criteria:
order_id, when POST /api/reviews is called with {order_id, rating, comment}, then HTTP 201 is returned with {review_id}.order_id, when POST /api/reviews is called, then HTTP 400 is returned with {error: 'invalid order ID'}.Testable Signals: ReviewService, create_review
Acceptance Criteria:
seller_id, when GET /api/sellers/{seller_id}/products is called, then HTTP 200 is returned with {products: [{product_id, name, price}]}.seller_id, when GET /api/sellers/{seller_id}/products is called, then HTTP 404 is returned with {error: 'seller not found'}.Testable Signals: SellerRepository, get_seller_products
Acceptance Criteria:
seller_id, when GET /api/sellers/{seller_id}/orders is called, then HTTP 200 is returned with {orders: [{order_id, product_id, customer_name}]}.seller_id, when GET /api/sellers/{seller_id}/orders is called, then HTTP 404 is returned with {error: 'seller not found'}.Testable Signals: OrderRepository, get_seller_orders
Acceptance Criteria:
GET /api/products/search is called with {keyword}, then HTTP 200 is returned with {products: [{product_id, name, price}]}.GET /api/products/search is called, then HTTP 400 is returned with {error: 'invalid search term'}.Testable Signals: ProductSearchService, search_products
Acceptance Criteria:
category_id, when GET /api/products/categories/{category_id} is called, then HTTP 200 is returned with {products: [{product_id, name, price}]}.category_id, when GET /api/products/categories/{category_id} is called, then HTTP 404 is returned with {error: 'category not found'}.Testable Signals: CategoryRepository, get_category_products
Every functional requirement above has two things most specs don't: a concrete acceptance criterion written in Given/When/Then format with actual HTTP status codes and field names, and a testable signal — a specific identifier (class name, function name) that must appear in your source code for the requirement to be considered implemented.
That's what PostIdea's verification engine checks. Not whether your code "looks right." Whether the identifiers the spec requires are actually present in your implementation.
See how this spec performed against a real implementation →
Want to generate a spec like this for your own idea?
Run your idea through PostIdea →