Build StyleFlow: An Online Clothing Store with an Agentic Workflow
In the previous articles, we created the foundation for an agentic development system.
We defined:
W — Workflow
A — Agent
T — Tools
We also created project instructions, Skills, testing rules, database guidance, Git checkpoints, and tool policies.
Now we are ready to use that system to build a real application:
StyleFlow — a modern online clothing store built with Claude and an agentic workflow.
The goal of this article is not to manually write every line of code ourselves.
Instead, we will give Claude:
- a clear business goal,
- a structured workflow,
- specialist Skills,
- access to development tools,
- testing requirements,
- and human approval boundaries.
Claude will then help create the application, run tests, inspect failures, and improve the result.
1. What StyleFlow Will Include
Our first complete version of StyleFlow will include:
StyleFlow
│
├── Home page
├── Product catalogue
├── Categories
├── Product details
├── Search
├── Shopping cart
├── Checkout
├── Orders
├── Admin area
├── Database
└── Automated tests
The application should work on both desktop and mobile.
We will not include real payments yet.
That will come later.
For this version, checkout will create an order in the database.
2. Our Existing Agentic Project Structure
Our project already contains the files created in the previous articles:
styleflow-wat/
│
├── PRODUCT.md
├── WORKFLOW.md
├── CLAUDE.md
├── README.md
├── .gitignore
│
├── skills/
│ ├── ui-design/
│ ├── frontend-development/
│ ├── backend-development/
│ ├── database-design/
│ ├── testing/
│ ├── security-review/
│ └── deployment/
│
├── docs/
└── tests/
Claude will use these instructions as context while building the project.
3. Give Claude the Main Build Goal
Open the StyleFlow project in VS Code.
Then start Claude Code in the project folder.
Our first major implementation prompt can be:
Read PRODUCT.md, WORKFLOW.md and CLAUDE.md.
Build StyleFlow Version 1.
Use the relevant Skills in the project.
Implement:
- product catalogue
- categories
- product details
- product search
- shopping cart
- checkout
- order creation
- basic admin pages
- persistent database storage
- automated tests
- responsive user interface
Make reasonable technical decisions yourself.
Prefer simple, maintainable solutions.
Run tests after implementation.
If tests fail, investigate the cause, correct the code,
and run the tests again.
Do not add real payments.
Do not deploy publicly.
When finished, report:
- files created
- architecture decisions
- tests run
- test results
- known limitations
- recommended next step
This is important.
We are not saying:
Create file A, then create file B, then write exactly this function.
Instead, we provide:
Goal
+
Constraints
+
Acceptance criteria
+
Tools
That is the essence of agentic development.
4. Claude Reviews the Existing Project
Before changing code, Claude should inspect:
PRODUCT.md
WORKFLOW.md
CLAUDE.md
skills/
docs/
tests/
Then it may create or update an implementation plan.
For example:
Phase 1
Project foundation
Phase 2
Database models
Phase 3
Product catalogue
Phase 4
Shopping cart
Phase 5
Checkout and orders
Phase 6
Admin pages
Phase 7
Testing
Phase 8
Security and UX review
This plan can differ slightly depending on the agent’s decisions.
That is normal.
5. Claude Chooses the Architecture
Suppose Claude decides to use:
Python
Flask
SQLAlchemy
SQLite
Jinja templates
CSS
Pytest
For Version 1, this is a reasonable simple architecture.
The exact choice is less important than the decision process.
Claude should document the decision in:
docs/decisions.md
For example:
# Architecture Decisions
## Backend
Flask selected for Version 1.
Reasons:
- simple application structure
- suitable for server-rendered pages
- easy to test
- fast local development
## Database
SQLite selected for local development.
The application should keep database access structured
so PostgreSQL can replace SQLite later.
## Frontend
Jinja templates and responsive CSS.
A separate frontend framework is not required for Version 1.
## Testing
Pytest for automated application tests.
6. A Possible Final Project Structure
Claude may produce something similar to:
styleflow-wat/
│
├── app.py
├── config.py
├── requirements.txt
│
├── app/
│ ├── __init__.py
│ ├── models.py
│ ├── routes/
│ │ ├── store.py
│ │ ├── cart.py
│ │ ├── checkout.py
│ │ └── admin.py
│ │
│ ├── services/
│ │ ├── cart_service.py
│ │ └── order_service.py
│ │
│ ├── templates/
│ │ ├── base.html
│ │ ├── index.html
│ │ ├── products.html
│ │ ├── product.html
│ │ ├── cart.html
│ │ ├── checkout.html
│ │ ├── order_success.html
│ │ └── admin/
│ │ ├── products.html
│ │ └── orders.html
│ │
│ └── static/
│ ├── css/
│ │ └── style.css
│ └── images/
│
├── tests/
│ ├── test_products.py
│ ├── test_cart.py
│ └── test_checkout.py
│
├── skills/
├── docs/
├── PRODUCT.md
├── WORKFLOW.md
├── CLAUDE.md
└── README.md
Your exact generated structure may be different.
That is fine.
7. Build the Product Database
Claude should use the database-design Skill.
The main entities may include:
Category
Product
Order
OrderItem
Later we can add:
Customer
Store
Payment
Shipment
Subscription
For Version 1, the simpler model is enough.
8. Product Model
A simplified product model may look like:
class Product(db.Model):
id = db.Column(
db.Integer,
primary_key=True
)
name = db.Column(
db.String(150),
nullable=False
)
description = db.Column(
db.Text,
nullable=False
)
price = db.Column(
db.Numeric(10, 2),
nullable=False
)
category_id = db.Column(
db.Integer,
db.ForeignKey("category.id"),
nullable=False
)
stock = db.Column(
db.Integer,
nullable=False,
default=0
)
image = db.Column(
db.String(255)
)
active = db.Column(
db.Boolean,
default=True
)
This gives each product:
Name
Description
Price
Category
Stock
Image
Status
9. Category Model
A simple category model might be:
class Category(db.Model):
id = db.Column(
db.Integer,
primary_key=True
)
name = db.Column(
db.String(100),
unique=True,
nullable=False
)
Example categories:
Women
Men
Accessories
Shoes
10. Order and OrderItem Models
The store also needs orders.
A simplified order model:
class Order(db.Model):
id = db.Column(
db.Integer,
primary_key=True
)
customer_name = db.Column(
db.String(150),
nullable=False
)
email = db.Column(
db.String(200),
nullable=False
)
phone = db.Column(
db.String(50),
nullable=False
)
total = db.Column(
db.Numeric(10, 2),
nullable=False
)
status = db.Column(
db.String(30),
default="new"
)
Each order contains multiple order items.
class OrderItem(db.Model):
id = db.Column(
db.Integer,
primary_key=True
)
order_id = db.Column(
db.Integer,
db.ForeignKey("order.id"),
nullable=False
)
product_id = db.Column(
db.Integer,
nullable=False
)
product_name = db.Column(
db.String(150),
nullable=False
)
unit_price = db.Column(
db.Numeric(10, 2),
nullable=False
)
size = db.Column(
db.String(20)
)
quantity = db.Column(
db.Integer,
nullable=False
)
The important part is that OrderItem preserves the price paid at the time of purchase.
11. Add Sample Products
For development, Claude can create sample products.
For example:
Classic Linen Shirt
Men
799 SEK
Summer Dress
Women
1,099 SEK
Minimal Sneakers
Shoes
899 SEK
Leather Evening Bag
Accessories
349 SEK
These products allow us to test the full shopping experience before adding real store data.
12. Build the Home Page
The UI-design Skill should guide the look and feel.
StyleFlow should feel:
Modern
Elegant
Clean
Premium
Simple
Responsive
The home page may contain:
STYLEFLOW
Modern fashion for everyday life.
[ Shop Women ] [ Shop Men ]
Featured Products
New Arrivals
Categories
A simple page structure could be:
<section class="hero">
<h1>StyleFlow</h1>
<p>
Modern fashion for everyday life.
</p>
<a href="/products">
Shop Collection
</a>
</section>
WordPress heading rules do not apply inside the application itself.
The store page can still use normal semantic HTML such as H1 for its main page title.
13. Build the Product Catalogue
A route might look like:
@store.route("/products")
def products():
products = Product.query.filter_by(
active=True
).all()
return render_template(
"products.html",
products=products
)
The template then displays product cards.
Example:
{% for product in products %}
<div class="product-card">
<img
src="{{ product.image }}"
alt="{{ product.name }}"
>
<h3>
{{ product.name }}
</h3>
<p>
{{ product.price }} SEK
</p>
<a href="/products/{{ product.id }}">
View Product
</a>
</div>
{% endfor %}
14. Add Product Search
The customer should be able to search.
For example:
Search:
jacket
A simple search route could use:
query = request.args.get(
"q",
"",
type=str
).strip()
Then:
products_query = Product.query.filter_by(
active=True
)
if query:
products_query = products_query.filter(
Product.name.ilike(
f"%{query}%"
)
)
Now:
/products?q=shirt
can return matching products.
15. Build Product Details
When a customer selects a product, the page should show:
Product image
Product name
Description
Price
Available sizes
Stock
Quantity
Add to Cart
For example:
Classic Linen Shirt
799 SEK
Soft linen shirt designed for
warm summer days.
Size
[ S ] [ M ] [ L ] [ XL ]
Quantity
[-] 1 [+]
[ Add to Cart ]
16. Add the Shopping Cart
The cart is one of the most important parts of the store.
The customer should be able to:
Add product
Change quantity
Remove product
See subtotal
Continue shopping
Proceed to checkout
A simplified add-to-cart route may look like:
@cart.route(
"/cart/add/<int:product_id>",
methods=["POST"]
)
def add_to_cart(product_id):
product = Product.query.get_or_404(
product_id
)
size = request.form.get("size")
quantity = request.form.get(
"quantity",
1,
type=int
)
if quantity < 1:
quantity = 1
cart_data = session.get(
"cart",
{}
)
key = f"{product.id}:{size}"
if key in cart_data:
cart_data[key]["quantity"] += quantity
else:
cart_data[key] = {
"product_id": product.id,
"name": product.name,
"size": size,
"quantity": quantity
}
session["cart"] = cart_data
return redirect(
url_for("cart.view_cart")
)
17. Do Not Trust the Price in the Browser
This is an important security rule.
The browser should not be trusted to determine the final price.
Suppose a product costs:
799 SEK
A malicious user could attempt to modify the browser data to:
1 SEK
Therefore, during checkout, the server should reload the real price from the database.
For example:
product = db.session.get(
Product,
item["product_id"]
)
line_total = (
product.price *
item["quantity"]
)
The server calculates the final total.
18. Build Checkout
The checkout page may ask for:
Name
Email
Phone
Address
Postal code
City
Example:
<form method="post">
<label>Name</label>
<input
type="text"
name="name"
required
>
<label>Email</label>
<input
type="email"
name="email"
required
>
<label>Phone</label>
<input
type="tel"
name="phone"
required
>
<label>Address</label>
<input
type="text"
name="address"
required
>
<button type="submit">
Place Order
</button>
</form>
For this version, checkout creates the order.
It does not yet make a real payment.
19. Create the Order
When checkout is submitted, the application should:
Validate customer information
↓
Read cart
↓
Reload products from database
↓
Calculate real total
↓
Create Order
↓
Create OrderItems
↓
Commit transaction
↓
Clear cart
↓
Show confirmation
This is an important business workflow.
20. Generate an Order Reference
We can make the customer experience more professional by showing an order reference.
For example:
SF-2026-00142
After checkout:
Thank you for your order!
Order reference:
SF-2026-00142
Total:
1,099 SEK
This reference can later also appear in email confirmations.
21. Build the Admin Area
Version 1 should include a basic admin area.
For example:
STYLEFLOW ADMIN
Products
Orders
Inventory
The order page could display:
SF-2026-00142
Anna Andersson
1,099 SEK
New
SF-2026-00141
Erik Svensson
1,598 SEK
Processing
For a real production store, admin authentication and authorization are essential.
For our development version, the admin interface can remain basic, but Claude’s security review should flag authentication as a requirement before production use.
22. Add Automated Tests
Claude should now use the testing Skill.
Important tests include:
Product listing
Search
Product details
Add to cart
Update cart
Remove from cart
Checkout validation
Order creation
Invalid product
For example:
def test_product_list(
client,
sample_product
):
response = client.get(
"/products"
)
assert response.status_code == 200
assert b"Classic Linen Shirt" \
in response.data
23. Test Add to Cart
Example:
def test_add_to_cart(
client,
sample_product
):
response = client.post(
f"/cart/add/{sample_product.id}",
data={
"size": "M",
"quantity": 2
},
follow_redirects=True
)
assert response.status_code == 200
assert b"Classic Linen Shirt" \
in response.data
24. Test Checkout
A checkout test may confirm that an order is created.
Conceptually:
def test_checkout_creates_order(
client,
sample_product
):
client.post(
f"/cart/add/{sample_product.id}",
data={
"size": "M",
"quantity": 1
}
)
response = client.post(
"/checkout",
data={
"name": "Anna Andersson",
"email": "anna@example.com",
"phone": "0701234567",
"address": "Test Street 1"
},
follow_redirects=True
)
assert response.status_code == 200
assert b"Thank you for your order" \
in response.data
25. Let Claude Enter the Agentic Test Loop
Now the most important part.
Claude runs:
pytest
Suppose the result is:
21 passed
3 failed
Our workflow says:
Tests failed
↓
Read failures
↓
Identify root cause
↓
Inspect relevant files
↓
Modify implementation
↓
Run tests again
Claude may then get:
23 passed
1 failed
It continues.
Eventually:
24 passed
This is where the agentic workflow becomes visible.
Claude is not simply generating code.
It is:
Acting
↓
Observing
↓
Evaluating
↓
Correcting
26. Review the UI
After the tests pass, automated tests are not enough.
We also need to inspect the interface.
Check:
Desktop view
Mobile view
Navigation
Product cards
Search
Cart
Checkout
Buttons
Form labels
Error messages
Spacing
The UI Skill can guide Claude to improve problems.
For example:
Product cards have different heights
Claude can update the layout.
Or:
Checkout is difficult on mobile
Claude can improve responsive CSS.
27. Run a Security Review
Next, ask Claude to apply the security-review Skill.
Example prompt:
Review the current StyleFlow Version 1 implementation
using the security-review skill.
Focus on:
- input validation
- sessions
- admin routes
- database handling
- secrets
- error messages
- user-controlled data
Do not implement payment functionality.
Report critical issues first.
Fix safe development issues where appropriate.
Do not make production infrastructure changes.
Possible findings may include:
Admin has no authentication
Missing CSRF protection
Weak session configuration
Insufficient form validation
Development secret key
Unsafe production configuration
This is useful because the agent reviews the application from a different specialist perspective.
28. Review Changes with Git
Run:
git status
Then:
git diff
Review what Claude changed.
Do not automatically accept everything simply because tests pass.
Check:
Architecture
Database models
Routes
Validation
Tests
README
Security findings
If you are satisfied:
git add .
Then:
git commit -m "Build StyleFlow Version 1"
Now we have a stable checkpoint.
29. The Final Customer Experience
A visitor opens StyleFlow.
They see something similar to:
STYLEFLOW
Modern fashion for everyday life.
[ Shop Collection ]
Below:
FEATURED PRODUCTS
Classic Linen Shirt
799 SEK
[ View Product ]
Another card:
Summer Dress
1,099 SEK
[ View Product ]
30. Product Page
The customer opens:
Summer Dress
1,099 SEK
Elegant summer dress
for special occasions.
Size
[ S ] [ M ] [ L ]
Quantity
[-] 1 [+]
[ Add to Cart ]
31. Cart
The cart displays:
YOUR CART
Summer Dress
Size M
1 × 1,099 SEK
Subtotal:
1,099 SEK
[ Continue Shopping ]
[ Proceed to Checkout ]
32. Checkout
The customer enters:
Name
Email
Phone
Address
Postal Code
City
Then selects:
Place Order
33. Order Confirmation
The final page displays:
Thank you for your order!
Order Reference:
SF-2026-00142
Total:
1,099 SEK
Your order has been received.
34. Admin Experience
The administrator may see:
STYLEFLOW ADMIN
Products: 48
Orders: 132
Low Stock: 7
Recent orders:
SF-2026-00142
Anna Andersson
1,099 SEK
New
This is our first complete practical output.
35. What Claude Did as the Agent
Claude did not only generate individual snippets.
It followed a workflow:
Read goal
↓
Understand requirements
↓
Select Skills
↓
Plan architecture
↓
Create database
↓
Build application
↓
Run tests
↓
Inspect failures
↓
Correct problems
↓
Review security
↓
Update documentation
↓
Report result
This is much closer to working with an AI development agent.
36. Where WAT Appeared in the Project
Our WAT model is now very clear.
Workflow
PRODUCT.md
WORKFLOW.md
CLAUDE.md
These define:
Goal
Rules
Process
Boundaries
Definition of done
Agent
Claude Code
Claude:
Understands
Plans
Chooses
Implements
Observes
Adapts
Tools
Files
Terminal
Git
Database
Tests
Skills
These give Claude the ability to perform real development work.
37. Why This Is Non-Deterministic
Suppose the requirements change.
Instead of:
Small clothing store
we now say:
100 stores
Multiple countries
Separate mobile app
Public API
High traffic
Claude may make different architectural decisions.
It may choose:
PostgreSQL
API backend
Separate frontend
Background workers
Object storage
The exact implementation depends on the goal and context.
That is what we mean by a controlled non-deterministic workflow.
38. What StyleFlow Still Needs Before Real Customers
Our Version 1 is a useful MVP, but it is not yet ready for a real commercial store.
Before real customers, we still need:
Authentication
Admin authorization
Production database
Payment provider
Email confirmation
Inventory improvements
CSRF protection
Production security
Backups
Monitoring
Deployment
Privacy policy
Terms
We should not confuse:
Working development application
with:
Production-ready commercial service
That distinction is very important.
39. From Application to Business
Now we have an online clothing store.
But the larger idea is much more interesting.
Instead of selling only one website, we could eventually build:
StyleFlow Platform
│
├── Store A
├── Store B
├── Store C
└── Store D
Each customer could have:
Own products
Own branding
Own orders
Own customers
Own settings
Then StyleFlow becomes a SaaS product.
40. Add an AI Shopping Assistant Later
We can also add an AI shopping agent.
A customer could ask:
I need something elegant for a summer wedding. My budget is 1,500 SEK.
The agent could:
Understand request
↓
Search products
↓
Check inventory
↓
Compare prices
↓
Recommend items
Example result:
Summer Dress
1,099 SEK
Evening Bag
349 SEK
Total
1,448 SEK
Now StyleFlow becomes more than a normal online store.
It becomes an AI-assisted shopping platform.
41. What We Learned
In this project, we used the WAT model to create a complete application.
We started with:
Business Goal
Then added:
Workflow
Then:
Claude Agent
Then:
Skills
+
Tools
Finally, the agent used feedback from:
Tests
Database
Application output
Git
Security review
to improve the result.
The full process looked like:
GOAL
↓
WORKFLOW
↓
CLAUDE AGENT
↓
SKILLS
↓
TOOLS
↓
IMPLEMENT
↓
TEST
↓
OBSERVE
↓
CORRECT
↓
REVIEW
↓
HUMAN APPROVAL
That is a practical agentic development workflow.
Conclusion
StyleFlow demonstrates the difference between simply asking AI to generate code and giving an AI agent a structured environment in which it can work toward a goal.
We gave Claude:
A product goal
A workflow
Project rules
Skills
Tools
Tests
Feedback
Human boundaries
Claude then helped turn those instructions into a working online clothing-store application.
The next step is to turn this single application into something more commercially useful.
We will explore:
Multiple stores
Customer onboarding
Subscriptions
Payments
AI shopping assistant
Automation
Deployment
Recurring revenue
That is where StyleFlow begins to move from a development project toward an AI-powered SaaS business.
→ Next Article: Turn StyleFlow into an AI-Powered SaaS Business