Case Study: Stilo - AI-Enhanced Peer-to-Peer Fashion Marketplace
Executive Summary
In the peer-to-peer (P2P) circular fashion market, operational friction on the supply side and poor curation on the demand side are the primary drivers of user churn. For Stilo, a growth-stage circular commerce platform, Seven Labs designed and engineered a scalable AI-driven infrastructure to solve two-sided marketplace liquidity. The goal was to transform the listing, pricing, and discovery experiences to compete effectively with established incumbents like Depop and Vinted.
Over a three-month development lifecycle, we built a three-pronged AI solution:
- An AI Listing Assistant that utilizes computer vision to generate complete listings (descriptions, tags, size, and condition) from a single photo upload, reducing listing time from 8 minutes to under 90 seconds.
- A Smart Pricing Engine trained on 60,000+ historical transactions that dynamically recommends optimal listing prices based on brand, condition, category, and real-time market demand.
- A Personalized Discovery Engine powered by a real-time collaborative filtering taste graph that continuously adapts each buyer's feed based on behavioral signals.
This integration resulted in a 70% increase in listing creation speed, a 44% lift in transaction completion rates, and a 31% increase in the repeat user rate within the first quarter of deployment.
Business Problem
Marketplace liquidity relies on a self-sustaining flywheel: sellers need a friction-free listing process to catalog inventory, and buyers need an intuitive, highly personalized feed to discover items they want at fair prices. Stilo faced three core challenges that stalled this flywheel:
- Supply-Side Listing Friction: Manual listing creation was an operational bottleneck. To list a single item, sellers had to upload photos, write descriptions, specify brand names, select category paths, input sizes, grade the item's condition, and manually assign tags. This process took an average of 8 minutes, leading to a 52% listing creation abandonment rate.
- Pricing Disconnect: Amateur sellers struggled to price items accurately. Overpricing led to stagnant inventory and buyer disengagement, while underpricing eroded seller margins and platform transaction volume (GMV). Without baseline transaction reference data, pricing was arbitrary.
- Curation Failure: As the catalog expanded to hundreds of thousands of individual items, standard category search filters failed. Buyers were overwhelmed by irrelevant listings, resulting in low browse-to-purchase conversion rates.
Stilo needed an engineering partner to build a robust SaaS platform that resolved listing friction, stabilized transactional pricing, and curated buyers' feeds in real time.
Technical Challenges
Transitioning Stilo from a standard catalog application to an AI-enhanced marketplace required solving several system and architecture challenges:
1. Visual Structural Extraction and Schema Enforcement
Sellers upload images containing highly variable backgrounds, lighting, and angles. Processing these images through a multimodal vision model like GPT-4 Vision to extract clean metadata is difficult. Large language models (LLMs) often return unstructured text, markdown, or incomplete JSON formats, which break standard PostgreSQL insertion queries. The system needed to guarantee that visual analysis outputs conformed strictly to the database's schema rules.
2. Pricing Engine Latency and Dynamic Regression
The pricing engine needs to evaluate dozens of variables-brand equity, item category, wear and tear, seasonality, and demand trends-and return a suggested pricing tier (Floor, Target, Ceiling) in under 100ms. Running complex regression algorithms or remote API calls sequentially during the listing flow introduces unacceptable lag.
3. Real-Time Taste Graph Updates
Traditional recommendation systems operate in daily or hourly batches. In P2P fashion, inventory is highly transient; items are often unique (one-of-a-kind listings). A batch recommendation engine cannot respond quickly to a buyer's immediate session-based intent. If a user clicks on three distinct streetwear hoodies, the feed must adapt in real time to display similar inventory before they close the app.
4. Split-Payment and Escrow Integration at Scale
P2P transactions require secure escrow management. Funds must be captured from the buyer, held securely, and released to the seller only after delivery is confirmed and the item passes the buyer's inspection. Managing these flows while automating platform fee deductions and refund processing requires a highly robust transaction state machine.
Solution Architecture
The marketplace architecture leverages a Next.js frontend, a Python microservice layer for AI models, a relational PostgreSQL core, and a real-time Redis caching layer.
+-----------------------------+
| Next.js Mobile-First |
| Web & React Native App |
+-----------------------------+
/ \
Upload Images / \ API Queries & Feeds
/ \
\/ \/
+-----------------+ +---------------------+
| AWS S3 Bucket | | Node.js API Gateway|
+-----------------+ +---------------------+
| |
Image REST /
Metadata JSON
| |
\/ \/
+--------------------------------------------------+
| Seven Labs Backend Services |
| (TypeScript / NestJS) |
+--------------------------------------------------+
/ | | \
/ | | \
gRPC / HTTP SQL Redis HTTPS
/ | | \
\/ \/ \/ \/
+--------------------+ +---------------+ +-----------+ +------------------+
| Python Inference | | PostgreSQL DB | | Redis Feeds| | Stripe Connect |
| (Pricing & Recs) | | (Core Schema) | | & Caching | | (Escrow/Split) |
+--------------------+ +---------------+ +-----------+ +------------------+
/ \ |
Image / Vectors \ | Sync
/ \ |
\/ \/ \/
+-------------+ +-------------------+
| GPT-4 Vision| | Pinecone Vector DB|
+-------------+ +-------------------+
Component Breakdown
- AWS S3 & CloudFront CDN: Handles raw image uploads. The client compresses images locally before uploading them to S3, triggering an S3 event notifications Lambda to generate WebP variants.
- Node.js / NestJS API Gateway: Acts as the traffic cop. It handles authentication, API routing, and input validation, communicating with downstream services via gRPC.
- Python Inference Microservice: Executes the smart pricing model and coordinates vector generations for the taste graph. It interfaces with the OpenAI API and Pinecone.
- PostgreSQL Relational DB: Serves as the primary source of truth, storing users, listings, transaction logs, and escrow state variables.
- Redis Cache & Activity Store: Powers the real-time feeds, caches API responses, and manages rate limits for the listing and search endpoints.
- Stripe Connect: Orchestrates the financial ledger, processing split-payments, holding escrow balances in transient accounts, and managing automated seller payouts.
Technology Stack
We selected the technology stack to balance development speed, database reliability, and low-latency API serving:
- Core SaaS Application Platform: Built on Next.js (v14) for the web application and NestJS (Node.js framework) for the backend microservices. The project is managed using a monorepo setup with
npm workspaces. Read more about our application development methodologies on our SaaS Development service page.
- Database & Caching Layer: PostgreSQL running on AWS RDS, utilizing GIN indexes for rapid text-based search. Redis serves as our caching layer and session store.
- Computer Vision and Schema Parsing: OpenAI GPT-4 Vision API, integrated with Instructor (Python) and Pydantic to enforce structured JSON output formats during image processing.
- Recommendation System: A custom hybrid filtering engine. It combines collaborative filtering (user-item interaction matrix) with semantic text embeddings of item descriptions generated via
text-embedding-3-small and indexed in Pinecone Vector DB.
- Payment Processing: Stripe Connect (Custom Account integration), enabling Stilo to maintain full control over the user experience and escrow release conditions.
- Deployment & Orchestration: Docker containers deployed to AWS Elastic Container Service (ECS) with Fargate, managed via Terraform infrastructure-as-code scripts.
Implementation Process
The implementation was executed in a 12-week chronological timeline, transitioning from data ingestion to live production deployment:
Phase 1: Developing the Vision Listing Pipeline (Weeks 1-3)
Our first goal was to reduce listing friction. We built a NestJS route that accepts image URLs from AWS S3, forwards them to a Python microservice, and processes them through GPT-4 Vision. To ensure the output matches our database schema, we used Pydantic models.
Here is the Python microservice implementation for extracting listing metadata:
import os
from pydantic import BaseModel, Field
from typing import List, Optional
from openai import OpenAI
import instructor
# Define target schema using Pydantic
class FashionItemSchema(BaseModel):
brand: str = Field(description="Recognized fashion brand, default to 'Unbranded' if unknown.")
category: str = Field(description="Primary category, e.g. Tops, Bottoms, Outerwear, Shoes, Accessories.")
subcategory: str = Field(description="Specific subcategory, e.g. Hoodie, Denim, Chelsea Boots.")
color: str = Field(description="Dominant color of the item.")
condition: str = Field(description="Guessed condition tier: New-with-tags, Excellent, Good, Fair.")
estimated_retail_price: Optional[float] = Field(description="Estimated original retail price if brand is recognizable.")
suggested_tags: List[str] = Field(description="Max 5 SEO-optimized tags for marketplace search indexing.")
generated_description: str = Field(description="A catchy, sales-oriented, SEO-friendly description highlighting brand and style.")
# Initialize OpenAI client wrapped with Instructor
client = instructor.patch(OpenAI(api_key=os.environ.get("OPENAI_API_KEY")))
def analyze_item_image(image_url: str) -> FashionItemSchema:
return client.chat.completions.create(
model="gpt-4o",
response_model=FashionItemSchema,
messages=[
{
"role": "user",
"content": [
{"type": "text", "text": "Analyze this clothing item image and extract structured listing data according to the schema rules."},
{"type": "image_url", "image_url": {"url": image_url}}
]
}
],
temperature=0.1
)
By constraining the model output to a Pydantic schema, we eliminated formatting errors, allowing the system to populate the frontend listing fields instantly in under 1.2 seconds.
Phase 2: Building the Dynamic Pricing Engine (Weeks 4-6)
We compiled a dataset of 60,000+ historical sales lines from Stilo’s early beta and open ecommerce datasets. We trained a XGBoost regression model on variables including Brand tier, Item Subcategory, Condition Grade, and Seasonal demand. The model yields three price points:
- Floor Price: The lowest price bound to ensure a quick sale.
- Target Price: The optimal price based on historical market clearing points.
- Ceiling Price: The maximum realistic value for premium buyers.
We deployed this model as a lightweight Python service on AWS Lambda behind an API Gateway, keeping response times under 85ms.
Phase 3: Engineering the Taste Graph and Feeds (Weeks 7-9)
To curate the buyer feed, we built a real-time collaborative filtering graph. When a user interacts with an item (views details, adds to wishlist, or shares), the NestJS API gateway publishes a payload to a RabbitMQ queue.
A Python worker consumes the events, retrieves the item’s vector representation from Pinecone, and updates the user's running preference vector in Redis:
$$\vec{u}{new} = \vec{u}{old} + \alpha (\vec{v}{item} - \vec{u}{old})$$
Where $\alpha$ represents the learning rate (decay factor) based on interaction type (e.g., view = 0.1, favorite = 0.4). The Next.js home feed queries Pinecone using the user's updated vector $\vec{u}_{new}$ to fetch similar items, yielding a personalized feed that refreshes instantly.
This vector retrieval strategy is detailed further in our blog post on why RAG pipelines fail and our guide on advanced RAG chunking.
Phase 4: Integrating Escrow and Stripe Connect (Weeks 10-11)
We implemented Stripe Connect using a Custom Account model. When a buyer purchases an item, our NestJS transaction server creates a payment intent with transfer_group parameters, holding the funds in escrow on Stilo's platform balance.
Upon verification of shipment delivery via the Shippo API, the system executes a transfer to the seller's Stripe balance, deducting Stilo's 12.5% transaction commission automatically. If the buyer reports an issue within a 48-hour inspection window, the system halts payout pending dispute resolution.
Phase 5: Testing, Security Audits, and Release (Week 12)
We conducted load testing simulating 12,000 concurrent page requests and 50 listing uploads per second. We verified API endpoint security, ran penetration testing against our payment webhook gateways, and pushed the Next.js updates live.
Security Considerations
Operating a financial P2P transaction platform requires strong security protocols:
- Stripe Webhook Signature Verification: Hackers often attempt to spoof Stripe webhook events (e.g., sending fake
charge.succeeded payloads) to trigger payouts. Our gateway strictly validates the Stripe-Signature header against our signing secret using Stripe's native libraries, rejecting unsigned traffic.
- Image Sanitization and Malware Scanning: Uploaded listing photos can be vectors for malware injection. To address this, images uploaded to S3 trigger an AWS Lambda function that parses the files, strips metadata (EXIF data containing coordinates and device identifiers to protect user privacy), and forces re-encoding into WebP formats, neutralizing payload threats.
- GDPR/CCPA Compliance on Behavioral Data: To comply with user data regulations, all clickstream telemetry collected for the recommendation engine is anonymized. User vectors stored in Redis are indexed using transient identifiers rather than real names or emails. Users can purge their taste graph data directly from their account dashboard.
For details on security frameworks for consumer platforms, review Seven Labs' blog on security challenges in distributed AI.
Performance Optimizations
To ensure Stilo runs smoothly on mobile devices and slow mobile connections, we implemented three key optimizations:
1. Client-Side Image Compression
Sellers frequently upload 12-megapixel raw camera photos, which can exceed 8MB per file. This wastes bandwidth and slows the upload process on mobile connections. We integrated browser-image-compression into the Next.js frontend, reducing image sizes to under 800KB before uploading to AWS S3, cutting upload times by 85%.
2. Database Index Optimization
With millions of active listings, searching the catalog using raw text queries is slow. We configured GIN (Generalized Inverted Index) indexes on PostgreSQL columns containing tag arrays and listing titles:
CREATE INDEX idx_listings_tags ON listings USING gin (tags);
CREATE INDEX idx_listings_title_trgm ON listings USING gin (title gin_trgm_ops);
This configuration reduced query latency for search strings and tags from 850ms to 12ms, even during high-traffic periods.
3. Redis-Backed Infinite Scroll
The homepage feed queries the database frequently. To minimize load on PostgreSQL, we cache user-personalized listing IDs in Redis lists with an expiration window of 3 minutes. When a user scrolls their feed, Next.js fetches the next page of IDs from Redis and retrieves listing metadata via a fast primary-key query, protecting the core database.
These optimizations build upon the high-throughput design patterns discussed in case-studies/apex-vpn and case-studies/rawai-content-engine.
Results & Outcomes
Stilo's post-launch metrics showed significant improvements in seller engagement, buyer conversion, and user retention:
- +70% Listing Creation Speed: Listing an item now takes under 90 seconds, down from an 8-minute average.
- 44% Lift in Transaction Completion: Accurate pricing recommendations and personalized discovery feeds helped convert views to sales more effectively.
- 31% Increase in Repeat User Rate: The personalized feed kept users engaged, driving consistent return visits.
- 0% Escrow Discrepancies: Automated Stripe Connect webhooks handled over 100,000 transactions without ledger issues.
Lessons Learned
Building and launching the Stilo platform provided several key engineering takeaways:
- Multimodal API Costs Can Accumulate Quickly: During the beta launch, we realized that calling GPT-4 Vision for every image upload was expensive. We optimized this by implementing client-side hashing; if a seller uploads duplicate photos, the system resolves the hash against our database and skips calling the vision API, reducing cost overhead.
- Recommendation Cold-Starts Need a Hybrid Approach: Collaborative filtering requires historical interaction data. New users have no interaction history, resulting in a generic feed. We resolved this by introducing a 3-step onboarding flow where users select preferred brands and aesthetics, generating a starting user vector.
- Escrow State Machine Isolation is Mandatory: Integrating shipping webhooks directly into the payout logic can cause failures if third-party APIs experience downtime. We decoupled these systems using RabbitMQ message queues; payout events are processed asynchronously, ensuring reliability even during external API outages.
For a deeper dive into the economics of product automation, read our blog on why automation ROI is flawed. To learn more about ecommerce integrations, see our work with automated customer assistants in shopify-ai-avatar.
Frequently Asked Questions (FAQs)
1. How does the vision assistant handle complex photos with multiple items?
GPT-4 Vision is directed by our system instructions to focus exclusively on the primary foreground object. If the model detects multiple distinct fashion items (e.g., a shirt and a pair of trousers on a hanger), the Pydantic schema validator will reject the response if the classification fields return conflicting information.
The API gateway then prompts the seller to crop the photo or select the target item from a suggested listing box, preventing catalog indexing errors.
2. Why did you choose collaborative filtering over content-based recommendation?
Content-based recommendations tend to suggest items that are very similar to what a user has already viewed (e.g., showing only black Nike hoodies to a user who clicked on one). Collaborative filtering allows for discovery by identifying similarities between user behavior profiles.
If User A and User B share a similar taste profile, and User B buys a vintage trench coat, the system will recommend that coat to User A, driving catalog exploration.
3. How does the system handle refund triggers and return shipping payouts?
We built a transaction state machine in PostgreSQL that tracks the escrow lifecycle. If a buyer initiates a dispute within the 48-hour inspection window, the state transitions to DISPUTED and the Stripe payout is paused.
If the dispute is approved, Stilo generates a return shipping label via the Shippo API. Once the carrier scans the return package, Stripe initiates a refund to the buyer's credit card while deducting the shipping cost from the seller's account balance.
4. How does PostgreSQL handle spatial searching for localized listings?
To allow buyers to filter listings near their zip code (minimizing shipping times and footprint), we integrated the PostGIS extension in PostgreSQL.
The listings table stores geographical coordinates (latitude and longitude) as a spatial geography point. Localized queries use index-supported queries like ST_DWithin to filter items within a specific mile radius, keeping query response times under 20ms.
5. What is the impact of AWS Lambda cold starts on the pricing engine?
AWS Lambda cold starts can delay API response times by up to 1.5 seconds. To prevent this, we configured the Lambda function with provisioned concurrency, keeping 2 instances warm at all times.
We also optimized the deployment package, removing unused Python dependencies and using a lightweight XGBoost model, reducing cold-start occurrences to under 0.2% of all API queries.
Schema & SEO Metadata
Recommended JSON-LD Schema
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "Stilo - AI Fashion Marketplace Case Study",
"description": "How Seven Labs engineered an AI-powered marketplace platform using GPT-4 Vision, collaborative filtering, and Stripe Connect, lifting transactions by 44%.",
"keywords": "SaaS Development, Next.js, GPT-4 Vision, Collaborative Filtering, Stripe Connect, Escrow, PostGIS, P2P Marketplace",
"inLanguage": "en-US",
"author": {
"@type": "Organization",
"name": "Seven Labs",
"url": "https://www.sevenlabs.site"
},
"publisher": {
"@type": "Organization",
"name": "Seven Labs",
"logo": {
"@type": "ImageObject",
"url": "https://res.cloudinary.com/dywx7ldqr/image/upload/v1779223334/media/img_01.png"
}
},
"about": [
{
"@type": "Service",
"name": "SaaS Development - Next.js & MERN",
"url": "https://www.sevenlabs.site/services/saas-development"
}
]
}
Internal Linking Anchors
