Jenna Cuene

Work

Work in progress

A commerce platform and its first store: a joint initiative, in progress

A work in progress: brand, design system, data model and a working store, built with a client partner and AI coding tools, under rules I wrote so the work could be trusted.

This work is not released, so it is described in general terms. No name, screen or product detail is shown, to protect the partner's position before launch.

Outcome
A work in progress: the platform is on staging and the first store is in testing. Nothing here is a customer result yet.
My role
Researched each approach first; led brand identity, type, design system and themes; prototyped the store; drafted the data model; built the front end, server and database work with AI coding tools; ran decisions with the partners
Team
A joint initiative between my firm, Sandbucket, and a client partner. The partner's business team owns scope, compliance and catalog calls. Final checks on database changes are assisted by the client partner's IT team and an outside technical consultant.
Scope
Technical research, brand identity, type system, design system and theming, prototyping, data modeling, front end, back end, release process, partner decisions
When
Summer 2026 to now
Kind
Build

How I use AI tools here

I direct the work and make the decisions. Before committing to an approach I do the reading: primary documentation, published best practice, and case studies and post-mortems of what worked and what failed. The options, trade-offs and sources go into a decision record before any code is written. Claude Code and Cursor then write most of the code under written rules, automated tests and release checks. Database changes run only on my go-ahead.

Diagrams, drawn for this page

A flow from left to right: brand and type, then one token file, then nine themes, then components and screens. A separate box below, labeled business rules in the data, connects to components and screens with a note that themes cannot change it.
One token source feeds every theme; a theme can change form, never a business rule
Three stages in a row: a prototype wired to a database, a handoff contract made of interfaces, a data contract, rules and tokens, and a production build with tests and release checks.
From prototype to production: the prototype became a contract, not the code
A loop of four steps: a question with a recommendation, a ruling in the decider's own words with the date, a mark for whether it binds the platform, the store or both, and one decisions table everyone reads.
How a shared decision gets made

The problem

A partner business needed to sell online to business buyers in the way those buyers actually order. My firm, Sandbucket, wanted the same foundation to serve other businesses later. So one system had to carry more than one business, more than one look, and rules that change with what is being sold.

It is also a joint initiative, with two organizations deciding together. The work had to earn trust as it went: every decision visible, every claim checkable.

What I did

  • Research first. Before committing to an approach I do the reading: primary documentation, published best practice, and case studies and post-mortems of what worked and what failed. The options, trade-offs and sources go into a decision record before any code is written.
  • Brand identity and type. I ran the identity program end to end and reported to the business team. A custom-drawn wordmark in two optical cuts. Options were shown under neutral codes, so reviewers judged the form and not a name. A three-face type system, each face with one job, with font licensing enforced by an automated check.
  • Design system and theming. Built on an established design kit and customized entirely through variables. About 120 tokens come from one source file, and the build fails on a stray color or an undefined token. Nine interchangeable themes run on one codebase.
  • Prototype. Figma Make prototypes of the store and its operations app, wired to a live database, so the partners reacted to real screens and real data.
  • Data model. I drafted the data model as a decision document: eight decisions, each with a recommendation. Three levels keep every store's data apart by design. Vocabulary and rules are stored as data, so a new kind of business needs no new code. Changes are numbered and only ever add; more than 50 so far, each run only on my go-ahead, on staging first, with final checks assisted by the client partner's IT team and an outside technical consultant.
  • Build. The production front end, server and database work. I direct it and make the decisions, and Claude Code and Cursor write most of the code under written rules, automated tests and release checks: React with server rendering, Express, Postgres, and card payments in test mode. Roughly 1,500 commits in eight weeks on the store and about 240 on the platform, with 500+ unit tests, about 100 browser test specs and about a thousand database checks.
  • Release. A store-wide check at phone and desktop widths before any release, with release notes and a named rollback for every deploy.

Decisions

One shared database, with each store's data walled off, not one database per business. A small team cannot keep many databases in step. The cost is that isolation has to be proven in every table and every test, so it is.

A theme may change how a thing looks and behaves, never what is true. Business rules live in the data. That gave up some freedom in the themes, and it means a new look can never show a buyer something they should not see.

Every shared decision is a question with a recommendation, ruled in the decider's own words. Questions go to the whole group, not at one person, and nobody is assigned work without agreeing to it. Each ruling is dated, marked as binding the platform, the store or both, and written once in a table everyone reads. The partner's decisions stay their own settings when the platform generalizes them. It is slower than deciding alone. It is why nobody has to ask twice what was agreed.

One thing that did not work. The developer told us the prototype's code could not be reused. I had treated the prototype as the start of the product. I recast it as a contract instead: interfaces, a data contract, written rules and the tokens. Screens now talk only to interfaces, so the source of the data can change without touching them.

Where it stands

This is a work in progress. The platform runs on staging and the first store is in testing, with final checks on database changes assisted by the client partner's IT team and an outside technical consultant. There is no customer result to report yet. What exists today is a working store on a foundation built for more than one business, and a record of every decision that shaped it.