Get started
Your first project in Studio
Studio turns a prompt into a working web app, then lets you edit the code, preview it live, and deploy it. This walkthrough takes you from an empty dashboard to a public URL.
Create the project
-
Sign in
Open studio.wrenchit.net and sign in with your Wrenchit account. If your workspace uses single sign-on, you land in the workspace you last used.
-
Describe what you want
The dashboard asks “What will you build?”. Write the app in plain language: the pages, the data, and the one action a visitor should be able to take. A good first prompt is specific and small.
Build a one-page site for a coffee roaster. Sections: hero, three coffees with price and tasting notes, and a wholesale enquiry form. Use a warm, minimal design. The form should show a confirmation message instead of reloading. -
Start the build
Submit the prompt and create the project. Studio opens the editor and starts generating the app. You can watch the preview update as files are written.
-
Wait for the first render
A first build usually takes a minute or two. If the preview is blank, wait for the build to finish before changing the prompt; sending a second request mid-build can produce a half-applied change.
The editor
Studio is split into three working areas. You do not need to use all of them, but knowing what each one is for saves time.
| Panel | What it is for |
|---|---|
| Chat | Describe changes. The agent edits the project and reports what it changed. |
| Preview | The running app. Use it to check layout and behaviour before you deploy. |
| Code | The project files. Read them, edit them directly, or use them to understand what the agent built. |
The project menu holds the name, the deployment history and the domain settings. Rename the project early; the name is used in the default preview URL.
Iterate
Make changes one at a time and check the preview after each one. Small, concrete requests are easier to review than a broad restyle.
- Change content: “Replace the three coffees with these four, and keep the same card layout.”
- Change behaviour: “Validate the email field and show an inline error when it is empty.”
- Fix a bug: “The form confirmation stays visible after a reload. It should reset when the page loads.”
If a change goes the wrong way, use the project history to return to the previous version before asking for something different. Stacking a second fix on top of a bad change usually makes the diff harder to read.
Review the code before you deploy. The preview shows what the app looks like; the code panel shows what it does. Check both when the app handles user input, payments or personal data.
Deploy
Deploy from the editor when the preview is what you want. Studio keeps three deployment targets:
| Target | Use it for |
|---|---|
| Development | Your own checks. Safe to break and redeploy. |
| Prototype | Sharing with a reviewer or client. Expect it to change. |
| Production | The public version. Deploy here when the change is ready for visitors. |
Each deploy produces a URL. Production also gets the project's stable URL, so the address you share does not change between releases. Deployment history keeps earlier builds so you can roll back without rebuilding.
Connect a domain
-
Open the domain settings
In the project, open the deployment or domain settings and choose Add domain.
-
Enter the hostname
Use a subdomain such as
app.example.comrather than the apex unless you intend to move the whole domain. -
Add the DNS record
Studio shows the record to create. Add it at your DNS provider exactly as shown, then return to Studio and wait for verification. A new record can take a few minutes to propagate.
-
Wait for the certificate
The domain is issued a certificate after DNS verifies. Until then the host may show a certificate warning; that is expected during setup, not a reason to change the record.
What to expect
Studio is a builder, not a general-purpose host. It is the right tool for marketing sites, dashboards, forms and small apps that fit the project model. It is not the right tool for long-running background jobs, custom daemons or workloads that need a specific system package.
- Build time: a first build takes longer than a follow-up edit. Large projects take longer still.
- Concurrency: let one build finish before starting the next. Parallel prompts on the same project can conflict.
- Data: a static site has no server-side data. If the app needs to store submissions, connect a backend or a form service before you call it production-ready.
- Secrets: do not paste API keys into the chat or commit them to project files. Use the project's environment settings.
If the preview will not load
Check the build log first. A failed build leaves the previous preview in place, so an old version can look like a new one that did not apply. Fix the build error, redeploy, and confirm the build number changed before you test again.