MiniBytez
Demo LabContact us
Work

Four operations, changed and still running.

Case studies, shown through what we can discuss publicly: the situation each organisation was in, the architecture we built, how it was governed into operation, and what changed as a result. Client names, interfaces and commercial figures stay confidential, and no figure appears here that we cannot evidence.

Discuss your operationWhat the work proves
Delivered systems
Four
Clients, all confidential
Three
Systems for one flagship operator
Two
  • Sector delivery

    Records, billing and entitlement platform

    • Billing
    • Entitlement
    • One record
    • Staff console
    • Reporting
  • Sector delivery

    Access hardware integration

    • Readers
    • Turnstiles
    • Terminals
    Per-vendor adaptersLive entitlement
  • Delivered system

    Integration and reporting layer

    • Finance
    • Operations
    • Marketing
    One customer identityAgreed metrics
  • Delivered system

    Multi-channel intake and messaging

    • WhatsApp
    • Web
    • Phone
    • Social
    One queueA named owner
System diagrams of four delivered systems, abstracted. Client names and interfaces are confidential.
Flagship delivery

One operator, engineered from the record to the door.

  • Sector delivery
  • Fitness & Wellness
  • Client confidential

Two systems delivered for the same multi-site fitness and wellness operator. The platform owns the member, the money and the rules; the access integration enforces those rules at the door on each site, whichever vendor's hardware is installed.

System diagramOne operating environment

    1. People and surfaces

      • Member apps and portals
      • Front-desk staff console
      • Management reporting

  2. Platform

    1. Core

      • Member record and lifecycle
      • Billing and collections
      • Entitlement serviceShared

    2. Integration

      • Payment providerConnected
      • Event-driven updates
      • Audit trail and role permissions

  3. Access integration

    1. Decision

      • Entitlement API at the doorShared
      • One interface, per-vendor adapters
      • Card, QR, mobile and terminal credentials

    2. Sites

      • Readers and turnstiles, several vendorsConnected
      • Device monitoring and alerts
      • Entry events into reporting

Connected: an existing or third-party system we integrated withShared: where the two systems meetDrawn from the two public write-ups. No hostnames, endpoints or client detail.

  • Sector delivery
  • Client confidential

A single platform for members, payments and access

The problem
Member data, billing, attendance and door access lived in four systems that regularly disagreed with each other.
The system
  • One member record
  • Billing and collections
  • Entitlement service
  • Staff console
  • Management reporting
What it connects
The payment provider, member apps and portals, the front desk, management reporting and the door hardware, all reading one member record.
What MiniBytez owned
The data model, billing and collections logic, the entitlement service, the staff console and reporting, then keeping it running.
What this proves
Operational platform engineering: one authoritative record, money, rules and real-time decisions, with an audit trail.
Read the system in full
  • Sector delivery
  • Client confidential

Access hardware driven by live business status

The problem
Several sites, more than one hardware vendor, and entry lists that were uploaded by hand.
The system
  • Live entitlement checks
  • One interface, many vendors
  • Central credentials
  • Entry data
  • Device monitoring
What it connects
Access hardware from more than one vendor across several sites, the member record, and attendance reporting.
What MiniBytez owned
The entitlement API, the vendor adapters, credential issue and revocation, device authentication and monitoring.
What this proves
Identity and access, physical systems driven by business data, vendor-neutral integration and device security.
Read the system in full
Demo Lab equivalent

The operator's own interfaces are confidential. Threshold and Perimeter are MiniBytez demonstrations of the same capabilities, with invented data.

Open the Demo Lab
Detail from Threshold, a MiniBytez demonstration with invented data: failed payments become work, and block the door.
Threshold Failed payments become work, and block the door.
Detail from Perimeter, a MiniBytez demonstration with invented data: every entry decision, with its reason.
Perimeter Every entry decision, with its reason.
Selected systems

Two more operations, the same engineering standard.

Each delivered for a different client, with the sector withheld. Shown as the system we built, because the interface belongs to the client.

System diagramIntegration and reporting layer

    1. Existing systems, kept

      • FinanceConnected
      • OperationsConnected
      • MarketingConnected

    2. Integration layer

      • Incremental, re-runnable pipelines
      • Translation and synchronisation
      • Matching and merge: one customer identity

    3. Reporting store

      • Metrics defined once
      • Data quality tests
      • Row and metric level access control

    4. Outputs

      • Leadership dashboards with drill-through
      • Team operational boards
      • Threshold and anomaly alerts

Connected: an existing or third-party system we integrated with

  • Delivered system
  • Client confidential
  • Sector withheld

Systems that finally agree, and numbers leadership can use

The problem
Several established systems each held part of the truth, and the monthly pack was assembled by hand.
The system
  • Integration layer
  • One customer identity
  • Agreed definitions
  • Dashboards
  • Alerts
