Key takeaways

The hard part is no longer writing code or picking a tool. It is getting what you know out of your head and into a form precise enough to build from, and your expertise actively works against you here.
Expert knowledge compiles into intuition. You stopped noticing the rules years ago, which is why “just tell me what it should do” produces a description missing everything that matters.
Four moves get it back out: narrate a real case aloud, hunt the exceptions, find the decision points, and define what correct looks like.
Define correct before you build, not after. It is the test you will judge the output against, and without it you are evaluating on vibes exactly where you are least able to afford that.
The method ends where infrastructure begins. Once the description is right and the thing works, the remaining questions are about where it runs, and those have different answers.

You have accepted that you could build the thing. The tools work, colleagues have done it, and the problem you want to solve has been sitting there for three years. So you open one of these tools, and it asks what you want to build, and you type two sentences that feel thin even as you type them.

That gap is not a failure of nerve or of vocabulary. It is a real and well-documented problem with expertise itself, and it has a method. What follows is how to get twenty years of knowing something out of your head and into a description precise enough to build from.

Your expertise is invisible to you, and that is the whole problem

Here is the uncomfortable mechanic underneath this.

When you learn something, it starts as explicit rules you consciously apply. As you get good, those rules compile into intuition. You stop stepping through them and start simply seeing the answer. That compression is what expertise is, and it is why you are fast, and it is also why you cannot describe what you do.

This is why requirements documents were always bad. Someone would ask an expert what the process was, the expert would describe the version they could still articulate, and the version they could articulate was the beginner’s version, with every hard-won refinement compiled away and invisible. Then the software got built to the beginner’s description, and everyone was vaguely disappointed without being able to say why.

You are now on both sides of that conversation, which is an enormous advantage and a specific new difficulty. Nothing gets lost in transmission any more. But you do have to interview yourself, and you are a difficult interviewee.

Move one: narrate a real case out loud

Do not try to describe the process. Describe one specific instance of it, end to end, out loud, including the parts you would skip as obvious.

Pick an actual case from last week. Not a representative one, an actual one. Then talk through what you did, in order, as though explaining to a competent new colleague who knows the industry but not your job. Record it or type it as you go.

The phrase to listen for is “obviously.” Every time you say obviously, or “of course,” or “you’d just,” you have found a compiled rule. Those are precisely the bits that are missing from your two-sentence description, and they are usually the bits that make your version better than a generic tool.

A second pass helps: take the same narration and ask, at each step, “what would go wrong if someone did this differently?” The answers are the constraints you did not know you were carrying.

Move two: hunt the exceptions

The rules are the easy part. The value is almost entirely in what happens when the rule does not apply.

Any tool can implement “requests get assigned to the team that owns that product area.” What makes a tool usable is knowing that requests from one particular account always go to a named person regardless, that anything mentioning a specific regulation gets flagged before assignment, and that during the end-of-quarter window the whole thing works differently.

Those exceptions live nowhere except in the heads of the people who do the work. They are not in the process document. They are frequently not known to the manager. They are the single biggest reason internal tools bought or commissioned from outside feel wrong to the people using them.

So make a list, and make it deliberately. Go through the last month of real cases and note every one that did not follow the main path. You will typically find between five and fifteen, and they will account for a surprising share of the actual work.

Move three: find the decision points

Walk your narration again and mark every place where you chose between paths.

Each of those is a branch the software needs to make, and each needs the same three things spelled out: what information the decision depends on, what the options are, and what happens in each case. That is it. That is the shape of nearly all business logic.

The useful discipline is to be honest when the answer is “it depends on judgment.” Sometimes that means you have not yet articulated the rule and another pass will find it. Sometimes it genuinely is judgment, in which case the right design is for the software to surface the case to a person rather than guess. Knowing which of those you are looking at is itself expert knowledge, and it is a much better design input than pretending everything is deterministic.

Move four: define what correct looks like

Do this before you build, and do it in writing.

Take five real cases, including at least two awkward ones, and write down what the right output is for each. Not what the software should do. What the answer is.

This is the single highest-value thing in the whole method, for two reasons. It forces the remaining vagueness out of your description, because you cannot specify an output for a case you have not fully thought about. And it gives you a test. When the tool produces something, you compare it against your five answers, and where they differ you know immediately which is wrong and why.

Without this you are evaluating output on whether it looks plausible, and plausible is exactly what AI-generated software is best at producing when it is wrong. Confident, well-formatted, subtly incorrect in a case nobody considered. Your five answers are the defense, and no technical skill is needed to apply them.

Turning it into something to build from

You now have a narration, a list of exceptions, a set of decision points, and five worked answers. That is a better specification than most professionally written ones, and you can hand it over more or less as it stands.

Lead with the purpose in a sentence, then who uses it, then the main path from your narration, then the exceptions as a list, then the decision rules, then your five cases as examples of correct output. Plain prose is fine. You are not writing a technical document, you are transmitting what you know.

