Builder is where the estate's internal tools get made: describe the app, review the plan it proposes, assemble from a governed component library — and watch publish risk and component debt before anyone ships.
The overview does not flatter the studio: 114 components carry high debt, 26 of them critical, and 30 pages sit above the publish-risk gate. A tool that shows you that is one you can run a real estate on.
builder.cedxsystems.com — live build
Runs on demo data — Northline ops studio is the demo workspace, not a customer.
48 apps in the studio14 live · 24 in draft or staging
320 pages tracked82 live · 79 on public routes
45 studio health26 components above critical debt
What it is
Three things low-code usually hides — Builder prints.
Describe the app, review the plan first
Prompt entry is the default creation path, with four seeded examples from a partner intake form to a field-ops console on a map. The output is not an app appearing by magic — it is a proposed plan: pages, components, bindings and permissions, as a checklist where every item is reviewable before materializing.
Draft plan proposes pages · components · bindings · permissions
4 seeded examples, one click to fill
Generated apps land in the Apps list, not in limbo
builder — screen-2
Every app carries a health score
The Apps table lists type, status, pages, components, health and sessions for all 48 — CRM desk shell at 76 health and 22,100 sessions, the vendor desk flagged at 34. Filter chips cut the list by Internal, Portal, Marketing or Ops tool, and the view exports to CSV.
Health, sessions and component count per app
Live, staging, draft and archived states
CSV of the view you were actually looking at
builder — screen-3
Pages know their routes — and their speed
All 320 pages carry their route, owning app, component count, broken bindings, sessions and LCP. The Finance desk dashboard shows 2 broken bindings; the create page of the finance shell reads an LCP of 5.1 in red. Nothing about a page's cost to run is a surprise after publish.
Broken-binding count on every row
LCP per page, red when it hurts
Public routes filter for marketing and portal pages
builder — screen-4
Product tour
Four screens, captured from the running build.
Not a mockup and not a concept deck. This is what opens at /app/builder.
builder.cedxsystems.com
01 — Overview
A studio health check, not a welcome mat
48 apps, 320 pages, 320 library components, 230K sessions in 30 days — and then the uncomfortable cards: debt high 114 with 26 critical, publish risk 99. Alerts arrive root-caused: 26 components above critical debt, 30 pages above the publish-risk gate, 8 data sources in error, and a partner form whose LCP is 4.1 seconds.
Describe the app in plain words — “an intake form for partners with document upload and an approval queue” — and the plan lands as a checklist. The screen is honest about state: generated apps this session, zero, with the count living in Apps.
Prompt entry is the first creation path
Every plan item reviewable before materializing
Seeded examples span warehouse, partner, HR and field ops
03 — Apps
The estate of apps, sortable
1–25 of 48 apps with type, status, pages, components, health and sessions. Support macros runs 88 health on 14,200 sessions; the inventory glance runs 34. The gap between those two numbers is the roadmap, and it is on the screen.
Search, filters and saved views
Health column coloured, not hidden
1–25 of 48 with the count on the table
04 — Pages
Where publish risk comes from
320 pages with route, status, app, components, broken bindings, sessions and LCP. Event wizard's list page carries one broken binding; the finance shell's create page runs an LCP of 5.1. Publish risk on the overview is the roll-up of exactly this table.
113 drafts not live, 79 public routes
Sessions per page, 30-day window
Filter chips for public and authored pages
Who runs it
Three roles keep an app estate alive.
Roles, not references. We have no named customers yet, so nobody in these photographs is quoted, credited or claimed as one.
Operations builders
Own the apps nobody else's team will build: intake forms, approval queues, cockpit views. They work from the plan checklist, not from a blank canvas.
48 apps · 14 live
Component library owners
Watch the debt signals table the way a lender watches credit: layout-pro-185 at 95 gets refactored before it ships into a thirteenth app.
320 components · 26 critical
Data source owners
Keep the bases the apps bind to. When 8 data sources sit in error on the overview, this is the person whose afternoon changes.
8 data sources in error
The shape of it
What the demo studio actually looks like.
Every figure below is legible in the captures above. Nothing here is a projection of your estate — it is the state of the demo data.
48apps in the studio14 live · 24 draft or staging
320pages across the apps82 live · 79 public routes
114components with high debt26 critical
230Ksessions in 30 daysapp traffic, overview card
Highest component debt, scored on screendebt score · library view
layout-pro-18595
legacy-table-v193
auth-alt-15686
orphan-sidebar-v080
kpi-pro-7778
Studio health, with its inputs listedlive 14 of 48 · avg health 57
An app starts as a sentence in Generate app — the seeded examples run from warehouse stock alerts to a leave-request workflow with manager sign-off.
02
Plan
The plan lands as a checklist: pages, components, bindings, permissions. Every item is reviewable before anything materializes.
03
Compose
Pages assemble from the 320-component library, and the debt score travels with each component — layout-pro-185 warns at 95 before it ships into another app.
04
Publish
Publish risk is a gate with named causes — broken bindings, missing auth, slow LCP — and 30 pages currently sit above it, on screen.
One record
Apps bind to data the estate already keeps.
Builder is not a form tool with a database bolted on. Its data sources, events and publish pipeline are the estate's own.
Finding this out on the third call is worse for you than reading it here, and worse for us.
Builder is not generally available. What opens today is the live build running on demo data — Northline ops studio is the software's demo workspace, not a reference.
We have no named customers to show you, so this page shows none.
The Generate app capture shows the plan step. The demo workspace shows zero apps generated this session, and we are not claiming generation quality beyond what you can try yourself in the live build.
Session counts, LCP values and health scores are the demo workspace's own telemetry, not benchmarks of yours or anyone else's.
No audit or compliance certification has been issued for Builder. What we can evidence about hosting, encryption and access is on the security page.
Yes. Every screenshot is a capture of the running build and you can open the same build at /app/builder. It runs on demo data, which the workspace name — Northline ops studio — makes plain on every screen.
What does Generate app actually produce?
A plan, first: pages, components, bindings and permissions as a checklist where every item is reviewable before it materializes. The seeded examples — partner intake, inventory glance, leave requests, a field-ops console — show the shape of prompts it expects.
What is component debt?
A score per library component, visible in the debt signals table. layout-pro-185 tops the demo list at 95, and the overview counts 114 components above the high-debt line, 26 of them critical. The point is that reuse stops being free the moment drift goes unmeasured.
What is publish risk?
A gate with named causes, not a vibe. The overview's root-caused alerts list 30 pages above the publish-risk gate, with broken bindings, missing auth and slow LCP called out per page in the Pages table.
Is Builder audited or certified?
No certification has been issued. What we can evidence about hosting, encryption, tenant isolation and production access is written up on the security page.
The studio is running. Go and look at it.
Live build, demo data, no card. Then draft the plan for the internal tool your team is currently running in a spreadsheet.
