02 / FULL-STACK COMMERCE
In developmentTAUT.
A small brand. A real-world build.
- MY ROLE
- Full-stack development
- BUILT WITH
- React, TypeScript, ASP.NET Core, EF Core & PostgreSQL
- FOCUS
- Order integrity & server-side validation
Hold the tension.
A brand we wanted to build ourselves.
TAUT started with my housemates and a straightforward ambition: build a business of our own. After considering reselling existing products, we decided to create our own press-on nail brand instead.
We landed on TAUT: a Sydney-born, gender-fluid nail brand with a sharp visual identity and the line “Hold the tension.” I’m building its commerce website with React, ASP.NET Core, EF Core and PostgreSQL.
The branding sets the direction; the application is still in development. Here is the current cart-to-checkout interface.
Choose a product variant, then adjust its quantity in the cart. The cart persists across a refresh.
Connecting the storefront to an order API.
I write and revise the application in small, guided steps: product browsing and variant selection in React, a persistent cart, and a guest order flow backed by C# and PostgreSQL. The work connects form state and API contracts to validation, database models and migrations.
A central lesson has been separating what the browser displays from what the server can trust. Cart prices are a preview; the order service owns the final calculation.
How I use AI on this project
I use AI for explanations, implementation guidance and code review. Some code and verification checks are produced or run by the assistant. This is a guided learning project, and I don’t present the whole implementation or its test results as independent work.
An order should keep its own history.
The problem. A browser cart can contain an old or modified price. Product names and prices can also change after an order is placed. An order needs a trustworthy total and a record of what was purchased at the time.
The decision. The request carries variant IDs and quantities. The service validates them, loads current prices from PostgreSQL, and builds item snapshots containing the product name, variant, SKU and unit price. It assembles the order, items and shipping address before one EF Core save.
- 01Validate variants
and quantities - 02Read database prices
and build item snapshots - 03Save one complete
pending order
The trade-off. Snapshots deliberately duplicate catalogue data. That costs storage, but preserves order history when a product changes. Stock validation is a separate concern: the current check does not reserve stock or prevent concurrent overselling.
The result. The implemented API calculates order amounts on the server and stores historical item details. During guided development, assistant-run checks against a temporary PostgreSQL database exercised multi-item orders, untrusted price fields and rollback on a failed address insert. Those checks are evidence for these cases, not a complete regression suite.
An early save and return sat inside the item loop. Guided review helped me move them after all items were processed and fix subtotal accumulation. It made clear why a successful build alone cannot prove the business flow is correct.
Real foundations. More to finish.
- ✓Implemented
Product browsing, variant selection, persistent cart, guest order creation, server-side price and stock checks, and order snapshots.
- ↗︎In progress
Stripe Checkout integration. A test-mode session endpoint exists; the frontend redirect and server-verified payment confirmation are still to come.
- →︎Next
Finish the payment journey, verify it end to end, and prepare the storefront for launch.
The source repository is private. A saved order is not proof of payment. The banner is brand artwork; the interface captures use sample data and show an unfinished application.