standalone deployment
qrks.ai runs inside your own stack and edits your existing application. Your team asks for changes in a chat; the changes land in your repository as ordinary commits and go out through the pipeline you already trust - on your domain, under your brand.
no migration · no rebuild · your repo stays the source of truth
The pricing page headline is stale - make it match the new positioning, and add the enterprise tier to the table.
Two files touched - the headline and the tier table. Here's the diff.
01 / what it is
The hosted product builds a new site from scratch. Standalone does the opposite: it takes the application you have already built and puts our editing interface on top of it.
It works against the repo you already use, in the framework you already chose. Nothing is ported, rewritten or trapped in a proprietary format.
The site stays where it is, on the address your customers already know. The editing interface sits on a domain of yours too, carrying your name rather than ours.
Changes arrive as commits or pull requests and go out the way everything else does - your CI, your checks, your reviewers, your deploy.
02 / how it fits
Setting it up is a day's work, most of which is us reading your codebase.
You grant access to the repository and tell us which parts of it the agents may touch. Everything else is off limits by construction.
The whole system - interface, API, build agents - runs in infrastructure you control, alongside the application it edits.
Anyone you invite describes what they want in plain language. No branch, no local setup, no waiting for a free developer.
Reviewed if you want it reviewed, published if you don't. Either way it's a normal change in your history, with a normal way to undo it.
03 / why teams do this
Most of the value isn't the AI. It's what stops being a ticket.
The headline, the price, the new logo, the seasonal banner. Small, constant, and expensive when each one costs a context switch. Marketing ships them directly instead.
Every other tool in this category asks you to rebuild your site inside it first. This one meets your codebase where it is, which means the evaluation is a day rather than a quarter.
The deployment lives in your infrastructure, against your repository, with your model keys. There is no copy of your codebase sitting in someone else's account.
The output is commits in your repository. Turn the whole thing off and you keep every change it ever made, in a form your team can read.
Branch protection, required approvals, CODEOWNERS, status checks - all of it still applies. The agent is one more contributor, held to the same rules as everyone else.
Who asked for what, what the agent changed, which build published it. It's git history, so every tool you own can already query it.
Nothing is built until someone approves it, agents run in sandboxes with no open network access, and secrets are scanned for before any push. The guardrails from the hosted product come with it.
Marketing site, docs, careers page, the microsite for last quarter's launch. They can all sit behind the same interface instead of each growing its own CMS.
Agencies and platforms run it for their own clients under their own name. The people using it never need to know whose software it is.
04 / what stays yours
The short version of the security conversation, before it starts.
Your repository, your branch protection, your access rules. We don't keep a copy.
The deployment runs in your account, in the region you choose, behind your network controls.
Bring your own. You choose the provider and the model, and you see exactly what it costs.
Both the site and the editing interface sit on addresses you own.
Whatever publishes your site today keeps publishing it. We don't replace your deploy.
No export step, no data to retrieve. Switching it off leaves your codebase exactly as it is.
05 / faq
No. The hosted product generates Astro sites because it writes them from scratch. Standalone edits whatever you already have - the agents work on your codebase the way a developer would.
In your infrastructure, next to the application it edits. We'll tell you exactly what it needs before you commit to anything.
Yes, and for most teams that's the right setting. Each change can open a pull request for a human to approve, or publish directly where the risk is low - your choice, and it can differ per part of the site.
Your build and your checks. A change that doesn't pass them never reaches production, exactly as with any other contributor. On top of that, nothing is built until someone approves it and every push is scanned for secrets first.
Whoever you invite. The point is that people who can't open a pull request can still change the site - marketing, support, a founder on a phone.
It depends on the size of the codebase and how much of it you want in scope. Talk to us and we'll give you a number rather than a range.
qrks.ai standalone
tell us your stack and we'll tell you what it takes.