Victor Jeman Academy

How does a project actually start, before you write any code?

Requirements tell you what to build, for whom, and what done means.

Start with the requirements, not the editor

The most expensive mistake is building the wrong thing well. Requirements are where the client tells you what they want and where you commit to delivering it. They might arrive as a ticket, a design file, or a two-line message. Either way, you cannot start until you can restate them in your own words.

I am about to build [describe the feature]. Act as a senior developer and ask me, one question at a time, the things you would want answered before writing any code. Wait for my answer before each next question.

Know who it is for

The same dashboard means one thing to an admin and another to a first-time user. Who uses the feature, and what problem it removes for them, changes what you build.

Here is the feature I am building: [describe it]. List the user types you can infer from my description and what each one is trying to get done. Mark which user types are assumptions I should confirm with the client before I build.

Agree on what "done" means

"Done" is not "the code runs." It is the moment the client agrees the work solves their problem. Pin it down early, in plain language, and you skip the endless round of "just one more change."

Here are the requirements I was given: [paste them]. Rewrite them as a short, testable definition of done, and point out anything that is vague or missing.

The costly mistakes happen before the first line of code. If you cannot restate the requirements in your own words, you do not understand them yet.

Additional Resources

Explore these carefully curated resources to deepen your understanding and practice the concepts covered in this lesson.