Building your first app
From a single sentence to a checked, deployed app — what happens at each step and what Sneh needs from you.
Start with one sentence
Describe what you want the way you would say it to a colleague. You do not need a specification, a schema, or a particular phrasing. “A waitlist page for founders, with a private list of who signed up” is a perfectly good starting point.
Sneh is better with a sentence about the goal than a paragraph about the implementation. Say what the app is for and who it serves; let Sneh propose how.
What happens next
- Sneh asks a few focused questions, only where a choice genuinely changes the product.
- It drafts a Product Brief — what the app is, who it is for, what has to work first. You approve it or ask for changes.
- It builds in a real sandbox while you watch the preview update.
- It opens what it built, checks desktop and mobile, and reports what works and what does not.
- You deploy to a live URL you can share.
The brief step is worth your attention. Correcting a misunderstanding there costs one sentence; correcting it after the build costs an afternoon.
Giving good feedback
When something is wrong, say what you expected and what you got, in plain language. “The signup form does not work on my phone” is more useful than a guess at the cause — Sneh can look at the app and find the cause itself.
- Point at a screen or a behaviour, not a file.
- One problem at a time gets a cleaner fix than a list of five.
- If a change made things worse, say so — Sneh can go back.
Read next
- How credits workCredits measure build work, not messages. What a turn costs, what your free grant buys, and how topping up works.
- The Product BriefSneh writes a plan before it writes code, and asks you to approve it. Here is what is in it and why it matters.
- Deploying your appTaking your app from preview to a real URL you can send to someone, and what is not supported yet.
Did this miss what you needed? Email hello@sneh.ai — or browse the rest of the help centre.