Plan before you build

Before Claude builds anything, talk the idea through with it. That conversation decides what your first version is, and NodeGX saves it in your project as the app's brief and build plan.

This is the most useful thing you will do on the whole project. Don't skip it.

A conversation, not one message

If you write "build me an app for my running club", Claude will guess everything you didn't say. Some guesses will be wrong, and you'll find out after it has built them.

A back-and-forth works better. You describe the idea, Claude asks questions, you answer, and you both argue about what matters. Changing your mind here costs a sentence. Changing it after the app is built costs a rebuild.

Starting with "build me X" instead of "let's talk about X" is the most expensive shortcut there is.

Start the conversation

Open the Claude desktop app, click the Code tab, and start a new conversation. (If you haven't connected NodeGX to Claude yet, do that first: Install Claude and NodeGX.)

Copy this, fill in the brackets, and send it:

I want to build an app in NodeGX. Before you build anything, help me plan it.

My idea: [say everything: who it's for, what it does, why you want it]

Ask me questions a few at a time. Push back if something is too big
for a first version, and tell me what you would recommend.
When we've agreed the plan, create the project in NodeGX.

In the first message, say everything. Don't hold back parts of the idea because they seem too big. Cutting comes later.

What Claude will ask you

NodeGX tells Claude to settle five things with you before it creates a project:

• What it is. One or two sentences.
• Who uses it. You, your customers, your team, the public.
• What it stores. The things the app keeps track of: members, bookings, recipes, orders.
• The pages. Each screen someone will see.
• What it won't do. The things you agree to leave out.

Questions people usually miss

These are the ones that cause rework later. If Claude doesn't ask, bring them up yourself:

• Log-ins. Do people need an account? Or can anyone use it without signing in?
• Who sees what. Can everyone see everything, or only their own things? Is there an admin who sees more?
• What it remembers. When someone closes the app and comes back tomorrow, what should still be there?
• The first-time screen. What does a page look like before anything has been added? A new person sees that first.
• Phone or computer. Where will people mostly use it?
• Who manages the data. Who adds, changes and deletes things? You, or the people using it?
• Emails and payments. Does the app need to send emails, or take money?
• What it won't do yet. Name the things that can wait for a second version.

It's fine to say: "I don't know. What would you suggest?" That's a good answer. Claude has seen a lot of apps and will usually have a sensible recommendation.

If a word comes up that you don't know, ask Claude to explain it, or look it up in Words, in plain English.

Let Claude disagree with you

Claude should be recommending, not just agreeing. If it never pushes back, you're not getting the value. Ask for it:

Be honest. Is this realistic for a first version? What would you cut?

Claude tends to play safe. If you think there's a bolder option it isn't mentioning, ask:

What would you do if this were your project?

You don't have to take its advice. You do want to hear it.

Cut it down to a first version

Most first ideas are too big. Watch for these three thoughts in yourself:

• "Everything is essential." Ask which one thing people would miss most. Build that first.
• "It's not that complex." "Just a chatbot" turned into eleven separate jobs in one of my projects. If you're not sure how big something is, ask Claude, and put it in the second version.
• "People won't understand it without X." Build something simple first. If people get confused, you'll learn what to explain.

Agree what's in the first version, what waits, and why. Here's how that looked on one of my projects:

First version: member sign-up, a library of tools with filters, a guides section, an admin page.

Later: the AI assistant, working together in real time, links to other services.

What you walk away with

When you both agree, Claude creates the project in NodeGX. It writes the conversation into the project as its brief and its build plan:

• The brief: what the app is, who it's for, what it stores, the pages, and what it won't do.
• What you turned down, and why. So nobody suggests it again next month without knowing.
• Open questions. Anything you didn't actually decide is written down as a question for you, not guessed.
• The build plan: the pages and pieces Claude will build. Nothing is built yet. You read the plan first.

Because it's saved in the project, it doesn't disappear when the conversation ends. A new conversation can read it and pick up where you left off.

What the files are

The brief and plan are plain text files in a docs/ folder inside the project: BRIEF.md, ARCHITECTURE.md, CONVENTIONS.md and decisions/000-initial-scope.md, which also records the build plan. NodeGX also writes a CLAUDE.md at the top of the project that points Claude at them. You can open and edit any of them in a text editor.

Next, before anything is built, see what it will look like: See it before it's built.

Quick reference

• Talk first, build second. Start with "help me plan it", not "build me".
• Say everything in your first message. Cut later.
• Ask Claude to push back: "What would you cut?" and "What would you do if this were your project?"
• Cover log-ins, who sees what, what it remembers, empty screens, phone or computer, who manages the data, emails and payments.
• "I don't know, what would you suggest?" is a good answer.
• The agreed plan is saved in your project as its brief and build plan.