Zappl. DARE Technology · reporting and compliance for the Apple estates they manage
An Apple-focused managed service provider knew the state of every machine it looked after and had no way to show a customer any of it. We built the reporting layer over that data, and the compliance model behind the figure their customers now read.
Two portals 14-day eligibility window Retained, scope expanding
Where DARE were.
DARE Technology manage Apple estates for their clients, on open-source tooling they had built around Munki with their own command-line agent distributing packages. The tooling did its job on the machines themselves and stopped there, because the agent wrote its output on the device and nothing stood between that output and a customer who wanted to know whether their laptops were patched.
OpenKit built Zappl, the reporting and compliance layer over the data that agent was already producing, and the first thing DARE could put in front of a customer. Two portals shipped, one for DARE’s customers and one for their own engineers, and the relationship has run on since through a maintenance agreement and a further roadmap of work.
- 01
A customer portal with device and application views, dashboards, alerts and scheduled PDF reporting by email.
- 02
A management portal where DARE run every client, generate per-client tokens, and step into a customer’s own view to fix a problem.
- 03
A compliance model worked out with DARE, so the figure a customer sees reflects how their estate is actually being run.
What DARE needed.
Every conversation with a prospective client ended in the same place. How many of our machines are patched? Which ones are behind? Can we have that monthly? The honest answer was that the information existed on each device and nowhere else, so the brief went wider than a dashboard and started with what had to be true before any dashboard would mean anything:
- 01
A customer has to be able to see their own estate, without an engineer in the middle.
- 02
The compliance figure has to mean something, or nobody will act on it.
- 03
DARE’s engineers need one place to run every client, or the operational cost eats the margin.
How compliance is measured.
The first thing we worked out with DARE was the maths behind the figure. Pass-or-fail compliance treats a machine with one application a version behind exactly like a machine nobody has touched since spring, and an estate scored that way tells its owner nothing they can act on.
Pass-or-fail scoring
One out-of-date application anywhere on a machine and the whole machine counts as non-compliant. Nothing else about its state matters.
A device three months out of contact scores exactly the same as a device that finished updating this morning.
Every estate reads as broken, including the ones being managed well, so the number stops being something anyone acts on.
Averaged and eligible scoring
Compliance averaged across a device’s applications, so a machine most of the way there reads as most of the way there.
An eligibility layer on top: a device counts towards the measure only if it completed a successful full update inside the window.
A Last Compliant Date written by the agent on every run, with rules for exactly when it moves. It updates when a user lets a prompted application close, and it does not when they defer.
The eligibility window is fourteen days, specified with the client, written into the agent and applied at both device and application level.
The two portals.
One record a support engineer can work from
Serial number, disk space, FileVault status, the full application list with versions and install paths, and the agent log with automatic purging. The engineer stops asking the customer to read things off their screen.
Every figure links to the devices behind it
Application counts and compliance figures are clickable throughout, filtering straight to the devices they describe. The estate view answers "which ones?" without anyone exporting a spreadsheet to find out.
The client-management layer
DARE’s engineers create a client, generate that client’s bearer token, and keep licence keys and expiry dates against the record. When a customer hits a problem, an engineer can step into that customer’s own view of Zappl, see exactly what they are seeing, and fix it from there.
What changed for DARE.
customer organisations on the platform, each able to see their own estate without an engineer in the middle.
a month against the tooling their customers were paying for before, in many cases.
portals reading one set of numbers, one for DARE’s customers and one for their own engineers.
Both figures are DARE-reported: the saving their customers make against their previous tooling, and the customer count their director gives.
What is contracted next.
The first release shipped, a maintenance agreement followed, and the plan now runs further than either, with the parts that are not yet sized carried as estimates.
- 01
Single sign-on
SAML into Microsoft Entra ID, Okta and Google Workspace, with user provisioning and role mapping, so a customer’s IT team stops managing a separate set of credentials.
- 02
A public API
Authenticated, rate-limited and versioned, with live endpoints such as application-usage statistics. It is the foundation the remote-logs and app-control work sits on rather than a feature on its own.
- 03
Configuration served to the agent
Settings held in the portal and delivered to devices through the API, plus allowed and disallowed application lists, moving policy out of the engineer’s head and into the product.
- 04
Bulk management and remote logs
Multi-select device clean-up, filtering and grouping by last check-in or pending updates, and the ability to pull a full log from a device against its record.
The build
- Customer portal
- Client management portal
- Compliance calculation model
- Per-client bearer tokens
- Scheduled PDF reporting
- React + TypeScript
OpenKit certifications
- ISO 27001
- ISO 9001, UKAS-accredited
- Cyber Essentials
Controls on this project
- UK GDPR
- UK data residency
ISO 27001, ISO 9001 and Cyber Essentials are OpenKit certifications, and we operate to UK GDPR. The controls listed are the ones set on this project.
OpenKit transformed our business requirements into Zappl, an elegant web application that provides secure Apple patch management for our customers. Their process began with thorough discovery sessions, demonstrating a clear understanding of our business objectives and user needs. The intuitive interface and streamlined workflows have reduced our staff admin workload and increased user adoption, with 100+ customers already onboarded. Throughout the partnership, OpenKit consistently demonstrated their commitment to delivering business value, from initial planning through to final implementation.
OpenKit delivered us a high-performance React application for Apple patch management, featuring large data ingestion and processing with enterprise-grade security. Their technical expertise was evident in every aspect, from an optimised frontend architecture to a robust backend with comprehensive API integration. The resulting application excels in both performance and reliability, with comprehensive monitoring and an automated deployment pipeline ensuring system stability.
More of the work.
Find your first workflow.
We start with a conversation, audit where AI actually pays back, and build the first automation into how your team already works. We reply within one working day.
Start the conversation Embedded AI Lead