Skip to content
ProjectsAboutSay hello
← Projects

Dulce Caribe

Spanish-first commerce platform with WhatsApp order coordination.

Role
Design and engineering, end to end
Year
2026
Status
In progress

In progress. This page describes what I'm building and why; I'll update it with decisions and outcomes as it ships.

The problem

A small Dominican business selling [TODO: what] takes orders the way most small businesses here do — over WhatsApp, message by message. That works until it doesn't: there's no catalog customers can browse on their own, no record of what was ordered, and no inventory anyone can trust.

The obvious answer is "build them a Shopify store," and it's the wrong one. [TODO: say why, in your own words — card payment penetration, the cost per transaction, the fact that customers expect to talk to a human before paying, whatever the real reason is.]

Constraints

  • Spanish first. The interface ships in Spanish. Strings are centralized so English can be added later without a rewrite.
  • Prices in Dominican pesos, stored as integer minor units — no floats touching money.
  • No online payments in v1. Payment and delivery are coordinated by a human. This is a deliberate scope decision, not a missing feature.
  • [TODO: budget and timeline. This is a friend's business — say what that actually meant for how you worked.]

What I'm building

A storefront with a browsable catalog, search, filtering, product detail pages with variants and availability, favorites, and a cart that survives between sessions.

An order-request flow instead of a checkout. The customer builds a cart and submits a request. The server recalculates every price and re-checks inventory against the database — nothing the browser sends about price, total, or availability is trusted. The order is written in a single transaction, and the customer gets an order number plus a prefilled WhatsApp message summarizing what they asked for, so payment and delivery can be settled with a person.

An admin portal for the owner: product and inventory management with an auditable movement history, an order queue with controlled status transitions, and editable homepage content.

Decisions and tradeoffs

Inventory is committed on confirmation, not on submission. A submitted request doesn't decrement stock; an administrator moving the order to confirmed does, and cancelling releases it. The alternative — decrementing at submission — means abandoned requests silently eat inventory the owner can still physically sell. The cost of this choice is that two customers can request the same last item, so the admin interface has to warn about competing requests. That felt like the right trade: a warning an owner can resolve beats phantom stockouts nobody notices.

Authorization lives in server-only domain services, not in components. Pricing, inventory, and order rules are enforced in one place on the server. React components stay presentational. [TODO: expand once it's built.]

[TODO: add the ones that come up while building. The decisions you make under pressure are more interesting than the ones you planned.]

Outcome

[TODO: fill in when it ships — orders processed, time the owner saves, whether the WhatsApp handoff actually gets used the way you expected.]

Stack

Next.js (App Router), TypeScript, Tailwind CSS, Supabase for Postgres, auth and object storage, Zod for validation, Vitest and Testing Library for unit tests, Playwright for end-to-end.