How I used codex to rebuild my publishing website

I recently had the urge to revive my publishing business, and as I got clearer on the new business model I felt it was time to rebuild my website. My website was built on Shopify as D2C distribution of books is a core part of the proposition. Previously, I would select a theme on Shopify and try to make it fit my desired look and feel without every quite hitting the spot. With this new iteration of the website I didn’t want to settle for good enough. I wanted the site to be an absolute representation of the new direction we are going in. My company, Wordjar, began as a publishing brand. But the ambition has now expanded, and I was no longer interested in just publishing books, I wanted to build an ecosystem for authors. One that helps them publish, market, distribute, manage rights, and think about their stories as assets that can travel across formats. This new platform needed to reflect that shift.

It also needed to feel premium. Wordjar was repositioning as a luxury brand - editorial, minimal, cinematic, and carefully made. I wasn’t interested in one of the generic startup sites that you see when people build with Lovable, and I didn’t want to start with a traditional agency workflow.

I wanted to test myself, to see if I could use OpenAI Codex as both a thinking and production partner. What followed was surprisingly practical end-to-end workflow - from brand strategy, to system design, to page builds, to Shopify templates, to a fully packaged theme.

The most important part of this process happened outside of Codex, before any code was written. Instead of jumping into Codex and asking it to start building pages, I started by building a context file. I approached this in a similar way to how I would work with my engineering team. I wouldn’t sit next to them and say “build me a home page that looks like this” and then “change the font here, make it look more like this website.” I would always start with sharing context within a clearly structured document. This could be a PRD or a framing doc. The same rule applies here. The file I created defined:

In effect, I created a structured “mental model” of the business and handed that to Codex.

On top of this context I built a prompt pack, breaking the work into stages:

The combination of these two things was the unlock. Without the context, it would have been easy for the output to drift into generic AI-generated design. With it, Codex had a clear point of view to execute against. It knew it was building something closer to a premium publishing house and storytelling studio than a SaaS product. The prompt pack gave it some structure and guardrails to execute against. This shift changed the quality of the work entirely.

Now that we had the context, it was time to get into the fun part. Rather than thinking about building for Shopify first, we started with a static version of the site. This gave us the space to focus on the structure, hierarchy, pacing, copy, visual rhythm, and overall feel.

The context file was our shared source of truth and helped to drive the collaboration. We worked through building each of the pages, from the home page right the way through to the contact page, following the pre-defined structure. Because all of the initial prompts were included in the context.md file, it allowed the interaction to be a lot more natural. Starting with the homepage we worked through the build of all pages as simple HTML pages initially to get to a place where we had a shared understanding of what the site needed to communicate and how it should feel. Codex built, then asked me to review. The feedback loop was immediate and allowed for rapid iteration towards what we wanted the site to be.

Once this static version felt right, the next step was to translate this into something usable inside Shopify. This is the point the work became more architectural. This required not just recreating the pages, it was about design a system that was compatible with the Shopify universe and was in effect a theme. This meant that we needed:

One of my key success metrics for this was to not have to depend on Codex for content updates after the build, similar to how I wouldn’t want to involve my engineering team for the same task. For the homepage in particular, this meant exposing far more flexibility that the static version had. This required giving me access to:

This surfaced an important distinction. A beautiful component is not the same as a usable component. If you want a site that can evolve, you have to design for the editor experience - not just the initial build.

Moving from our unconstrained build in our static version to the Shopify ready theme is where we started to experience some speed bumps. Every platform has its own opinions about how things should work and Shopify is no different. What looks straightforward in a static prototype quickly becomes more nuanced when you try to turn it into a flexible, production-ready theme that works properly inside Shopify’s architecture. Shopify introduces it’s own sets of rules and quirks which I didn’t anticipate ahead of time. Some of these frictions were structural, for example:

Other constraints were more granular. Shopify’s schema system, which powers the theme editor, has strict validation rules that only really reveal themselves during implementation

Small details suddenly mattered:

