Made for more than a proof of concept
Since last week basable.com opens with a new line: “Made for more than a proof of concept.” A tagline is a small thing, but choosing it made us say out loud what we are building, and what we are not, so here is the reasoning.
Everyone sells the first hour
Every AI app builder we compared makes the same promise in different words: describe it, and you have an app in minutes. The promise is real. We make it too, and the todo app walkthrough shows the clock. But speed is where these products are most alike, and it is not where apps fail.
Apps fail in the second week. The demo worked and someone started using it. Then a redeploy wiped the database, because the data lived in the container. The API key that was pasted into the code ended up in a public repository. The admin page turned out to be reachable by everyone. A payment provider wanted a webhook on a real domain with a real certificate. The app got slow and nobody could see why. And the bill arrived for a plan the app had outgrown. None of this shows in a demo. All of it decides whether the app survives its first users.
So the line is a claim about the second week, not the first hour. We would rather be measured on whether the app is still running a year from now, with its data, than on how fast the first version appeared.
What a proof of concept is missing
Here is what separates a demo from something people can rely on, and what Basable does about each of them today.
Data that outlives a deploy. A proof of concept keeps its data wherever was easiest, often a file inside the container, and the next deploy replaces the container. On Basable an app with a database gets a PostgreSQL cluster of its own, migrations that run before the new version starts, and a volume that keeps the data between deployments. Since this month the database also backs itself up into the environment’s own private bucket, base backups and a continuous archive, so a bad migration is a restore and not a loss.
Secrets nobody else sees. A proof of concept has the Stripe key in the source. On Basable the app reads its keys from a secret in its own cluster, the deployment waits until you have set them, and the values are never stored by us and never pass through the chat. The previous what’s new post describes how.
A place to try it before it is live. Every project has a preview environment with an address you can send to a colleague or a customer. The live environment follows only when you press Merge & Deploy, and that button does not open until the code has run on preview at least once.
An environment with walls. A proof of concept shares a machine with whatever else was on it. Each Basable environment is a Kubernetes cluster of its own, sandboxed from every other project at the kernel level, with its own resource limits and network rules. A neighbour cannot take your app down, and your app cannot take down a neighbour. A coming post goes through those walls one by one.
A build you can read. The build is a workflow in your own repository, run by your own CI. When something breaks, there is a log, a commit and a diff, and you can rerun every step. Nothing happened inside a box you cannot open.
Your own name on it. Three ways to put your own domain on a project, with certificates handled for you. Webhooks, sign-in providers and customers all get a real address.
A bill that follows use. There is no monthly plan to outgrow. Every new organisation gets a month free per environment; after that you pay for the capacity you reserve, by the second, and for AI by the token. A preview nobody touches goes to sleep and stops costing anything. The pricing page has every rate.
A way out. The code is ordinary: Dockerfiles or Bazel, a CI workflow, Kubernetes manifests, in a repository you own from the first commit. Any Kubernetes cluster can run it. The surest sign that something is more than a proof of concept is that it does not need us.
What is still a proof of concept here
Basable itself is in alpha, and a tagline does not change that. Monitoring is
not built in yet: you read your app’s logs with kubectl on its own cluster.
The assistant runs one vendor’s models. Native mobile apps are not there yet.
And expect rough edges: the pipeline from description to deployment works end
to end, but it has not seen everything. Teams that need a dedicated cluster,
their own infrastructure or ISO 27001 can write to us.
We would not have put the line on the front page if we did not expect to be held to it. Sign up with just your email, see how far the first version gets you, and then keep going past it.