Delicaté 4.0

01Context

Delicaté is a brand of handmade soaps made in small batches in the Dominican Republic, and I built the site for it. It sells through conversation: the customer asks, chooses and arranges delivery over WhatsApp. The site had to present the brand and the catalog with an experience of its own and bring the customer into that conversation with the order already put together.

The repository keeps two generations. The 2024 one was a conventional store: sign-up and Google sign-in, a server-side cart, reviews, order history and a blog. Version 4.0, rebuilt in August 2026 and in production since September, starts by asking what the business actually needed.

02The problem

A store with accounts, checkout, payments and inventory promises an operation this business doesn't have. Requiring sign-up to buy a bar of soap adds friction and gives nothing back, and a checkout that can't take payment is a broken promise. What it did need was to show the products well, help people choose and receive a clear order, because confirmation, payment and delivery would keep happening over WhatsApp.

03My role

I gathered the requirements with the business, defined the information architecture and the user journey, designed the interface and developed the store, the API and the admin. I also deployed it on its domain and wrote the technical documentation, the launch checklist and the spec for a future line of custom soaps.

04Users

The shopper browses the collection, filters by category, opens each soap's details and builds an order without creating an account. The business team maintains products, prices, stock, photos and featured items from the Django admin, and receives on WhatsApp a readable message with each product, its quantity and the total.

05Constraints

• No payments, no logistics and no promise of real-time stock. That's why the cart total is "estimated".
• A catalog that changes without rebuilding anything. The store reads it from the API on every visit.
• Phone first. That's where the brand's audience shops, and where WhatsApp lives.
• No shopper data. The store keeps no profiles, addresses or orders.

06How I built it

I started from the real sales journey — discover the brand, find a product, understand its benefits, build the order and open the conversation — and removed everything that didn't serve it. The rebuild dropped the previous version's models with explicit migrations (cart, cart lines, reviews and user profiles) and added a data migration to give every product a unique slug. It went from eight models to four, and from thirty runtime dependencies on the frontend to two: React and React DOM.

The backend is three Django apps: shop (catalog, API and admin), contact (messages and subscriptions) and accounts (the team user, who signs in with an email). The frontend is six React components, a cart hook and custom CSS, with no state or component libraries. In September 2026 I got it ready for production: I hardened Django, made the cart sync with the catalog and deployed it on its domain.

07Architecture decisions

• No customer accounts. The custom Django user exists only for the team; the shopper never signs up.
• A public, read-only API. The catalog is read through the API and written only from the admin. The store requests every page of the list, so a bigger catalog never leaves products out.
• A cart that doesn't lie. It lives in localStorage and survives a reload. When the catalog arrives, each line takes the current price, its quantity is capped at the stock and discontinued products drop out of the cart; if something changed, the drawer says so.
• A single container in production. Django serves the API, the admin, the photos and the React build from the same domain, with WhiteNoise: no CORS needed. In development, Vite proxies to Django.
• Demo data never replaces real data. The fallback catalog only shows up in development, or when explicitly enabled, with a visible notice. In production, if the API fails, the customer sees an error with a retry, not made-up products.

08The WhatsApp order

"Finish on WhatsApp" opens a wa.me link with the order already written. There's no WhatsApp API integration and nothing to pay per message: the server doesn't record the order, and the conversation continues on the business's phone. This is the message the cart in the screenshots generates, in Spanish, as the business receives it:

¡Hola, Delicaté!
Quiero realizar este pedido:

• 2 × Avena Calma — RD$700
• 1 × Corazón de Lavanda — RD$425
• 1 × Café Despierto — RD$450

Total estimado: RD$1,575

Mi nombre es:
Prefiero: entrega / recoger

¿Me confirman disponibilidad y forma de entrega? Gracias.

The greeting used to carry an emoji that WhatsApp's web page turned into "�" when it redirected the link; now it goes without it. The contact form does the same with the name and the question: it doesn't store anything on the server either.

09Production and security

• Ship only what works. Every push to main builds the image, applies migrations before release and only sends traffic to the new version if /api/health/, which queries the database, returns 200. If anything fails, the previous one stays up.
• Headers on every response, including the ones WhiteNoise serves: a Content Security Policy, Permissions-Policy and X-Frame-Options; mandatory HTTPS, one-year HSTS and secure cookies.
• Rate limits that count the real IP behind the proxy: a thousand requests per hour per visitor, with tighter caps on the write endpoints.
• A safe startup. With DEBUG off, Django refuses to start with the development key or with a relative photo path.
• Validated photos by format (JPG, PNG, WebP) and size (5 MB), served with a seven-day cache.

10Challenges

The main one was building a convincing shopping experience without faking a payments or logistics infrastructure. The second was keeping the managed catalog, the filters, the product view and a cart that survives between visits consistent when prices or stock change. And the third was cutting down: going from an oversized store to a maintainable product of about 2,600 lines.

11What deployment taught me

• Railway didn't apply railway.json to the service created from the command line, and the first version went out without migrations. The configuration is now pinned on the service itself.
• Git Bash turned the /data/media path into a Windows path, and the photos were lost in a redeploy. I fixed it and added the check that now refuses to start with a relative path.
• When the custom domain was added, Railway stopped exposing the *.up.railway.app address; both hosts are now explicitly allowed.

12Design and UX

The visual direction uses a warm palette of cream, forest green and terracotta, an editorial serif for headlines and plenty of breathing room to communicate craft, without downloading web fonts. The page tells a story in order: home, values, collection, brand story, how to order in three steps, FAQ and contact. When you add a product, the cart opens to confirm the gesture.

The states are all handled: loading, error with retry, empty category and sold-out product. For accessibility, the product view is a native <dialog>, the cart traps and returns focus, the mobile menu closes with Escape, there's a skip-to-content link, filters declare their state with aria-pressed and prefers-reduced-motion is respected.

13What it doesn't have

So nobody assumes otherwise: there are no payments, no in-store search (only the API accepts ?search=), no product variants, no more than one photo per product and no dedicated URL for each soap: the product view is a dialog. There's no order dashboard either, because orders never go through the server. The API keeps two rate-limited endpoints for contact and newsletter that no store screen uses today.

14About the screenshots

The screenshots were taken on September 25, 2026, on the store's production build, served locally with a throwaway database and the catalog's ten products. Some states were triggered on purpose to show them: the sold-out product, the catalog that's slow or fails, the empty category and the saved cart with old prices. What you see in each one is production code. The product photos are the original project's; the lifestyle images on the home page and in the story were generated for this version. Screens with any visible defect were left out.

15What I learned

A good product doesn't need to fake more infrastructure than the business can run. Removing accounts, the server-side cart and checkout made the system smaller, safer and easier to adopt, and turned a real limitation into a coherent flow. The version that delivers the most wasn't the one that did the most, but the one that best fit how the business sells.

16Current status

Live at delicate.jonasjavier.dev since September 25, 2026: a Docker service on Railway with PostgreSQL, a volume for photos and its own domain over HTTPS. The repository is public for evaluation, under a proprietary license, with continuous integration green and 18 automated tests passing. Before announcing it, the checks that depend on the business are still on its launch list: delivery and privacy policies, a full order tested on Android and iPhone, backups and monitoring. I don't publish sales or traffic because I don't measure them.

The product's next line is already specified: a guided custom-soap configurator whose result is a WhatsApp request, not an automatic purchase. It isn't part of the system yet.