Operating an App
In the design, SaaS.Studio runs every App a Startup has from one place: its Versions and Domains, the Actions people take, and the Metrics they feed.
In the design, SaaS.Studio runs every App a Startup has from one place. It shows the Versions and Domains of each App, the Actions people take in them, and the Metrics those Actions feed.
Every App in one place
The management part lists each Interface of the Startup, the Domain it answers on, and the Version it serves. Open Changes sit beside the Version they would replace.
| Interface | Path | Live Version | Open Changes |
|---|---|---|---|
| API | leaseclock.com/api | sha256:9f2c4e1a7b3d | none |
| MCP server | leaseclock.com/mcp | sha256:9f2c4e1a7b3d | none |
| Portal | leaseclock.com/dashboard | sha256:9f2c4e1a7b3d | none |
| Admin | leaseclock.com/admin | sha256:9f2c4e1a7b3d | none |
| App per Persona | leaseclock.com/app | sha256:9f2c4e1a7b3d | Change 14, preview at change-14.leaseclock.com |
Every Interface serves the same Version, because each one derives from the same definition. Publishing Change 14 moves all five at once, and rolling back moves them back together.
Operations: one feed of Actions
The operations part is one feed of every Action across the Apps, newest first. Each row names the App, the person or Agent, the Verb and the status the Action ended in.
| At | App | Who | Action | Status |
|---|---|---|---|---|
| 09:14 | /app | a manager at Elm Street Rentals | Lease.renew on lease_1 | done |
| 09:15 | /app | the same manager | Lease.renew on lease_1 | refused: the lease is renewed |
| 09:40 | /api | an Agent of Harbor Lettings | Lease.create | done |
| 10:02 | /admin | a member of the leaseclock.com team | Lease.terminate on lease_7 | pending, waiting on an Approval |
The feed filters by App, Customer, Persona, Verb and status. Waiting Approvals are answered from the feed, through the same Verbs as the App.
Refusals group by reason. Fourteen refused Lease.renew calls on leases already renewed point at a screen that still offers Renew there. That gap is a screen to fix, not a rule.
Analytics: Metrics from Events
The analytics part shows Metrics, each computed from Events and never typed in. A Startup reads them per App, per Persona and per Offer.
| Metric | Computed from | Sample value for leaseclock.com |
|---|---|---|
| Time to value | first sign-in to the first Lease.created, per Persona and Offer | 6 minutes for manager |
| Activation | Customers who reach the activation Event of their Flow | 41 of 58 trial Customers |
| Renewals recorded | Lease.renewed Events per week | 212 |
| Refusal rate | refused Actions over all Actions, per Verb | Lease.renew: 6% |
| Seats in use | seats taken over seats sold, per Offer | 74 of 90 |
A Metric that moves names the Events behind it. A drop in activation opens the Flow step where Customers stall.
Admin across Apps
The admin part opens each App's Admin as the owner, from one sign-in. Every button there runs its Verb through the API, the same as in the App.
By default a Startup sees each Customer in aggregate: counts, usage, refusals and seats, never the records themselves. To see a Customer's screens, a person chooses View as, states a reason and gets a session of 30 minutes.
Each View as session leaves an entry in the Customer's own audit list at /dashboard. The entry names the person, the reason and the time, so the Customer sees every look.
What the Customer sees
A Customer of leaseclock.com sees none of SaaS.Studio. It sees what operations change: a refusal that names its reason, a screen that stops offering a Verb that refuses, and every View as entry.
Each Interface the Startup publishes carries its uptime and latency objectives, as Headless SaaS states. The Startup's status page reports them per Interface, in its own name.