The hardest part of putting an AI assistant to real work is not the technology. It is the blank prompt box. Once your assistant can ship working software instead of code blocks, the question stops being "can it?" and becomes "what should I ask for first?"
That first request matters more than any request after it. Pick well and you get a live tool your team uses this week, plus the confidence to delegate the next ten. Pick badly and you burn an afternoon on something too vague to finish, then quietly go back to spreadsheets. This guide is about picking well.
Quick answer
The best first build is annoying, bounded, and shareable: a chore you already do by hand, small enough to describe in three sentences, producing a link or file someone else will actually open. An uptime monitor, an invoice maker, or a price watcher all qualify. Describe the outcome in plain language, review the result at its private URL, and publish when it earns it.
Key takeaways
- First builds fail on scope, not capability. Choose a job you could explain to a new hire in one minute.
- The three traits that predict success: it is already annoying, it has clear edges, and the output is something you would share.
- Start from a proven shape rather than a blank prompt. A template turns "what do I even ask?" into "here is my version of a thing that works."
- Judge the first build by one test: did you send the link to someone? A tool nobody opens taught you nothing.
Why the first build is different
Your fifth assistant-built tool can be ambitious. Your first one has a different job: it has to prove the loop works. Request in, working link out, changes handled in plain language, spending under a cap you set. Every part of that loop is easier to trust once you have watched it complete once.
That is why the right first build is deliberately unimpressive. You are not trying to replace a product; you are trying to retire one recurring annoyance and get a URL you can open on your phone. Ambition comes free after that.
The three traits of a good first build
It is already annoying. The strongest candidates are chores you do today, badly, by hand: re-checking a page, re-formatting a file, re-sending a document that is 90 percent identical to last time. An existing annoyance means you already know what "done" looks like, and you will notice immediately if the tool gets it wrong. Inventing a brand-new workflow and building it are two separate hard problems; do not stack them on your first attempt.
It has clear edges. You should be able to describe the whole job in three sentences: what goes in, what comes out, who looks at it. "Watch these five URLs and show me a status page" has edges. "Help us manage projects better" does not. If the description needs a meeting, it is not a first build.
The output is shareable. The point of an assistant that ships real software is that the result lives at a URL, not in the chat transcript. So pick something with an audience, even an audience of one colleague. A status page the team checks, an invoice a client receives, a deals page you send to a friend. Sharing is also your success metric, and it is why every AI agent should be able to return a URL in the first place.
Five proven starting points
These five shapes come from watching what people actually build first, and each one has a template so you start from a working example instead of a blank prompt.
| Start here if... | Build this |
|---|---|
| You re-check the same pages or ask "is the site down?" in chat | URL uptime monitor |
| You copy last month's invoice and edit the numbers | Invoice and quote maker |
| You clean the same messy export every week | CSV cleanup portal |
| You keep a browser tab open to watch a price or listing | Price and job watcher |
| You are hunting specific gear and deals sell out before you see them | Telescope deal watcher |
The uptime monitor is the best default. It is useful to almost every team, it demonstrates the part chat alone can never do (it keeps checking after the conversation ends), and the result is a page everyone understands at a glance. The invoice maker is the strongest pick for freelancers and agencies, because the output lands in front of a client the same week.
Notice what is not on the list: dashboards that need five data sources, anything with payments, anything you would describe as "a platform." Those are fine second and third builds. The best use cases for AI agents that ship software covers the wider field once your first tool is live.
How to run the first request
Write the goal like a brief: audience, outcome, definition of done. "Our team keeps asking if the client sites are up. Give us a status page for these six URLs that checks every few minutes and shows history. Done means anyone can open one link and know." That is enough; the assistant is better at the technical decisions than your spec would be. The full version of this habit is in the manager's guide to delegating real work to an AI assistant.
Two settings make the first run safe. New projects are private by default, so the first version can be wrong in front of you and nobody else; review it at its private URL like a draft, ask for changes in plain language, and flip it public only when it earns it. And set a budget cap before you start, so the worst case of any experiment is a paused task rather than a surprise bill.
Then apply the only test that matters: send the link to one person who shares the annoyance. If they open it twice, you picked well.
Ready to try it? Get started free and give your assistant its first real outcome.
FAQ
How long does a first build take?
For the shapes above, expect a working private version in one session. Most of your time goes to review rounds, which is exactly where your judgment belongs.
What if I am not technical at all?
These first builds are designed for plain language. Describe the annoyance and the outcome; the assistant handles servers, code, and hosting. If you can write the brief, you can delegate the build.
Should I start from a template or a blank prompt?
Template, almost always. A template is a proven shape with a live example attached, so you spend your first session adapting something that works instead of discovering scope the hard way.
What makes a bad first build?
Anything you cannot describe in three sentences, anything that needs data nobody can export, and anything with no audience. Vague scope is the number one killer; missing capability is rarely the problem.
Related reading
- A manager's guide to delegating real work to an AI assistant
- The best use cases for AI agents that ship software
- 5 internal tools your startup should not waste engineering time on
- From prompt to live URL: uptime monitor