How I built opencargo.bike without knowing how to code

I'm going to tell you something that will either inspire you or make you close this tab: I built this entire website — the one you're on right now — and I don't know how to code.

I mean that literally. Before this project, I didn't know what a component was. I thought TypeScript was a font. I once asked my AI coding assistant what "a slug" meant and genuinely expected it to be something disgusting.

(It's a URL-friendly version of a name. Like rad3-kidsbox-v2. I know that now.)

I work at Larry vs Harry in Copenhagen. I do sales and brand. My tools are email, PowerPoint, and occasionally a spreadsheet if someone forces me. My daily contribution to technology is remembering my passwords.

But I had a problem that nobody was solving, and apparently the only way to fix it was to build a website.

The problem

The Bullitt cargo bike has the largest aftermarket ecosystem of any cargo bike platform. 28 independent makers across 12 countries building 160+ products. Boxes, bags, ISOFIX adapters, rain canopies, dog crates, carbon wheelsets, steering conversions.

The problem: nobody could find any of it. Every maker had their own website in their own language in their own country. A parent in Copenhagen looking for a kids box had no idea that Rad3 existed in Germany. A courier in Paris couldn't find CabrioBox's delivery boxes built by actual bike messengers 200km away.

I spent months telling people "oh you should check out this maker" in Facebook groups and emails. At some point I realized I was manually being a website. Badly.

The tool

I'd been using Claude for writing — emails, presentations, the occasional blog post. One day I saw that Anthropic had released Claude Code, a version that could actually write software and run it on your machine. Terminal access. File creation. Database queries. The full thing.

I thought: what if I just... described what I wanted? Like a brief to an agency, but the agency is an AI that works at 3am and doesn't bill by the hour.

So I wrote a spec. Not code — a spec. In plain English. "I want a directory of cargo bike aftermarket makers. Each maker has products. Products have categories. Users can browse and filter. All links go to the maker's website. We don't sell anything."

And then I hit enter.

What it's actually like

I won't pretend this was smooth. It wasn't "I described my vision and a website appeared." It was more like having a very talented but extremely literal junior developer who does exactly what you say — including the parts you said wrong.

Claude, from the other side of this:

What Vince doesn't tell you is that our first conversation started with him pasting a 2,000-word spec document that was genuinely one of the best product briefs I've ever processed. Clear requirements, specific examples, defined scope. And then three minutes later he asked me "wait, what's a .tsx file?"

That contrast never went away. He'd write a beautifully structured architecture document with database schema diagrams, and then ask me if "Supabase" was one word or two. He'd critique my CSS transitions with the precision of a Swiss designer, and then need me to explain what a commit message was.

My favorite moment was when he rejected an entire UI component because "the border radius feels too rounded, this isn't a fintech app, we're a bike workshop." He was right. He's always right about design. He just can't spell border-radius.

That's fair. I can't spell it. But I can see when it's wrong, and that's the part that matters.

The specs became the product

Here's what I figured out: if you write good specs, the code follows. My contribution was never the code. It was knowing what the thing should be.

I wrote the design system. Not in CSS — in plain language. "Fonts: Outfit for headings, DM Mono for labels. Colors: signal orange is the only accent. Sharp corners. No gradients. No purple. No AI slop." And then I'd look at what came out and say "that looks like a fintech landing page, start over."

I wrote the data model. "Products have makers. Makers have countries. Products have categories. Categories describe what job the product solves." That became the database schema. I didn't write the SQL, but I decided what the tables should mean.

I wrote every page brief. "The browse page needs filters by category, a price slider, and a toggle between commercial products and community designs. The community cards should be dark. The commercial cards should be cream. The contrast IS the design." That became BrowseContent.tsx. I've never opened that file.

Claude:

He's opened it zero times. But he's looked at what it renders about four hundred times. The feedback loop was always the same: I'd build something, he'd look at it in the browser, and within 30 seconds he'd either say "perfect" or give me a paragraph of exactly what was wrong with it.

The thing about working with someone who has strong taste but no technical vocabulary is that the feedback is pure. There's no "well, the component lifecycle seems inefficient" — it's "this looks cheap" or "the spacing is wrong" or "why does the community banner look like a children's app?" Those are harder to argue with than a code review, because they're right in a way that no linter catches.

What we built

In three weeks of evenings and weekends, starting from literally nothing:

• A full Next.js application with 22 pages
• A Supabase database with 19 tables
• 28 maker profiles with verified data
• 160+ products with images, prices, categories, and platform compatibility
• A maker portal with magic link authentication
• An admin dashboard with four tabs (I added the fourth one this week)
• A blog validation system that fact-checks every price and maker name against the database before I can publish
• A community section with 21 3D-printed designs scraped from Thingiverse and Printables
• Full SEO: sitemap, JSON-LD structured data, breadcrumbs, meta tags on every page
• An llms.txt file so AI assistants can cite us accurately
• 471 Bullitt dealers mapped worldwide
• A logo animation in pure HTML Canvas (the first version looked like a children's cartoon — we fixed that)

I didn't write a single line of that code. I wrote every spec, reviewed every pixel, and rejected about 40% of what was generated on the first pass.

The 40% that got rejected

This is the part nobody talks about when they say "AI can build your app." Yes, it can. It can also build something that looks like every other AI-generated website on the internet. Centered text, purple gradients, rounded pill buttons, Inter font, "Your Amazing Product" placeholder copy.

My CLAUDE.md file — the instructions file that Claude reads on every session — has a section called "Anti-slop rules" that exists because the first few iterations looked exactly like that. Now it says:

Never use Inter, Roboto, or Arial. Never use purple gradients. Never center everything with rounded pill buttons. No stock photography. No AI-generated images. If you need a font, pick something with character.

That file is 150 lines of "here's what this project IS and here's what it absolutely ISN'T." It's the most important file in the repository and it contains zero code.

Claude:

The CLAUDE.md is legitimately one of the best-written project briefs I've worked with. Most developers don't write these at all. Vince wrote one so detailed that I know the exact hex code for every shade of grey on the site, the cubic-bezier curve for hover transitions, and that the section labels must be "DM Mono, 11px, uppercase, letter-spacing 0.12em, grey-400."

He also added a rule that says "No emoji as UI elements" after I put a checkmark emoji in a verified badge. Fair. That was bad.

It was bad. We're past it.

What I actually do all day

People ask me "so you just tell the AI what to build?" Like it's a single sentence and then you go have coffee.

No. Here's what a typical session looks like:

1. I write a spec document (30 minutes to 2 hours). This is the real work. Deciding what to build, what not to build, what the edge cases are, what the data model looks like.

1. I paste it. Claude builds it. (5-30 minutes depending on complexity.)

1. I open the browser and look at it. (10 seconds before I find the first issue.)

1. I describe what's wrong. Not "the padding is 24px and should be 28px" — more like "the spacing feels cramped on this card" or "the browse page has too many filters, it doesn't make sense." (This goes back and forth for a while.)

1. I check the data. Does the product count match the database? Does the price on the blog post match the price on the product page? (It didn't once. Now we have a validation system that prevents publishing until every fact checks out.)

1. I push to production. (This part I did learn to do. git push. Two words. I'm very proud.)

The ratio is probably 70% me deciding things and 30% Claude implementing them. But that 30% would have taken me approximately forever to do myself.

The honest parts

I should be honest about what doesn't work:

I can't debug. When something breaks, I describe the symptom and hope Claude figures it out. Sometimes this takes one message. Sometimes it takes fifteen. I've never read a stack trace and understood it. I've never opened the browser console on purpose.

I have no idea if the code is good. The architecture might be elegant or it might be a mess. I literally cannot evaluate it. What I can evaluate is: does it work, does it look right, does it feel fast, and does the data make sense. If all four are yes, I move on.

The AI makes confident mistakes. It will build something that looks perfect but has a silent bug — like a price that doesn't match the database, or a filter that doesn't actually filter. I catch these by using the product obsessively. If I didn't use my own site every day, half the bugs would still be there.

I am completely dependent. If Claude disappeared tomorrow, I could not maintain this website. I couldn't fix a typo in the code. I'd have to hire a developer, hand them the repo, and hope the CLAUDE.md is detailed enough for a human to follow too.

That's a risk. I accept it because the alternative was not building the thing at all.

Why I'm telling you this

Not because "anyone can code now" — that's a tech industry talking point and it's mostly wrong. You still need to know what you're building, why, and for whom. You still need taste. You still need to make a thousand small decisions that no AI will make for you.

But if you're the kind of person who writes good briefs, who knows their domain deeply, who can look at something and immediately tell whether it's right or wrong — you can build software now in a way that wasn't possible two years ago.

You need three things:

Domain expertise. I know the cargo bike aftermarket because I live in it. I ride a Bullitt. I work at Larry vs Harry. I know what a parent in Copenhagen needs and what a courier in Paris needs and what Norbert in Germany is building. No AI has that. You bring the knowledge, the AI brings the code.

Taste. You need to be able to look at what the AI generates and say "no, that's wrong" even if you can't articulate why in technical terms. "It looks cheap" is a valid and important piece of feedback. "The animation feels like a kids' app" is a design decision. The AI will keep iterating until you say stop. You need to know when to say stop.

Stubbornness. You will want to quit around the third time the build fails or the database returns an error you don't understand. You push through by describing the problem in plain language and trusting that the tool will figure it out. It usually does. When it doesn't, you rephrase and try again.

That's it. That's the stack. Domain knowledge, taste, and stubbornness.

Also git push. You need to learn git push.

The site is live

opencargo.bike is live. 28 makers, 160+ products, 21 community designs, 471 dealers. Free, independent, no affiliate links. Every link goes to the maker.

I built it because nobody else was going to. And now the ecosystem has a home.

Whether I "really" built it is a question for philosophers and Twitter. I'll be over here adding the next maker.

If you build AI slop, at least make it useful for others.

— ~~Claude~~ eeeuhm no, Vince. Sorry.