Sign-in with roles
Three demo accounts — administrator, manager and operator. Each sees a different menu and different permissions, because access control is the first question a government buyer asks.
One hundred applications you can sign into
Not screenshots and not a slide deck — one hundred working demonstration applications across enterprise operations, retail, healthcare, finance, logistics, communication, public safety, industrial IoT, smart city and media. Each has its own sign-in, sidebar, dashboards, records, forms and reports. Open one and use it.
A specification tells you what a system should do. A demo tells you what it feels like when it is running at 3am with four hundred sensors reporting. These are the patterns we build from — the same ones behind our fuel monitoring, e-lettering and forensic case management deployments — reduced to something you can open in ten seconds.
0DEMO APPLICATIONS
0INDUSTRY DOMAINS
0WORKING SCREENS
0ROLES IN EVERY APP
The catalogue
One hundred demonstration applications
Filter by domain or search by capability. Every card opens a separate application with its own login. Sign in with the demo accounts shown on each login screen — administrator, manager and operator each see a different menu.
100 applications · 10 domains
No application matches that search. Try a broader term, or tell us what you need — the list is not the limit.
About these applications
Each demo is a self-contained application running entirely in your browser on synthetic data. Sign-in is simulated, there is no server behind it, nothing you type is transmitted or stored, and a page refresh restores the seed data. They exist to show the interaction model, the screens and the role structure — the production build is engineered to your workflow, your integrations and your compliance regime. Our delivered work is on the project register.
Inside every application
The same five modules, built for each domain
Every demo application has the structure a departmental system actually needs. The modules are the same shape throughout; the data, terminology and workflow are specific to the solution.
Dashboard
Four live KPIs with period comparison, a trend chart, a recent-activity stream and a snapshot of the most recent records.
Records register
A working data table — search, status filter, column sorting, pagination, a detail drawer on any row, and edit and delete actions.
Create form
Fields typed to the data, required-field validation and a save that actually writes the record into the table in front of you.
Reports
Date-range and grouping selectors, summary cards, a comparison chart and a category breakdown, with export actions stubbed.
Configuration
Notification rules, the operational thresholds that matter to that domain, and access-control settings — hidden from the operator role.
Ready for their own subdomains
Each application is a self-contained folder with no references outside itself, so it runs at
/demos/<name>/ today and at <name>.cyberedgetechs.com as soon as a DNS record and virtual host point there — for example hrm.cyberedgetechs.com or pharmacy.cyberedgetechs.com. No rebuild is needed. Setup instructions are in build/DEPLOY.md.
Engineering
What “real-time” actually costs
Live systems fail in ways batch systems never do. A dashboard that refreshes every five minutes forgives a lost message; an alarm panel does not. We design for the failure first.
- Ingestion sized for peak, not average — burst load is the normal case
- At-least-once delivery with idempotent handlers, so a replay is harmless
- Back-pressure and shedding rules agreed before launch, not after the outage
- Clock discipline — event time and processing time are never assumed equal
- Degraded modes that stay useful when a sensor, link or upstream goes dark
- Offline capture on mobile, with conflict resolution on reconnect
- Retention and archive policy set against the audit requirement, not disk cost
- Observability built in from day one — you cannot fix what you cannot see
5
Modules in every demo application
Patterns
The shapes behind the hundred
Nearly every real-time system reduces to a handful of interaction patterns. Recognising which one you need is most of the design work and it is why a build that looks unfamiliar is rarely as novel as it first appears.
Telemetry & thresholds
A value arrives continuously and must be judged against limits. Gauges, alarm panels and excursion records — cold chain, BMS, tele-ICU, plant control.
Event streams
Discrete events append to an ordered log that people read as it grows. RFID reads, badge swipes, bids, transactions, lab results.
Position & movement
Entities move through space and must be tracked, predicted and geo-fenced. Fleets, transit, drones, herds, warehouse robots, patrols.
Stage progression
Work items advance through defined states with rules at each gate. Procurement, fulfilment, loan approval, triage, treatment.
Matching
Two populations must be paired under constraints and scored fairly. Organ allocation, freight capacity, recommendations, dispatch.
Aggregation & ranking
Many writes collapse into a sorted view queried constantly. Leaderboards, poll results, blood stock, portfolio allocation.
Queue & service
Demand exceeds capacity and must be sequenced visibly and fairly. Token systems, OPD routing, contact centres, wait prediction.
Shared state
Several people or devices edit one thing at once without losing work. Co-editing, presence, multiplayer, collaborative sessions.
Grid & estate
A large population of identical assets reports individual health. ATM networks, street lighting, shelf facings, inverters, detectors.
Technology
What we build these on
Chosen per engagement against your existing estate, hosting constraints and the skills of the team who will hold the system after handover. We do not impose a stack you cannot maintain.
Ingestion & transport
MQTT and Modbus for devices, Kafka and RabbitMQ for queues, WebSocket and SSE to the browser, REST and gRPC between services.
Processing
Stream processors for windowed aggregation, rules engines for thresholds and policy, and Python model serving where inference is needed.
Storage
PostgreSQL and SQL Server for transactional state, time-series stores for telemetry, Redis for hot state, object storage for evidence.
Delivery
Web, Android and iOS clients with offline capture, plus signage, LED boards and SMS or push channels where the user is not at a desk.
On-premisePrivate cloudPublic cloudHybridAir-gapped
Deployment model is a decision, not a default. Law-enforcement and forensic workloads we have delivered run on-premise or air-gapped; commercial platforms usually do not need to.
How it starts
From a demo to a delivered system
Picking a card is the easy part. This is what happens next.
1 · Discovery
We sit with the people who will use it and watch the current process — including the workarounds nobody documents. Two to five days.
2 · Working prototype
A narrow slice of the real system on your data shape, so scope arguments happen against something visible rather than a document.
3 · Build & integrate
Milestone delivery with dated acceptance gates, weekly written status and integration to the systems you already run.
4 · Handover & support
Source code, documentation, role-based training, warranty period and an optional maintenance contract for the life of the system.
Questions
What clients ask first
Are these demos your delivered systems?
No, and we would not claim otherwise. The demos are illustrative prototypes running on synthetic data in your browser. Our delivered work — 38 contracted engagements against signed work orders — is listed in full on the project register, with dates and client departments.
Can you build something not on this list?
Yes. The hundred entries are patterns we have implementation experience with, not a menu limit. Most enquiries turn out to be a variation on one of the nine patterns above, and the ones that are genuinely new get an honest answer about what we do and do not know.
How long does a real build take?
A single-domain system with one integration typically runs eight to sixteen weeks from discovery to UAT. Multi-department platforms with legacy data migration run longer, and we will say so at proposal stage rather than at month four.
Who owns the source code?
You do, on final payment, together with the technical documentation and database schema. We do not hold client systems hostage through undisclosed dependencies, and we will hand over to another vendor cleanly if you ever need us to.
Can it run without internet, or on our own servers?
Yes. We have delivered on-premise and air-gapped systems for law-enforcement forensic work, and offline-first mobile capture for field teams operating outside coverage. Deployment model is decided against your security requirement, not our convenience.
How is security handled?
Role-based access, complete audit trail and encrypted transport are baseline, not extras. As an ISO 27001:2022 certified organisation with an in-house VAPT practice, we security-test our own builds before they reach your acceptance testing — see cybersecurity services.
Tell us which one you opened
Send the scope, or just the name of the demo that looked closest. You will get a named engineer, a written technical approach and an indicative timeline within one business day.