Build It for One.
Sell It to Many.

It started the way every good product starts: with someone being sick of something. Gianna was on a beach in Mexico, doing what marketers do – opening one tool after another, copying numbers into a spreadsheet so she could finally see where the leads were coming from.

Her first attempt was not to build anything. She had a Claude subscription and the browser extension, so she did the obvious thing: one tab with the spreadsheet, one tab with the marketing tool, and a prompt asking the model to move the numbers from one to the other.

It didn't work. She spent hours hunting for the right prompt and gave up.

That failure is the interesting part. For most people it's the end of the story – proof that the tool isn't there yet, or that they're not the right person to be trying. For Gianna it was the moment the problem got promoted: if nothing out there does this, I'll make the thing that does.

I put it to her that this reaction is rare, because I watch the other reaction constantly:

Her answer went further than mine did.

Read that last sentence again. The blocker she names isn't ability and it isn't the tooling. It's not knowing that you're allowed.

The gap between the people who now sell software and the people who don't is mostly a gap in who waited for permission.

Ask Gianna what you should prompt and you get a small, useful correction. She doesn't think of it as prompting at all.

That reframe does a lot of quiet work. "Prompt engineering" sounds like a discipline you have to go and acquire. Briefing is something a freelance marketer has done a thousand times – to a designer, a copywriter, a media buyer. It's a skill she already had, pointed at a new colleague.

And a colleague is exactly how she describes it – which is also where the second unlock lives. Claude looked at what she was building and told her to connect GitHub.

No embarrassment, no detour into a beginner's course. She asked, looked it up, and kept going – then did the same for the backend, for hosting, for deployment. All the boring infrastructure nobody warns a marketer about, learned one question at a time, in the middle of doing the work.

I learned maybe eighty percent of what I know from YouTube, and YouTube has been free and infinite for two decades. Most people still didn't use it. What's changed is that we now have a teacher who is not just infinite but patient– one that doesn't mind being asked what the hell GitHub is, for the fourth time, at eleven at night.

If you want the same first step with a bit more scaffolding under it, the Codex starts exactly here – with turning your own problem into a brief and then getting the boring setup out of the way.

This is the question that stops people, and it deserves a straight answer instead of a motivational one. Gianna is honest that she often doesn't follow what the machine just did – she states the problem, she sees the outcome, and the middle goes past too fast to hold onto.

I don't think that's a defect. I think it's a choice everyone makes, whether or not they notice making it. There are places I stopped caring entirely: I have Claude build meeting slides in HTML, and I could not tell you a single thing about the markup underneath. It looks right, it says the right things, it helps people follow me. Fine.

And then there's the place I started caring a lot more – the same place Gianna came to our meetup to learn about.

Which is not an argument for relaxing. It's an argument against the idea that there's a credential that makes this safe. There isn't. There are tools that scan your work, and there's the slightly sketchy move of asking the same model that built the thing to review its own work – better than nothing, and not the same as somebody independent looking.

So how deep do you go? My honest answer is that the depth is bottomless, and pretending otherwise is what makes people freeze.

Natural language alone is probably too shallow if you intend to earn money with the result. One level deeper – enough to picture the architecture, where the data sits, who can reach it – is usually enough to hold your ground.

Then the rule is simple: broad strokes first, then obsess about the one thing you're actually building.Payment integrations, for example. That is not a joke. When you get to that point, have the long, boring, five-minute monologue conversations with Claude until you genuinely understand what is happening to other people's money.

Gianna, looking back, would add a little foundation to the front of it:

Note where she puts it, though. Not as a prerequisite. As a thing that would have made the doing smoother. Nobody learns the whole map before they leave the harbour.

Here is the move worth copying, and it is much smaller than "founded a startup."

Gianna had one client with the same problem she had. She didn't write a business plan or validate a market. She pitched him a favour with a number attached: what if I build you a dashboard – start with this many hours, just so you can see it?

He said: yeah, just go ahead.

What she built first was not clever. It was a set of tabs. Contacts, active, inactive, timeframe, tags, lists – the numbers he actually looked at, in the order he looked at them. The whole value proposition was fewer clicks.

Anyone who has gone looking for a number inside DigiStore knows the feeling she's designing against. Sometimes you can't find it at all and you end up messaging customer support to ask what you sold.

