How I work
Depending on where the project starts, my workflow can shift. Sometimes a designer hands me a finished Figma and my job is to turn it into a system a content team can run. Sometimes nothing exists, and I'm the designer, the engineer, and the product owner all at once. Different starting points, same destination: something built with intention that other people can actually use and maintain.
From Figma to field architecture
My agency methodology, refined over 8+ years of headless WordPress builds for luxury hospitality and real estate brands.
Review the design with the designer
To kick off a new build, I chat with the designer to align on styles, interaction expectations, and questions that the design hasn't annotated.
Annotate sections into components
I map each section across each artboard to a named component, defining its ACF fields in FigJam. The judgment call here decides whether the CMS will be pleasant or painful: which sections are truly the same component wearing different content, and which only look similar.
Classify by build cost
Each component gets a classification, low cost (1 to 2 hrs) or high cost (4 to 8 hrs), so the agency can see where the budget lives and make scope tradeoffs before the build starts.
Draw the component tree
Page to flexible component to sub-component, for every page. When this is done, the whole build is visible on one board: what exists, what repeats, what it costs, and what fields power it.
Generate the schemas with Claude
I screenshot each annotated component to Claude, workshop the name, specify the fields, and have it generate the ACF JSON and matching GraphQL schema. Pre-2026, this was the most tedious, error-prone part of the build, but now it ships without missed edge cases.
Build, decide, and fill out content
Once I set up the WordPress and connect it to Next.js, I set the variables, mixins, and folder structure to stay organized and consistent. I build out one component at a time, followed by animations and mobile. Then content: I implement every non-templated page personally, and enter one complete example per templated post type for the content team to duplicate.
The system isn't done when it renders. It's done when someone who isn't me can run it. After sign-off, I test accessibility, add cookie consent, marketing scripts, and any CRM integrations for launch.
Thinking in Figma, building with Claude
My own products start from a blank page, and AI has genuinely changed how I work through them.
Plan with Claude Code
I explain the problem, craft the idea, and set the outcome. Sometimes that's a massive concept that needs breaking into an MVP. Sometimes it's one component, and I want different ways to think about how it could work. Claude drafts, and I review.
Figma becomes my notebook
I used to keep an actual notebook on my desk for scribbling ideas. That's what Figma begins as today: a scratchpad, a place to think. I doodle shapes and paste inspiration. I get a general sense of how I want something to work and gather my thoughts for Claude.
Manage the codebase
On Ant Farm, I caught a component rendering differently in two places, which meant the code had drifted past my comprehension. I stopped and restructured folders and files until the project was something I could follow again, and something another engineer could walk into and understand.
I'm currently in a debate with an engineer friend who's certain this won't matter. He believes that if outcomes are correct, human-readable code becomes irrelevant. I think it's a healthy conversation to have, but for now, I build codebases I can still read, because I'm the one who has to stand behind them.
Design gets the Kelly 1-2 punch
Claude's initial design is often a good start, but I'm not interested in good. I want unique and personal. To account for this, I screenshot what it built, go back to Figma, and design the actual system: intentional typefaces, headings that match, meaningful colors, real polish. Then I write a good share of the styling myself, not because I have to, but because I love it, and "organic code" is how I keep growing as an engineer. But after building this portfolio, I'm 50-50 on this because...
This site is the case study
The site you're reading was designed by me and built by Claude Code, a headless WordPress and Next.js build that was nearly complete in 3 days. It worked because I had a solid plan of action, had a repo that it could refer to about my preference in organized systems, and had a plethora of story behind my life for the content.
Ideation with my new teammate
Since the stakes were low but expectations high for my portfolio, I wanted to give Claude a chance to test all of my reflections from the sites that I have built earlier this year. It knows my life story and has helped me solve problems both life- and work-related, so gathering most of my history was easy.
Once paired with screenshots of a couple of bare-bones case studies I wrote a while back, I was able to prep all five case studies with detail and map those to components.
Write the spec, not just the vibe
Once we knew the content, we could create build sheets that map every page's copy to components and fields. A schema manifest becomes the single source of truth: Claude proposes field names, I approve them, and nothing enters a query or the ACF JSON without passing through me.
Designing the components and defining the visuals
My portfolio has always been one of my favorite sites to build. It's a little way to show my personality digitally and push my creative boundaries. Once I knew the set of components and copy, I went to Figma to begin shaping the homepage including new fonts, colors, and my funky sidebar. I could now point Claude to these artboards, and shockingly enough - the homepage came out incredibly well! The first QA only had 12 inconsistencies. The case study template on the other hand... not so much.
Cleaning up the chaos
Since I'm the queen of styling, I can tell pretty quickly why some styling doesn't match the design. Gotta love order of operations when it comes to grids, am I right?
I make QA lists of each detail that needs some love as well as ensure only variables and mixins are being used. I catch Claude occasionally trying to add inline styles or remaking a component that's a bit off and set new rules immediately.
Build query-first, in parallel
Once I have all components designed, Claude writes each GraphQL fragment and ACF JSON before building the component, so I can enter content in WordPress while the component is still being built, and then sync fields when it's ready for review. Animation waits for my per-component briefs. Nothing continues until I say when.
Verify the foundation, then trust the spec
After pointing Claude at Ascaya's conventions for folders, variables, and mixins, and once the foundation matched how I build, review became spot-checks. It also gives me the opportunity to test design ideas quickly and live.
Claude has surpassed my skill in developing, which is both sad and exciting: sad because I love building, and exciting because now I can build even more creative ideas.
I'm sad that AI is surpassing me,but excited I can build my dreams
Why
Claude is the bigger teamthat I've never had
My career has mostly been a 1-person show. No senior engineer at the next desk, no design crit on Thursdays, no code review culture to absorb by osmosis. What I love about working with AI is honest and a little unglamorous: I'm never smart enough yet. There's always another best practice I would have learned on a larger team, and now I have somewhere to learn it.
But the judgment stays mine. The content models, the component boundaries, the design decisions, the taste. That's the part that doesn't delegate. AI eliminates the distance between deciding and shipping. Deciding and creating is still my job, and I love it.