A Shopify rebuild, a live revenue surface, and the safety system that made Codex useful.
A DTC beauty founder came to Superculture needing her Shopify store rebuilt. We used Codex. But the first thing we built wasn't a page. It was a safety system.
That sounds backwards, because the public story of AI is speed: point the model at the thing, describe what you want, watch it go. But a live ecommerce store isn't a sandbox. There's a cart. Checkout. Product data. Admin. Redirects. Discount terms. An email list. Revenue.
The fast way to use AI is also the way you take the store down on a Tuesday afternoon and don't notice until the orders stop.
So we did the slow thing first.
This is the workflow we built: Codex for scoped implementation, GitHub for memory, Google Sheets for human decisions, and a hard line between review-ready and launch-ready. Not "AI redesigned a website." Something more useful: a founder could talk to her store in plain English and get back scoped code, QA notes, documentation, and a clear view of what was safe to ship. She take a screenshot, mark it up, use natural language and have a previewable, staged site in minutes for the price of a $20 a month subscription.
That's the real promise. Not autonomy, but an always on team you can talk to.
The danger zone
Here's the move to avoid: open your live Shopify theme, hand the AI the keys, and ask it to "make updates." It'll do it. That's the problem.
The model has no instinct for which changes are cosmetic and which ones touch the buying flow. It doesn't know that an unpublished theme can still depend on live Admin data. It doesn't care that a beautiful new section is worthless if add-to-cart breaks. AI needs crisp boundaries, and if the boundary only lives in someone's head, it'll eventually get crossed.
So before any design work, we wrote the boundaries down. Actually we had a conversation with Codex and the repo more accurately. Which theme Codex could touch (an unpublished one). Which theme it could never touch (the live one). A flat rule that shopify theme publish was forbidden unless a human explicitly asked. Where the theme code ended and the Shopify Admin began.
We put all of it in a README.md and treated that file as the source of truth. Not a chat message. Not someone's memory. A file the AI re-read at the start of every session. Then we installed the Github CLI, the Codex CLI, the Google Workspace CLI on the founders machine, downloaded the repo, launched the Codex desktop app and walked the founder through speaking to her new dev team.
Start with safety, not design. The first deliverable was risk containment.
Give the AI a memory
The second thing we did was put the theme in GitHub. Not because the store needed enterprise version control, but because a chat thread is a terrible place to keep a project. Close the tab and the context is gone. Codex is much more useful when it can open a repo, read the history, and reconstruct where things stand without anyone re-explaining the whole job.
So every meaningful chunk of work became a commit. Before each chunk: confirm the local branch was clean and synced. After each chunk: report what changed, whether the preview worked, whether a Shopify push happened, whether Admin was touched, and whether the live theme was touched.
The repo became the project's memory. "What changed and why" stopped being something a human had to hold in their head.
The payoff showed up fast. The founder learned to make her own commits. Codex could fetch them, inspect them, review them, and pull them in. We added a START_HERE.md so a fresh session, hers or ours, could walk in cold and not do anything stupid.
That's one of the underrated parts of AI work: the model gets better when the project boundaries, design and goals are clear.
Code lives in GitHub. Decisions live in a spreadsheet.
GitHub is good for code. It's bad for humans who don't read code. The founder is sharp. She's not going to review Liquid templates, and she shouldn't have to.
So the human layer went into a Google Sheet: one master tracker with tabs for status, launch readiness, copy approval, assets and decisions, feedback, and Admin changes. Codex could read and update it. The founder could review and decide inside it without ever opening the repo.
That sheet did something helpful. It made approval a visible state. You could look at one tab and see the difference between "we built this" and "this is cleared to go live." That distinction mattered more than almost anything else in the project.
Review-ready is not launch-ready
This is the line some teams blur, and blurring it is how you ship a broken store.
Review-ready means the preview renders, the structure is there, and a stakeholder can click around and comment. Launch-ready means the Admin templates are assigned, copy and claims are approved, pricing and discount terms are final, redirects are loaded, checkout passes a normal-browser test, and someone with authority has said the word go.
A convincing preview feels like a finished product. It isn't. As of this writing, the rebuild is review-ready, not launch-ready. That isn't a delay. It's a status. The launch blockers live in the tracker where everyone can see them, instead of getting discovered the hard way after publish.
If you take one thing from this, take that distinction. Codex will happily make something that looks done. Knowing it isn't done is your job.
Design is source material, not instructions
When the full design handoff arrived, it came as PNGs and assets. Flat images, not a tidy content spec.
A screenshot doesn't tell Shopify where the content should live. It might carry placeholder copy, borrowed imagery, or a legal claim nobody's cleared. So we didn't ask Codex to copy the mocks. We asked it to translate them: identify the page sections, extract the copy into a doc and mark it placeholder until approved, flag what needed real product data, and propose where native theme settings could do the job versus where custom code was actually needed.
That last call matters. Use custom code for brand expression. Stay conservative around buying behavior. DTC sites live or die on boring things working: add to cart, cart drawer, search, checkout. We built scoped custom sections for the editorial layouts and left the commerce flows on native, battle-tested behavior. A gorgeous section that breaks checkout is an outage with good typography.
Let the feedback be messy
Founders shouldn't have to file perfect tickets. The founder sent screenshots, mockups, rough notes, marked-up images. Good. That's how design feedback actually arrives.
The workflow's job was to absorb that mess and structure it before anyone edited a file: turn the screenshot into copy changes, the rough note into layout tweaks, the marked-up image into asset swaps, Admin decisions, and open questions.
Codex is quite useful as that translation layer, the thing between "I don't love the hero" and a scoped set of changes. The founder stays in the language of taste, priority, and intent. The system turns that into concrete work and reviewable deliverables.
What still needed a human
Codex drafted, built, tested, and documented. It wrote runbooks, caught a console error, fixed a sticky cart, ran interaction QA across the gallery, drawer, and mobile menu. It moved fast and left a paper trail.
But it didn't decide the brand. It didn't approve a claim or a discount term. It didn't decide what was true about the product. It didn't touch the live store, and it never ran publish. Every one of those stayed with humans, on purpose, gated behind the Admin worksheet.
The AI made the path from decision to implementation much shorter. It didn't make the decisions disappear. That's the part the demos skip.
Takeaway
The cost of building software is collapsing. You've heard that. Here's the part that follows: as the cost of making a change approaches zero, the real work moves to making it safely, legibly, and reversibly. In a way it creates more work for the client, but it also gives them more control.
Anyone can point a model at a store now. The skill is the operating system around it: safety rules, version history, human review, and a bright line between review-ready and launch-ready. Wrap Codex in that system, and a founder who doesn't read code can talk to her store like she has a production team standing by.
We didn't build a website with AI. We built a way to change a real business without breaking it. The first thing we shipped was a safety system. Everything useful came after that.
At Superculture, we help founders and teams turn AI from a clever demo into a working operating system: scoped, reviewable, reversible, and safe enough to ship.