Use Case · Product

Customer portal on the Software Lifecycle Cloud

A customer portal on KERNSTACK replaces the emailed screenshot with a login: account status read from the tables your operations already maintain, files shared from buckets under the client’s prefix, and a project conversation — optionally mirrored to the client’s Telegram or WhatsApp — where questions land in topics instead of inboxes. The portal is not a second system; it is a window into the same project that does the work.

Edge GatewayObject BucketsCollaboration BoardNoSQL Tables
Talk to us Read Technical Documentation → Software Lifecycle Cloud →

The engineering bottleneck with assembled stacks

Customer-success leads email screenshots because the system of record has no client-shaped door. The screenshot is stale on arrival, the files it references live in a drive the client cannot open, and the follow-up question starts a new thread that loses the first one. Everyone is working hard; the client experiences archaeology.

Architecture on the Software Lifecycle Cloud

The portal is an app served by a gateway prefix route, reading status rows the operational side writes and listing the client’s bucket prefix for shared files. Access keys are per client; a handler scopes every read to the authenticated client’s slice. Conversation topics belong to the project, shareable with partners, so the “any update?” message becomes a place both sides can read.

One status, two audiences

The design refuses a separate portal database. The status the client sees is the row operations update — shipped, in production, waiting on documents — because a portal fed by sync jobs eventually lies, politely and with confidence. Scoping reads to the client’s key slice is a handler discipline reviewed in the same diffs as everything else in the project.

  • Files are shared by bucket prefix: the client sees exactly their folder, uploads land in it too
  • Questions attach to topics with states, so “waiting on you” is visible to both sides
  • Clients who live in WhatsApp or Telegram can follow the same conversation there

Trust is a freshness property

Portals fail socially when they lag reality: the client sees “in progress” for the thing delivered yesterday and stops believing the portal. Feeding the portal from the operational rows removes the lag class of failure entirely, which is worth more than any feature list the roadmap was arguing about.

FAQ

Frequently asked questions

With access scoped to their slice: the portal’s handlers take the client identity from the authenticated session or key and filter every read by it. Client A’s files, status, and conversation are keys Client B’s requests never construct.

Yes, with presigned URLs into their own bucket prefix — signed deliverables, documents, assets. Uploads appear in the same folder operations sees, so “did you get the file?” ends as a question.

They need portal credentials, not a platform account. Partners can also follow the project conversation from a bound Telegram group or WhatsApp chat, which for many clients is the only interface they will ever want.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Category PillarThe Software Lifecycle CloudWhy people and agents build, deploy, and operate on a single vertically integrated stack.Service · EdgeGatewayHTTP, WebSocket, and prefix routesService · DataBucketsObject storage with presigned uploadService · PeopleCollaborationBoards and conversations on the projectService · DataTablesServerless key-value and document tablesIndustry SolutionE-commerce Cloud SolutionsE-commerce on KERNSTACK owns the parts of commerce that constitute the business: the catalogue and its search, carts and checkout state, the order lifecycle, raw payment events reconciled into provable order states, and fulfilment workflows with human steps for the exceptions. Cards stay with the payment provider; the data that makes the business worth buying moves onto infrastructure the merchant controls, in Europe.Use Case · ProductExperiment assignmentAssignment is a pure function of the subject key and the experiment’s salt — stable across requests, no coordination needed. The function records the assignment row once and serves the variant; outcome handlers were already writing events, which now simply carry the experiment id the assignment returned. Analysis reads assignments and outcomes from neighbouring tables with the same keys.Use Case · AgenciesAgency client deliveryThe studio’s delivery shape is a template stack.json: gateway, functions or workers in the client’s stack languages, tables, buckets, and apps under one target per client, on European infrastructure the studio can name in the pitch. Previews run the same declaration; the client’s approval happens in the bound conversation with a live link. Every client’s meter is separate by construction — the studio sees delivery cost per client without allocation spreadsheets.

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →