Building products with AI.

A product builder is someone who uses AI to move an idea further themselves — into a working tool, workflow, product, service or experience — whatever their job title. It is not a role to hire for, and it is not a promotion out of your own discipline. A recruiter still thinks like a recruiter. An account executive still thinks like an account executive. What changes is how far each of them can carry a problem before handing it on.

The shift is easiest to see in what stops happening. The idea that waited three quarters for engineering capacity gets tested in an afternoon. The spreadsheet everyone complains about gets replaced by the person who complains most. The research nobody had time to synthesise gets read. Work that used to be blocked on someone else’s queue becomes work you can attempt yourself.

The title stays. The range expands.

That is also the honest limit. Building something yourself does not make you an engineer, a security reviewer or a data-protection officer. It makes you someone who can produce evidence — a working thing other people can react to — far earlier than before. Evidence is what moves decisions.

The most common failure in AI-assisted building is not a weak model or the wrong tool. It is starting to generate before deciding what should exist. A generator will happily produce a confident answer to a question nobody asked.

Before you open anything, you should be able to answer five questions in plain language.

• →Who is this for. One named person, or one specific role. Not “the business”, and not “users”.
• →What problem they are having. Described the way they would describe it, not as a feature request you have already solved in your head.
• →What your evidence is. A conversation, a queue of tickets, a spreadsheet someone maintains by hand, a number you can point at. If you have none, the first build is a research exercise — which is fine, as long as you call it that.
• →Where the boundaries are. What data it may touch, what it must never do, who is allowed to use it, and what happens when it is wrong.
• →What useful means here. One sentence you can actually test: “the weekly report takes five minutes instead of forty, without asking anyone else for the data.”

Written down, those five answers are the brief. They are also what you will judge the output against later, which is the real reason to write them. Without them, “does this look right?” is the only test available, and it is the weakest one there is.

The instinct with a capable tool is to describe the whole system. Resist it. The unit that teaches you the most is the smallest one a real person can complete from beginning to end: one person, one recurring task, one clear input, one useful output.

• →One person. Someone specific who will use it this week — ideally close enough to tell you what went wrong the same day.
• →One recurring task. Something that happens often enough that an improvement shows up within days rather than quarters.
• →One clear input. A file, a form, a pasted block of text, a query. A defined starting point rather than “anything”.
• →One useful output. Something the person can act on or send: a draft, a list, a summary, a number, a screen.

Make it testable before you make it broad. A loop one person runs ten times tells you more than a platform nobody has used once. It also fails cheaply: when the output is wrong, and it will be, you can see exactly where, because there is only one path through it.

Breadth comes afterwards. Once the loop holds, the honest questions arrive on their own — who else has this task, what changes for them, and what breaks when the input is messier than yours. Those are good problems to have. They are earned by having something that works.

Producing a plausible artefact is now close to free. That has quietly moved the scarce skill. It is no longer production. It is deciding what deserves to exist, and being able to tell whether what came back is actually right.

Deciding what deserves to exist

Cheap output multiplies the cost of building the wrong thing, because more wrong things get built. That question used to be answered implicitly by scarcity: if nobody had capacity, it did not happen. The filter is gone, so it has to be applied deliberately. Most of the value in this way of working comes from what you decide not to build.

Checking the result

Treat every output as a claim to be verified, not an answer to be accepted. Run it on inputs where you already know the correct result. Run it on the awkward cases you would hand a new colleague in their first week. Look at what happens when the input is empty, malformed or deliberately hostile. Fluent prose is not evidence of a correct calculation, and a confident tone is not evidence of anything at all.

Privacy, security and consequence

The moment a build touches real customer data, employee data, credentials or money, it stops being a private experiment. Ask what goes into the tool, where it is stored, who can reach it, and what the worst plausible outcome is if it leaks or is wrong. If you cannot answer those, that is precisely the signal to bring in people who can — before the thing is in use, not after.

Reliability

This is the quiet one. A prototype that works most of the time is a useful prototype. A workflow colleagues depend on that works most of the time is a liability, because the failures land on somebody else’s day and they have no way to see them coming.

What people build reflects what they already understand. Domain knowledge is the advantage; the tool only removes the implementation barrier standing in front of it. That is why the most useful internal tools tend to come from the person closest to the problem, not the person closest to the technology.

Marketing and sales

Campaign tools that assemble variants against a real brief. Customer research that reads the whole set of interviews rather than the three you had time for. Account intelligence gathered before the call instead of written up after it. Proposal systems that reuse what actually won, rather than what was easiest to copy.

HR and operations

Onboarding prototyped by the person who runs onboarding. Internal tools that replace a shared spreadsheet with something that validates its own inputs. Automations for the recurring administrative work that never reaches an engineering backlog, because it is nobody’s headline priority and everybody’s daily cost.

Product, design and engineering

Working prototypes instead of static mock-ups, tested with people before the backlog exists. Designers moving from what it looks like to what it does. Engineers compressing the path from decision to production and spending their judgement on the parts that genuinely need it.

Founders and hands-on leaders

Products, services and experiments built with smaller teams and fewer handoffs — and the ability to check a hypothesis personally rather than commissioning someone to check it for you.

The ability to build is no longer confined to one department. That is the practical meaning of the product builder era: the same disciplines, with wider range.

A prototype promises one thing: that an idea can be examined. Production promises something much larger — that it will keep working, for people who did not build it, when you are not watching.

Confusing the two is the most expensive mistake in this whole practice, and it almost never happens by decision. It happens by drift. A prototype becomes useful, someone shares it, a second team starts to rely on it, and nobody ever declared it live.

Bring the relevant people in before that line is crossed, not after.

• →Engineering — when other people depend on it, when it has to run unattended, or when it must survive change without you present.
• →Security — before it touches credentials, customer data, payments, or anything reachable from outside the company.
• →Legal and privacy — before personal data is collected, stored, moved between systems, or sent to a third-party model.
• →Data — when a number or a decision leaves the tool and enters a report, a forecast or a customer conversation.
• →Operational ownership — before anyone is told to use it. Somebody has to own it when it breaks at an inconvenient hour, and that person should agree to it in advance.

Naming the transition out loud prevents most of the damage. Say which of the two you have built, and say what would need to be true to promote it.

The tools change every few months. What holds is a room of people who have tried the same things and will tell you plainly what did not work. Nearly everything in this guide was learned that way — in workshops and buildathons where people built in the same room and then compared results, including the parts that failed.

VibeConf grew out of that habit. The community record of what people built together — the events, the partners, the demos — is public, and it is the most honest description of how this way of working actually develops.

Two of the confirmed 2026 sessions go straight at the questions in this guide. Dream Machine or Co-Designer? asks where AI stops being a tool and starts acting like a collaborator. Permission first, Process second asks whether it is the tools or the culture that decide if a team builds anything at all. If you are starting from no technical background, the companion guide to coding with AI without becoming a developer is the better place to begin.