What it connects
Finance, operations and marketing systems that stayed in place, into one reporting store.
What MiniBytez owned
The integration layer, identity matching, metric definitions, data quality tests, dashboards and alerting.
What this proves
Integration without replacement, identity resolution, governed data and executive reporting.
Read the system in full
System diagramMulti-channel intake and messaging

    1. Channels

      • WhatsApp Business PlatformConnected
      • Web forms
      • Phone
      • Social

    2. Intake

      • Signature-verified webhooks
      • One ingestion API, per-channel adapters
      • Duplicate detection

    3. Work

      • Queue with retry and rate limits
      • Routing by product, language and availability
      • Shared inbox with owners and notes

    4. Follow-through

      • Automatic reply and follow-up
      • Consent and opt-out in the data layer
      • Attribution to pipeline and revenue
      • Advertising platformsConnected

Connected: an existing or third-party system we integrated with

  • Delivered system
  • Client confidential
  • Sector withheld

Every enquiry answered on the channel the customer chose

The problem
Enquiries arrived by WhatsApp, web form, phone and social, and were handled from personal devices.
The system
  • Official WhatsApp integration
  • Shared inbox
  • One queue for every channel
  • Immediate acknowledgement
  • Attribution
What it connects
The WhatsApp Business Platform, web forms, phone and social channels, the customer record and the advertising platforms.
What MiniBytez owned
The platform integration, the ingestion API, routing, the shared inbox, automation, consent handling and attribution.
What this proves
Event-driven messaging at volume, routing, workflow automation, consent and attribution.
Read the system in full
  • Internal platform
  • Live system

The Demo Lab

Seven working applications we designed, built and run at www.minibytez.com/demo: operations, executive reporting, messaging, CRM, sales, access control and subscriptions. Every dataset is invented. It is where our interface and product engineering can be shown in full, because client work cannot.

Open the Demo Lab
  • www.minibytez.com/demo/operations
    The Deck demonstration showing an operations queue of work orders with SLA countdowns and a triage panel.
  • www.minibytez.com/demo/crm
    The MiniBytez CRM demonstration showing a salesperson's home screen: pipeline figures, a work queue with AI recommendations waiting for approval, and the day's appointments.
  • www.minibytez.com/demo/sales
    The Momentum demonstration showing a full-width sales pipeline board with deal cards grouped by stage.
What the work proves

Read across the systems, not by client.

Four systems, nine capabilities. A mark means the system's public write-up describes that capability; an empty cell means only that it does not.

Where the same capability applies
Delivered systemApplicationsIntegration and APIsData and reportingAutomationIdentity and accessSecurityConnected devicesMessagingMonitoring
Records, billing and entitlement platformFlagshipOne authoritative record, money, rules and real-time decisions.6 of 9 capabilitiesApplicationsIntegration and APIsData and reportingAutomationIdentity and accessSecurityConnected devicesMessagingMonitoring
Access hardware integrationFlagshipPhysical systems driven by business data, across vendors.7 of 9 capabilitiesApplicationsIntegration and APIsData and reportingAutomationIdentity and accessSecurityConnected devicesMessagingMonitoring
Integration and reporting layerSystems that cannot be replaced, made to agree.7 of 9 capabilitiesApplicationsIntegration and APIsData and reportingAutomationIdentity and accessSecurityConnected devicesMessagingMonitoring
Multi-channel intake and messagingEvery channel into one queue, owned and attributed.6 of 9 capabilitiesApplicationsIntegration and APIsData and reportingAutomationIdentity and accessSecurityConnected devicesMessagingMonitoring
Delivery depth

Most of the work sits below the interface.

Each layer shows a real decision from the delivered systems and names the one it came from. Where no public write-up covers a layer, the method that applies to every engagement is shown instead.

See how we build

The interface: what a screenshot or a demonstration shows

  1. Discovery

    Time in the operation before designing anything: how the work flows, where it stalls, what data exists.

    MethodEvery engagement

  2. Architecture

    A translation and synchronisation layer between existing systems, so each keeps its own model.

    Delivered systemIntegration and reporting layer

  3. Engineering

    Scheduled jobs written to run safely more than once, and event-driven updates instead of batch delay.

    Sector deliveryRecords, billing and entitlement platform

  4. Integration

    One internal interface with per-vendor adapters, so replacing hardware leaves the business logic alone.

    Sector deliveryAccess hardware integration

  5. Security

    Signature-verified webhooks, and consent and opt-out enforced in the data layer.

    Delivered systemMulti-channel intake and messaging

  6. Testing

    Data quality tests on freshness and completeness, alerting when they fail.

    Delivered systemIntegration and reporting layer

  7. Go-live

    Migration, training and a controlled go-live, with a rehearsed way back if anything goes wrong.

    MethodEvery engagement

  8. Operations

    Signed, short-lived tokens cached locally so a network interruption degrades safely, and monitoring on every device.

    Sector deliveryAccess hardware integration

Start with the problem

Your business is not on this page.

It never is. Tell us what breaks, what it costs and what you have already tried. That is a more useful conversation than any case study.

Discuss your project

Named references are available under NDA.

Tell us what your business is trying to do.

The first conversation is about your operation, not our services. If we are not the right fit, we will say so.

A few sentences is enough. Please do not include passwords, card details or personal data about your customers.

By sending this enquiry you agree to us handling your details as described in our Privacy Policy.