There is a point in the process where you will feel like you've hit a wall because built-in triggers feel mid, and you realise that your idea needs a custom component.

That is exactly what happened to me recently while working on the Bòme Wines project.

Usually, accepting that you need to build a custom component is where designers close the tab and cry. I decided to just... not do that. Instead, I found my workaround in Claude.

In this piece, I'll show you how to brief an AI well enough to build what you actually envisioned.

No-code has a ceiling and you will find it

I don't know React. Honestly, I don't see myself learning React. But I also wasn't going to water down the vision because Framer ran out of options.

It wasn't a total shot in the dark, either. I already knew how to get usable logic out of Claude, so I decided to see if it could handle an entire custom build.

Even though I have zero developer knowledge, I managed to build a fully functional shop with very specific requirements by treating Claude as my technical co-founder.

Framer's built-in toolkit is genuinely good. Until what you need and what it offers are no longer the same thing.

The shop component for Bòme had requirements that no drag-and-drop solution was going to handle.

That just meant getting into the code, whether I wanted to or not.

So the question stopped being "how do I avoid code" and became "how do I get the code I need without writing it myself."

Treating Claude like a technical Co-founder

I managed to build a fully functional shop with very specific requirements by treating Claude as my technical co-founder. Make no mistake. 

You can’t approach this assuming there is a magic formula or a magic prompt.

During the process there were moments where I’d literally end up asking Claude, "What is actually wrong with you?" and feeding the error logs back until he got his life together.

One of the things I wish I knew earlier was you need to put an extra effort to win an argument with the LLM.

So if you are working in a similar Framer environment here is how you actually “cook”.

Provide visual evidence when something breaks

Include a screenshot alongside 'it doesn't work' — visual context immediately surfaces the real issue and eliminates guesswork.

Specify exact values, not descriptions

Use precise measurements and color codes rather than approximations — '1px border #D7D2CA' gets it right the first time, 'make it thinner and grayish' does not.

Write conditions in plain if/then language

"Describe access logic as a human rule — 'if signed in as Krug Member, allow navigation; otherwise open the modal' — it maps directly to code with no translation needed.

Bundle all constraints into a single prompt

Combine related requirements into one message — breakpoint, card count, and screen size together — rather than adding them one by one across multiple rounds.

The Brief is the build

Your ability to describe an interaction precisely is now the most valuable technical skill you can add to your designer skillset.

Since I didn’t want any half-finished output I gave Claude design details about the Bome project, from the brand identity and specific user flow to the technical constraints of Framer.

In this process you have to be able to explain the logic to Claude in plain English, otherwise you’ll never get the React code back.

Pro tip: Don’t take "no" for an answer. If the code fails or the preview crashes, it’s just a draft. You have to keep pushing and iterating until the vision finally comes to life.

Every time the code didn't work or the Framer canvas glitched, I was back in the conversation with Claude, feeding error logs, explaining what I was seeing, pushing until the logic clicked.

The psychological experience of debugging code you cannot read is its own thing. You're working on trust and pattern recognition rather than comprehension.

The biggest shift is realizing that 'it almost works' still means it's broken.

You have to stop trying to play developer and just tell Claude exactly what's glitching on the screen.

What the shop required and how it got built

As a wine brand with a minimalist luxury aesthetic The Bòme webshop had requirements that ruled out off-the-shelf solutions: a specific purchase flow, and precise interaction states.

That is why beyond the shop itself, I went into architect mode to build out the rest of the Bòme ecosystem.

I created my own social media plugin for the Journal timeline because I wasn’t about to let a clunky, basic third-party embed ruin the minimalist luxury aesthetic.

To sum it up, we needed Instagram posts and blog posts mixed in one feed, sorted by date.

Framer has no built-in way to do this, so we built a Code Override that fetches posts from a Cloudflare Worker, merges them with CMS items, sorts by date, and injects matching HTML cards — all filtered by hashtag so the client controls what appears on the site directly from Instagram.

After that, I developed custom audio components to add a layer of sensory depth you just can’t find in a template. Basically, it’s a custom player that ties background music to specific sections of the page, automatically starting and stopping as you scroll.

Conclusion

The secret to the entire process is giving Claude as much context as you can provide along with the functional constraints until he understood the vision instead of just spitting out generic snippets.

This project is proof that the gatekeeping of "technical" web design is over. When you have the taste and a clear vision, the code becomes an implementation detail rather than a barrier.

By combining a high-end design eye with aggressive, iterative prompting, I shipped a custom-coded site that looks like it had a full engineering team behind it.

Ultimately, Bòme is the result of refusing to let the limitations of "no-code" define what I could create.