Then she added the part that made it more than a nicer view. She connected Claude to the data and taught it to read the funnel the way she reads a funnel – what comes to mind when she looks at those numbers, which drop is the one that matters.

His reaction, in full: this is cool – I haven't really seen anything like this.

And yes, a perfectly configured HubSpot gets close to this. But nobody has a perfectly configured HubSpot, and getting one costs a fortune in time and money. She built the version that fit one real person's actual week. That's a much lower bar than "better than the market leader," and it's the only bar that mattered.

Build for one identified human being. It removes every excuse about market size, positioning and competition in one move.

A favour becomes a product at an identifiable moment, and it isn't when you decide it should. It's when somebody who owes you nothing looks at the thing.

I know that moment from the other side. I spent January to March 2025 screaming at my machine until my first SaaS product existed – a ChatGPT-style tool where you could pick your model and store your business context. I solved my own problem, someone paid for it on Stripe, and something shifted permanently: the thing I used to sell by the hour, I could now sell as a product.

But going from one user to many is where the work stops being the work you expected. It is not the code.

Connecting her own client's accounts was easy. Getting permission from Google and LinkedIn so that anyonecould connect theirs is a different job entirely – pages of documentation, proving the access is read-only, proving you're not quietly assembling a competitor out of their data.

Six weeks of paperwork and a screen recording for a reviewer, to read a number a customer already owns. Nobody puts that in the founder story, and it is the single most useful thing in this episode for anyone about to make the same jump. The moment other people's data enters your product, you inherit a bureaucracy – and a whole class of problems around who can see what.

What she's solving for them, by the way, is the hardest problem marketers have. Spend five hundred euros on Meta for a webinar: how many of those clicks registered, showed up, and bought – and did you make more than five hundred back? Meta's numbers disagree with Google Analytics, the organic traffic sits in Search Console, and nothing reconciles. We call it the attribution problem. If it were easy, every marketer would be rich.

On pricing, she's doing the thing more founders should admit to doing – changing her mind in public:

That is a marketer's instinct applied to her own company, and it only works because she can now build both landing pages herself in an afternoon. No developer queue, no half day lost in a WordPress plugin directory. Testing is only cheap when shipping is cheap.

And when I asked what she'd do differently, she didn't say anything about the technology:

Build it for one. Then show it to the next twenty before you build anything else.

There's a pattern I keep noticing, and Gianna is the clearest example of it I've had on the show.

A marketer who has spent real money on ads and watched real funnels leak wants something a developer would never think to build. Gianna's next step for Hebelytics isn't a better chart – it's an AI that stops saying "this ad isn't working" and starts saying which partisn't working. The text or the colours. Why "make five thousand in two weeks" outperforms "make money." Then a concrete plan, and a test to prove it.

Only somebody in the marketing weeds, spending their own money, gets to that level of specificity. It doesn't come from studying software.

And it doesn't stop at the product. Once building is cheap, it leaks into everything:

Why a pop-up builder? Because every pop-up tool she'd used broke at some screen size, and paying a subscription for something that doesn't fit your page is annoying. So she replaced the subscription.

I do the same thing in a less defensible direction. I'm forty-four and still make time to play games, so I built myself a little system that interviews me about how I'm playing, pulls my data from Steam and Nintendo, and tells me which game I should be playing right now. Completely unproductive. Genuinely fun to build.

Gianna's equivalent, thought up live on the recording: she's still fitting out the bus, she has every measurement, so – a tool that tells her exactly how much wood of what kind to buy for each section. Nobody will ever pay for that. It doesn't matter.

Keep a list of these. Look at it every quarter or so. The ones that are still nagging you months later are the ones to build.

I closed by asking what she'd say to the marketer who is still doing it all by hand and is fairly sure that building software is for other people.

Her whole route, compressed: get properly annoyed by something you do every week. Brief it like you'd brief a freelancer. Ask the embarrassing questions out loud and keep moving. Build it for one person you can name. Then show it to a third person and watch their face.

Everything after that – the pricing, the paperwork, the six weeks waiting on Google – is just the ordinary work of having a product. It is not the hard part, and it is definitely not the part that stops people.

The hard part was believing she was allowed to start.

Gianna is speaking at Vibe Coding Cologne on 2 September – a live demo of the thing, not slides about it. She came to the last one as an attendee. Come to this one and see how short that distance actually is.