A customer portal takes a quarter to build.

A working portal for customers, partners and field teams.

Describe who the portal is for and what they need to see and do. STRAX builds the pages over the data your systems already hold. Sign-in, roles and row-level filters are switched on per site, and the same portal is published to the web and as a phone app.

Request a demo → All features →
A customer portal described, secured and published A gap is noted: customers phone for order status. A one-sentence description becomes a customer portal with an orders grid, invoice tiles and a ticket form, and the STRAX hub fills it with current orders. Six security switches are turned on (sign-in, MFA, roles, own rows only, audit trail, staging to production), the portal is published to the web and a phone, and the gap is marked closed. Gap · customers phone for order status Gap · closed — customers help themselves Customer portal: my orders, invoices, log a ticket Build Customer portal Open invoices2 BalanceR 1 240 My orders Order #20931In transitOut for delivery Order #20904Delivered Order #20877Delivered Live from the hub Log a ticket Subject What happened? Send STRAX hub Security · this portal OAuth / OIDC sign-in MFA Roles per site Own rows only Audit trail Staging → production Nothing here needs a developer. Customer portal #20931Out for delivery #20904Delivered Open invoices2 Log a ticket web · Android · iOS Described in a sentence, built by STRAX. Live from the hub, so every figure is current. Security is switched on per site. Published · production Described → live 38 min Customers help themselves, securely, on your own data.

Working the day you describe it

A portal starts as a sentence about who it is for and what they need to see and do. STRAX assembles it from building blocks over the data the business already has: grids, forms, detail panels, approvals, dashboards, calendars and kanban boards. There is nothing to develop before someone can use it, and changing it is another sentence.

  • Described in plain language and built from 28 building blocks over the hub's current data.
  • Templates for the common cases: customer, field-ops, partner and back-office portals.
  • Each person sees their own tasks and their own data, and nothing else on the screen.
Live Described, then built A sentence in · a working portal out
Working the day you describe it A plain-language description becomes a portal: grid, form, detail panel and kanban blocks assemble over the hub's current data, ready the same day. The description "A portal for our field technicians: their jobs, materials and sign-offs." assembling… Technician portal 28 building blocks · current hub data My jobs (grid)#1042 · Midrand · today 11:00#1046 · Benoni · today 14:30#1051 · Kempton · tomorrow Job detailmaterialsphotossign-off Complete job (form)writes straight back to the huband to the systems that own it Kanbanby status usable today changed by a conversation Say who it is for and what they do. A working portal the same day.
A portal starts as a sentence and is assembled from building blocks over data the business already has.

Security switched on per site

Every option a serious portal needs is already there and switched on per site: who may sign in and how, what each role may see and do, which rows a person may touch, what is logged, and a staging copy to try changes on before production sees them. None of it is licence-gated, and none of it needs a developer.

  • Sign-in with OAuth and OpenID Connect, or the portal's own accounts, with MFA.
  • Roles per site, and row-level filters so a customer sees only their own records.
  • Staging and production copies, versioned pushes and rollback, and an audit trail of every change.
  • Visitor analytics with a consent banner, and a dark mode the visitor can choose.
Live Security is a switch Already built · switched on per site
Security switched on per site The portal's security controls (sign-in, MFA, roles, row-level filters, audit trail, staging copy) switch on one after another. Portal security None of it is licence-gated or needs a developer. Sign-in: OAuth · OIDC or the portal's own accounts Multi-factor authentication one switch per site Roles per site what each role sees and does Row-level filters a customer sees only their records Audit trail every change on the record Staging copy try changes before production sees them A serious portal, secured All six controls on, with nothing to build. production-ready ✓ Every control a serious portal needs is already there. Switch each one on per site.
Sign-in, MFA, roles, row filters, audit and staging, each switched on per site.

The calls and spreadsheets that stop

Customers stop phoning for order status, technicians stop calling the office for job details, and partners stop emailing spreadsheets. Because the portal reads the same hub the systems write to, what people see in it is current, on the web or as a native app on their phone.

  • Self-service for customers, field teams and partners over data that is already correct.
  • The same portal as a web app or a native Android and iOS app.
  • Records created or edited in the portal flow back to the systems that own them.
Live The calls and spreadsheets that stop Self-service · web and native mobile
The gap the portal closes The status phone calls and emailed spreadsheets are crossed out; customers, technicians and partners answer themselves in the portal, on web or phone. “Where is my order?” customers phoning “What is on the job card?” technicians calling the office partner-stock-v7-final.xlsx partners emailing spreadsheets The portal that closes the gap Reads the same hub the systems write to Order #8841: out for installation, Thursdaythe customer sees it themselves Job card #1042: materials, address, historyon the technician's phone, as a native app Partner stock, current, with no spreadsheetedits flow back to the systems that own them what they see is current ✓ the same portal as a native app Android · iOS The status calls and spreadsheets stop. People answer themselves, on web or phone.
Customers, technicians and partners serve themselves over data that is already correct, on the web or as a native app.

Keep exploring

More in Build

Hand-offs and approvals that run on their own.

Approvals, follow-ups and cross-system updates run on their own, from a two-system relay to a nine-step process, with no middleware to write or maintain.

Workflow automation →

Reports read the same data the business runs on.

Reports and queries read the same hub the systems write to, so every figure is current, and AI writes the insight paragraphs from the report's own numbers.

Reports & queries →

Every process as it really runs, gaps included.

STRAX assembles each business process from what the systems record and what the people say, checks one against the other, and shows every gap on the diagram.

Business processes →

See it on your own systems.

A demo takes about an hour. Bring a process, a portal or a report you would like to see built on your own data.

Request a demo → Request a quote