Where Vercel fits — and where teams hit the wall
Where Vercel fits well: frontend teams who want previews on every pull request, a global edge in front of their pages, and deployment that disappears into the git workflow.
Where teams outgrow Vercel: when the frontend turns out to be the easy half — the product needs its own data, long-running jobs, and search, and each of those arrives as another vendor beside the platform that was supposed to be the platform.
What Vercel deliberately does not run
Vercel hosts the interface and the functions attached to it, and it is very good at that. Databases, queues, file storage, and search are partner products from a marketplace: excellent tools, but each with its own account, keys, console, limits, and invoice.
So the production system a reviewer has to understand is Vercel plus the database vendor plus the queue plus the search service — while the deploy button only tells the story of the first one.
The backend in the same project
On KERNSTACK the pieces behind the interface are resources of the same project: tables for records, buckets for files, a search index over both, workers for work that outlasts a request, and workflows when steps need order or an approval.
- Gateway routes serve the interface; functions and workers sit behind the same stack.json
- Preview and production run the same declared shape, so a review shows the whole system
- One credit balance replaces the platform bill plus each attached vendor
Side-by-Side: Vercel vs KERNSTACK
| Dimension | Vercel | KERNSTACK (Software Lifecycle Cloud) |
|---|---|---|
| Focus | Frontend hosting, previews, and edge delivery | The whole product: routes, compute, data, search, workflows |
| Backend data | Partner databases and storage from a marketplace | Tables and buckets as resources of the project |
| Long work | Functions with platform execution limits; queues are add-ons | Container workers and declared workflows with human steps |
| Agents | Not part of the platform model | Agents draft in sandboxes; people approve the plan |
| Bill | The platform plus every attached vendor | One credit balance for the whole project |
| Hosting | Hyperscaler regions behind the platform | Our own bare metal in Europe, one zone per project |
Frequently asked questions
Yes. Teams often move data and background work first: tables, buckets, and workers on KERNSTACK, called from the frontend they already ship. When they are ready, gateway routes in the same stack.json can serve the interface as well, and the project becomes one graph.
No. Builds, routing conventions, and function shapes differ, and nothing is imported from a Vercel project. What carries over is the code and the architecture; the deployment is re-declared in stack.json, which is also what makes the whole system reviewable in one diff.
A backend that is declared instead of assembled: data, files, search, jobs, and workflows in one project, in one European zone, on one credit balance — with agents able to draft changes against that graph and people approving them before production.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.