Then iterate by describing wrongness rather than editing anything. “When the request mentions the regulation, it should flag before assigning, not after” is a complete and actionable instruction. You do not need to know how it is implemented, and you should resist the urge to suggest, because your guess about implementation is the one part of this you are not the expert on.

This is where Agent Runners or any capable coding agent does its work, and the quality of what comes back tracks the quality of your specification far more than it tracks which tool you chose.

Verification is half the method

Build it, then run your real cases through it. All five, plus the awkward ones from your exceptions list.

The mechanism that makes this practical is having somewhere to run the thing that is not the real thing. On Netlify each change becomes a Deploy Preview, a complete running copy at its own URL with its own database branch, so you can push genuinely messy real-world cases through it without touching live records. Then when it is right, the same app is what goes live.

Expect the first pass to be wrong in ways that teach you something about your own description. That is not a setback, it is the method working: each mismatch is a compiled rule surfacing, and you add it to the specification. Two or three rounds is normal.

What not to build

The method works well enough that it is worth saying where to stop, because the failure mode of a good method is applying it to everything.

Do not rebuild something a mature product already does well. Encoding your own scheduling logic is a fine weekend; reimplementing a calendar is a hobby. The test is whether the value is in the general capability, which somebody has already built, or in your specific rules, which nobody has.

Do not build the thing that decides outcomes for identifiable people. Anything making clinical, legal, financial, or employment decisions about individuals needs review by people whose job that is, and that is a statement about the stakes rather than about you.

Do not build where being wrong cannot be undone. Software that moves money, sends communications on the company’s behalf, or deletes records has a different risk profile, and the honest move is to keep a person in the loop at the irreversible step.

And be wary of the process that is genuinely judgment all the way down. If your narration keeps arriving at “it depends,” the useful software might be something that gathers the information and presents it, rather than something that decides. That is a smaller build and frequently a better tool.

Where the method stops

At some point the description is right, the output matches your worked cases, and people start using it. The questions arriving after that are of a different kind, and no amount of domain knowledge answers them.

Where does the data live and is it backed up. Who is allowed to open this. What happens when you change it and the change is wrong. Who patches the thing underneath. Those belong to Netlify Database and the rest of the platform layer rather than to you, and most of them are properties of where you put the app rather than work you have to do.

Worth knowing the handover point exists, because people often assume the second set of questions is more of the first and conclude they are out of their depth. They are not. They have finished the part only they could do.

What you are actually good at here

The framing that gets this wrong is “non-developers can now write code.” That is true and it is not the interesting part.

The interesting part is that the scarce input changed. Code generation is close to free. What remains expensive is knowing which cases occur, which exceptions matter, what correct looks like, and which of the eleven steps exists for a reason nobody remembers. That was always the valuable half, and it was always the half that got lost on its way to the people who could implement it.

Most of what gets built this way is internal apps: trackers, calculators, intake forms, the dashboard that replaces a weekly email. Unglamorous, and collectively an enormous share of what an organization runs on. They were bad for decades because the knowledge and the implementation lived in different heads. That is the part that changed, and the method above is how you take advantage of it.

FAQs

How do non-developers turn what they know into software? By interviewing themselves before they build. Narrate one real case out loud including the parts that feel obvious, list the exceptions where the normal rule does not apply, mark every point where you choose between paths, and write down the correct output for five real cases. That becomes the specification an AI can build from, and it is usually better than a professionally written one.

Why is it so hard to describe what I do? Because expertise compresses. Rules you once applied consciously turn into intuition, and you stop being able to see them. That is what makes you fast and also what makes you a poor describer of your own process, which is why requirements documents historically captured the beginner’s version of a job.

What should I write down before building an app? Five things: what the tool is for in a sentence, who uses it, the main path from start to finish, the exceptions that break the main path, and the correct output for several real cases including awkward ones. Plain prose is fine. The worked cases matter most, because they become your test.

How do I know if the app the AI built is right? Compare it against the correct answers you wrote down beforehand. Run your real cases through it and check the output against what you would have produced by hand. This is why defining correct comes before building: without it you are judging whether output looks plausible, and plausible is what AI-generated software produces most convincingly when it is wrong.

What kinds of tools should a domain expert build? Things where the value is in your specific rules rather than in a general capability somebody has already built well: internal trackers, intake forms, calculators that encode a rule living in one person’s head, dashboards replacing a manually assembled report. Avoid rebuilding mature products, and route anything deciding outcomes for identifiable people through proper review.

Do I need to learn to code to do this? No, and the skill that matters is not code. It is articulating what you know precisely enough to build from, then verifying the result against cases you can grade. You will eventually want a developer’s help when the tool becomes something a team depends on, and building on infrastructure that produces ordinary code in a real repository is what makes that handoff possible.

Before you open any tool, narrate one real case and write down the correct answer for five more. Then see it running at netlify.new.