How it works

From idea to live, then on to the next version

Connect your agent, go live safely, then plan, build and ship each next version from one board.

Six steps, start to finish

  1. Connect your agent or start from a template

    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.

  2. It goes live safely

    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.

    • Every release scanned for leaked keys before it ships
    • Backups, checked by restoring them
    • Sign-in for your users
    • Monitoring and a public status page
    • Its own address with HTTPS, renewed for you
    • One action to undo a release or restore a backup
  3. Plan the next version with the roadmap assistant

    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.

    Refining PaymentsClose session ×

    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.

    Questions for you
    1. Which payment account should it use?The clinic’s existing account
    2. Charge at booking or after the session?At booking

    Here is version Payments: three tickets and two setup steps. Change anything by asking here.

    Ask for a change to the plan…
    Payments+ Add a deadline
    Clients pay when they book, and get a receipt by email.
    DecisionsSettled once for the whole version. Its tickets build on these instead of asking.
    Payment providerThe clinic’s existing payment account
    When to chargeAt booking, the full price of the session
    RefundsHandled by the clinic by hand for now
    Setup stepsWhat you do before the tickets can run. These become a Setup ticket assigned to you.
    Add your payment account key on the settings pageThe platform checks that PAYMENT_API_KEY is set on the development site.
    Before work starts ▾
    Switch on sign-in for your clientsThe platform checks that managed sign-in is on.
    Before going live ▾
    Build order: 3 ticketsBuilt top to bottom. Each ticket starts once what it needs is on develop.
    1. 1Checkout page at the end of a booking
    2. 2Receipt email after paymentafter 1
    3. 3Show paid or unpaid on each bookingafter 1
    Put on the queueJust planAssign them to @softkiln, it starts right awayCreate version and tickets
  4. Tickets land on the board

    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.

    To do1
    • APP-22Refund from the booking page
    In progress1
    • APP-21Receipt email
    Develop1
    • APP-20Checkout pageAPP-20: Checkout pageMoved when its commit landed
    Production1
    • APP-12Sign up with email
  5. The coding agent builds each ticket onto the development site

    Assign 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.

    APP-21Receipt email
    1. SpecDone

      AgentShould the receipt include the VAT line?

      YouYes, for Norwegian customers.

    2. ImplementDone

      Three files changed

    3. Independent reviewRunning
    4. Deploy to the development siteNext
  6. You promote to production when you are happy

    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.

What you never have to do

Not shortcuts: these jobs stop existing. They are the reason a working prototype usually stalls before it reaches anyone.

  • Choosing, sizing or patching a server
  • Installing a certificate, or noticing the week it expires
  • Writing a backup script, and finding out on the bad day whether it works
  • Keeping a file of passwords and keys, and keeping it out of the repository
  • Wiring up monitoring so you learn about downtime before your users do
  • Remembering to check whether the last release leaked a key

Where your product runs

In Europe, by default
The running product and its backups sit in EU infrastructure. It is not a setting you have to find and switch on.
On your own address
Every product gets a softkiln.com address immediately. On Pro you point your own domain at it, for the product and for its status page, and the certificate is renewed for you from then on.
Apart from where you experiment
The development site and the live one are genuinely apart, with their own data and their own secrets, so trying something out cannot reach your users.

More detail in the FAQ, and what it costs on pricing.

Ready when you are

Start free and have something live in the next ten minutes.