Connect your agent, go live safely, then plan, build and ship each next version from one board.
Connect the AI client you already build with, or start from a template. There is nothing to install and no servers to pick.
Softkiln creates the product, gives it a database, and sets up two separate copies: a development site where you try things, and the live one your users see. You are never asked to choose a server size, a region or an operating system, because that decision has already been made and is the same for every product.
Publish, and the product is online with everything it takes to run in front of real people already switched on.
Keys and passwords live in encrypted storage and reach the product only while it runs, never the page a visitor downloads. Backups start on a schedule straight away and are checked by actually restoring them, not by trusting that the job ran. Uptime and response times are watched continuously, with ninety days of history behind a status page you can send people to.
Tell the roadmap assistant what the product should do next. It proposes a version: a goal, the tickets that get there, and any setup step it needs from you.
A setup step is something only you can do, like adding a payment provider's key, and the proposal says whether it is needed before work starts or before going live. You change the proposal or accept it, and the versions line up on a timeline.
Customers should pay when they book.
I read the booking code first. Payment fits right after a time is picked. Two questions before I plan it.
Here is version Payments: three tickets and two setup steps. Change anything by asking here.
The version's tickets appear on the product's board, in to do, in progress, develop and production. You can add your own the same way.
A card moves when its commit lands, not when someone remembers to drag it. So the board is a record of what is actually on the development site and what is live, rather than what somebody said.
APP-20: Checkout pageMoved when its commit landedAssign a ticket to the coding agent. It writes a spec, builds the change, runs the tests, has it reviewed independently, and deploys it to the development site.
When the ticket leaves a real choice open, the agent stops and asks you, and carries on with your answer. The review is a separate pass that sees the change and the test results, never the builder's own account of it. A ticket counts as done when the development site runs the change, not when the code is pushed.
AgentShould the receipt include the VAT line?
YouYes, for Norwegian customers.
Three files changed
Look at the change on the development site, then publish. Your users get it without the product going down.
Nobody sees an error while it happens. If it turns out wrong, one action puts the previous version back, and restoring a backup brings the data back with it. Nothing here is one-way, which is the point: people stop changing their product when they are frightened of breaking it.
Not shortcuts: these jobs stop existing. They are the reason a working prototype usually stalls before it reaches anyone.
Start free and have something live in the next ten minutes.