Your AI assistant writes the code. You write the brief, and the brief decides whether you get a toy or something your team will use. Here are 5 principles, each with a prompt that goes wrong and one that works.
Run helix login once, then open your assistant and ask. Every Helix project carries instructions for the assistant, so it already knows how Helix code is written. Spend your words on the app.
1. Say who uses it and what decision it supports
Name a feature and you get that feature. Name a person and the decision they make, and you get an app shaped around their day.
Before:
Build me a renewals dashboard.After:
Create a Helix app: a renewal tracker for account managers, who
use it every Monday to decide which renewals to work this week.
Start with one record per renewal: account, owner, renewal date,
value, and a reason from a fixed list when it's at risk.Now the assistant knows what goes first on the screen and which fields matter. Every guide in the prompt library opens this way: the app, the people, the decision.
2. Name the systems, and say which way
Name every system the app reads from or writes to, and say which way. Read only is the safe default, so say where it should write.
Before:
Connect it to Salesforce. Here's my API token: 00Dx...After:
Connect it to Salesforce to read renewal opportunities, and to
Slack to warn the owner when a renewal needs attention. Everything
else is read only.With Helix you never paste a key. When the app needs Salesforce, the assistant lists the authentications in your Tray workspace and you pick one. If there isn’t one yet, it gives you a link to create it in Tray. The secret stays in Helix, never in the code or the chat. You don’t have to ask for any of this, or for a login page: every Helix app works this way.
3. Build one screen at a time, and run it between steps
One giant prompt gets you one giant guess. Build a screen, look at it, then ask for the next.
Before:
Build the whole app: records, the weekly view, the manager roll-up,
alerts, reporting, and the Salesforce sync.After:
Build just the list of this quarter's renewals from Salesforce for
now. Leave alerts and reporting for later. Run it and give me the URL.Open it, click around, and write your next prompt about what you saw. “The at-risk reason should be required” beats anything you’d have guessed up front.
4. Ask for a plan before anything risky
Most changes are cheap to undo. Get a plan first for anything that changes how data is stored, deletes records or adds a new write to a system of record.
Before:
Change it so renewals can have more than one owner.After:
I want renewals to support more than one owner. Before you change
anything, explain what changes in how records are stored, what
happens to existing records, and which screens and Salesforce
writes are affected. Don't write code until I say go.Restoring an earlier deployment brings back the code. Your data stays as it is, so a bad data change is the one mistake a redeploy won’t fix.
5. Deploy early, then keep iterating
Put the app on a URL as soon as the first screen works. A few real people on a real link will teach you more than another hour of polish.
Before:
(Nothing. The app stays on your laptop until it's "finished".)After:
Deploy my app.That’s the whole prompt. The URL, connections and access settings carry over on every redeploy. If something breaks, ask the assistant to read the deployed logs and find the failing run.
Before you share the link widely, set the project’s Access Control tab in the Helix dashboard. By default, everyone in the workspace can get in.
All 5 in one prompt
Create a Helix app: a renewal tracker for account managers, who
decide each Monday which renewals to work this week.
Start with a list of this week's renewals from Salesforce. Run it and tell me what you built.
Later we'll post a Monday summary to Slack.
Before any change to how data is stored, explain the plan and wait.For staged prompts for fifty real apps, browse the prompt library.