FlyFit Fashion Store
An online fashion store with checkout that can't oversell, payments that survive duplicate webhooks, AI search and a shopping assistant that can't make up a price.
note: the demo runs on free hosting, so the first load can take up to a minute while the server wakes up.
note: concept build. The business is fictional, built as a working demo. The software and the test results are real.
Results
- Items oversold with 200 buyers racing for 10 units
- 0
- Shopping assistant tasks completed (40 scenarios, 3 runs)
- 98.3%
- Made-up prices shown, audited against the database
- 0
- Search recall@10, against 0.307 for keyword search
- 0.919
- Prompt-injection attempts resisted
- 18/18
- AI cost per assistant conversation
- $0.0005
cat problem.md
The problem
Most online shops look fine until they're busy. When 200 people press "Pay" for the last 10 dresses, or the payment provider sends the same confirmation five times, a store can sell stock it doesn't have, charge twice or send two refunds. AI features add their own risks, such as a search box that misses what shoppers mean, or an assistant that quotes a wrong price with total confidence.
What we built
A complete store. 150 products across ankara, adire, aso-oke, agbada and ready-to-wear, with a bag, accounts, an admin area and Paystack checkout.
Search that understands shoppers. Keyword and meaning-based search are combined, and a small AI step turns “wedding outfit under 50k” into filters for occasion and price.
A shopping assistant. It searches, compares, checks sizes and store policies, and edits the bag. It cannot place an order, read another customer’s order or show a price that isn’t in the shop’s own price data: those rules are enforced in code, not just requested in the prompt.
Recommendations and product copy. “Similar items” and “bought together” suggestions, plus an AI pipeline that drafts product descriptions, rejects claims the product data doesn’t support, and waits for a person to approve them.
Built for busy days
Stock is held for 15 minutes the moment a shopper starts checkout, in the same database step that creates the order. In a test with 200 buyers pressing “Pay” at once for 10 units, exactly 10 orders were paid and nothing was oversold. To prove the test could fail, we broke the code on purpose and watched the next safety layer catch it.
Payments are handled just as carefully. The same payment confirmation sent five times records one payment. A customer who pays after their hold has expired either gets the item, if stock is still free, or an automatic refund with an apology email.
The result we didn’t hit
Search scored 0.919 on the 50 test queries used while building it. On ten queries written separately and never used for tuning, it scored 0.762, below our 0.85 target. We report that number rather than tune it away, because it is the honest measure of how search performs on questions nobody planned for.
What this means for your business
The same approach works for any shop or booking system that takes payments: decide what “correct” means before building, test the busy-day cases, and keep AI features on a short leash that’s enforced in code.
cat project.json
- industry:
- Retail and e-commerce
- built:
- October 2026
- stack:
- PythonFastAPIPostgres + pgvectorNext.jsTypeScriptTailwindClaude Haiku 5.5Voyage embeddingsPaystackResendDockerGitHub ActionsVercelRender