Requesting Changes to Your Product
Evolve your launched product by describing changes in plain language, with an estimate before anything runs.
Launch is the beginning, not the end. Change requests are how you evolve your product: you describe what you want in plain language, review an estimate, and the platform implements it, commits it to your repository, and deploys it. No developer required, no ticket queue.
How it works
- Open your project and start a change request.
- Describe the change as you would to a person: "Add a testimonials section to the homepage with three quotes", "Customers should get a reminder email 24 hours before their appointment", "The dashboard chart should show the last 90 days, not 30".
- The platform analyzes your codebase, proposes what it will do, and shows an estimated credit cost. Nothing runs until you approve.
- On approval, the change is implemented, verified, committed to your GitHub repository as a readable commit, and deployed. If verification catches a problem, the repair loop fixes it before the change goes live.
Writing requests that land on the first try
- One intention per request. "Add a FAQ page" and "change the color scheme to green" as two requests beat one combined request — smaller changes are estimated more accurately, verified more reliably, and rolled back more surgically if needed.
- Say what and why, not how. "Visitors keep missing the booking button — make it much more prominent" gives better results than prescribing pixel sizes, though you can be prescriptive when you have exact requirements.
- Include exact text when text matters. If you want specific wording, prices, or names, paste them; otherwise placeholder-quality copy is generated for you to refine later.
- Point at things by name: "on the pricing page", "in the confirmation email", "the header on mobile".
Scope: small to large
Change requests handle everything from copy edits to new features: new pages, new fields on existing forms (including the database migration that implies), new integrations, layout changes, behavioral rules. Larger requests get larger estimates and occasionally a suggestion to split into stages. If a request would fundamentally change what the product is, the platform will say so and propose treating it as a bigger piece of work rather than pretending it is a tweak.
Safety net
Every change is a commit in your repository, and deployments switch over only after health checks pass. If you dislike a change after seeing it live, you can request the reverse or use a rollback — see the Rollbacks guide. The one caution: changes that alter the data model interact with real data, so on a product with live customers, read those estimates and descriptions extra carefully before approving.