These are the kinds of issues that don’t appear in a Figma file, but start to emerge when a design becomes an integrated system. One of the more interesting lessons was realising how different “designing a page” is from “designing a reusable editing experience”. A static layout is relatively simple. A reusable Shopify section is effectively a configurable product.

I wasn’t just deciding what the section looks like today, but also had to think about what future flexibility should exist, what content editors should be allowed to change, how much design freedom is too much, and where consistency matters more than flexibility. This introduces a very different type of systems thinking. For example, exposing typography controls sounds simple at first , but once you start implementing them you quickly enter a rabbit hole of further questions like “Should editors control container widths?” , “How many layout variants are actually useful before the interface becomes noisy?” , “How do you preserve brand consistency while still allowing flexibility?”

The challenge stops being purely technical and becomes architectural. This is where Codex really shined. It moved from being less of a generator towards being more of a true collaborator. It helped to debug errors, adapt implementations, explaining the platform constraints I was experiencing, iterating quickly without breaking the flow. Working through these issues with Codex made it feel like “I used AI to build my site” to more like “I had a technical partner helping me work through a complex build” as we were working through issues in real time, without losing momentum.

My initial assumption was that I would layer this work into an existing theme. But as the system became more coherent, it made sense to package it as its own theme to remove constraints of existing themes. An example of one of these constraints is the fact the current theme I was using wouldn’t allow me to make my new home page the default landing page for the website. Other benefits of packaging this as a standalone theme is that it allowed me to:

The final output included its own theme layout, shared assets. header and footer, default templates, bespoke Wordjar-specific sections, page and collection templates , and a deployable theme package.

Reflecting on this experience, there were a few key things that made the difference.

1. Context engineering

The quality of the output was directly tied to the quality of the input. Writing a proper context file and prompt pack was the highest leverage activity.

2. Separation of stages

Each phase had a clear purpose:

3. Iteration over one-shot generation

The result didn’t come from a single prompt. It came from many small refinements.

4. Treating Codex as a collaborator

This is a culmination of the first three points. Ultimately, treating Codex the same way you would treat your tech lead is the way to get the most value out of it. Not just for code, but for structure, language, systems thinking, debugging and decision support.

Next time around I would bring more of the production thinking into the project earlier. The first version worked because the workflow moved quickly: define the brand, build the static site, convert it into Shopify, then debug the constraints. But looking back, some of the later complexity could have been reduced by making a few architectural decisions upfront and adding these to my context file. The best example of this is the content model. For a publishing business, the site is not just a set of pages, it is a system of connected objects; books, authors, collections, rights, submissions etc. Each of these objects has its own fields, relationship and future workflows. For example a book isn’t just a static product card, it also has

If the model isn’t clear early, the build can become too page-led. The site may look right visually, but what lays underneath can be harder to scale.

Secondly, I would decide much earlier which components need to be flexible in the Shopify editor, and which should remain fixed. The reality is, not every section needs endless controls. In fact, too much flexibility can make a premium site worse. If every font size, margin, layout and colour can be changed, the brand system becomes fragile.

Next time, I would classify sections more intentionally. For example:

That would make the Shopify editor cleaner and reduce unnecessary complexity.

Finally, I would think more deeply about data structures for the areas that could scale:

Books may need richer product metadata. Rights may need a clearer way to represent what formats are available or already licensed. Submissions may need a proper workflow for reviewing authors, categorising manuscripts, and managing follow-up. That is where the website stops being just a brand presence and starts becoming part of the business infrastructure.

So next time, I would still use Codex to move quickly, but I would give it a more detailed operating model earlier.

Not just:

“Build me the site.”

But:

“Here is the business system this site needs to become.”

What this process showed me is that tools like OpenAI Codex are most powerful when the work spans multiple domains. Being able to use it as a ‘build partner’ operating across strategy, language, designs, systems and implementation is where it truly shines.

In that kind of workflow, they compress the distance between idea and execution. They don’t replace judgment. If anything, they make it more important. I still had to define the direction, shape the brand, and decide what felt right. But the path from thought to working product became dramatically shorter. For a project like this, that was the real value.