Writing Good Prompts
The quality of what Vulcan builds depends almost entirely on how you describe what you want. This guide shows you what works, what doesn't, and why.
The core idea: describe the outcome, not the solution
The AI figures out how to build things. Your job is to describe what you need and who uses it. The more concrete you are about those two things, the better the result.
| Instead of... | Try... |
|---|---|
| "A task tracker" | "A task tracker where my team can add tasks, assign them to a person, mark them done, and filter by status" |
| "A dashboard" | "A daily ops dashboard showing open delivery exceptions grouped by region, with a button to mark each one resolved" |
| "Something for inventory" | "An inventory tracker with item name, SKU, quantity on hand, and reorder threshold — alert me when stock is low" |
| "A form" | "A form where drivers can submit end-of-day reports with their name, route, stops completed, and any issues" |
The vague versions aren't wrong — they just leave too much to guesswork. The AI will make choices that may not match what you had in mind.
Say who uses it
"Just me" and "my whole dispatch team" produce completely different apps. The AI designs differently based on who's using the thing.
"Just me — I want to track my daily tasks" "20 dispatchers on the ops team — they need to look up a driver and see their stop status" "Managers only — they review and approve expense requests submitted by drivers"
Describe the data
Tell the AI what information your app needs to track. Think of it like describing a spreadsheet: what are the columns?
"Each delivery exception has a driver name, route ID, issue type, timestamp, and whether it's been resolved." "Each employee has a name, team, role, Slack handle, and start date." "Each expense has an amount, category, description, date, and who submitted it."
You don't need to know database terminology. Just describe the fields like you'd describe filling out a form.
Before/after examples
Building a stop tracker
Before (too vague):
"A stop tracker"
After (clear and specific):
"A stop completion tracker where dispatchers can search for a driver by name and see which stops they've completed vs pending for today. Let them mark stops complete and add a short note to each one."
Building an approval tool
Before:
"An approval thing for our team"
After:
"A request approval queue. Anyone on the team can submit a request with a title, description, and category. Managers can approve or deny each one and leave a note. Show open requests separately from closed ones."
Asking for a change
Before:
"Fix the table"
After:
"The table is showing all records including resolved ones. I only want to see open exceptions by default. Add a toggle to show resolved ones if needed."
One thing at a time
This is the most common mistake: trying to describe an entire app in one message.
The AI can build complex apps — but not all at once. The best results come from starting small, checking the preview, and adding the next feature when the first one is working.
The pattern that works:
- Start with the core — the one thing the app absolutely has to do
- Check the preview — does it look right? Does it work?
- Add the next feature
- Repeat
First message: "A table of delivery exceptions with driver name, route, issue type, and timestamp. Include a form to add new ones." Second message: "Add a button to each row to mark it resolved." Third message: "Add a filter above the table to show only open exceptions."
Each step is small enough that if something goes wrong, you'll catch it immediately. Stack five features in one message and you might get something that technically runs but is broken in subtle ways you won't notice until later.
→ More on building incrementally
Describe problems, not solutions
The AI knows how to build things. You don't need to tell it how — just describe what you're trying to accomplish.
Skip the technical details unless you have a strong reason:
| You don't need to say... | Just say... |
|---|---|
| "Use localStorage to save the filter state" | "Remember my filter settings if I refresh the page" |
| "Add a debounced onChange handler to the search input" | "Search should filter as I type" |
| "Create a REST endpoint at /api/drivers" | "Let me pull in driver data from our internal API" |
Describing the outcome lets the AI choose the right approach. Describing the implementation can actually constrain it into a worse solution.
Give feedback with "expected vs actual"
When something's wrong, the most useful feedback tells the AI what you expected to happen versus what actually happened.
Less useful:
"The filter doesn't work"
More useful:
"When I select 'Pending' from the status dropdown, I expected to see only pending items. Instead it still shows all items including completed ones."
Less useful:
"The form is broken"
More useful:
"After I submit the form, I expected the new item to appear in the table below. Instead the form clears but the table doesn't update until I refresh the page."
The more specific you are, the faster the AI can fix it — because you've already diagnosed what is wrong, not just that something is.
Recovering from bad output
The AI doesn't always get it right. A few things that help:
Undo and try again:
"Undo that last change. Let's try a different approach — I want [more specific description]."
Narrow the scope:
"You changed a lot of things I didn't ask for. Can we focus only on [specific thing] and leave the rest of the app alone?"
Ask for a plan first:
"Before you write any code, tell me what you're planning to change and why. I want to make sure we're aligned."
If it went completely sideways:
"This isn't what I had in mind. Can we start over with just [core feature] — something simple, no extra features."
Prompt starters to copy
Starting a new app:
"A [type of app] for [who uses it]. It needs to track [data fields]. Users should be able to [key actions]."
Adding a feature:
"Add [feature]. It should [what it does]. Show it [where in the UI]."
Fixing something:
"When I [action], I expected [expected result] but instead [actual result]. Can you fix that?"
Scoping a change:
"Only change [specific thing]. Don't touch anything else."
Undoing a change:
"Undo that last change and go back to how it was before."