Software partners do not all need the same architecture. The correct choice depends on product ownership, development capacity, speed to market, device-management needs and customer experience. For HCM, WFM and T&A software companies, the decision affects more than hardware. The endpoint becomes part of the partner’s own product experience, support model and long-term roadmap.
Three partners can use the same clock and need three different architectures.
Partner A already has a mature Android employee application and wants direct access to readers and device functions. Partner B wants to enter the physical-clock market quickly and prefers a prebuilt employee experience that exchanges data with its platform. Partner C has many customers and resellers and wants centralized device operations as much as application integration.
All three can be legitimate. The mistake is treating SDK, prebuilt app and cloud middleware as competing features instead of different ownership models.
SDK: maximum application ownership
A platform SDK can make sense when the partner wants to own the Android user experience and business logic on the clock. That choice also creates more development, testing and lifecycle responsibility.
Prebuilt application: faster enablement
A configurable application such as TimeTrack can reduce endpoint development while still allowing the partner to integrate time and labor data through supported APIs and workflows.
Cloud middleware: operational leverage
A middleware/device-management layer can add provisioning, connectivity, monitoring, updates and integration services when the partner does not want to build those capabilities itself.
Hybrid is often reasonable
A partner may use different approaches by market, product tier or customer segment. Architecture should be modular enough to evolve.
Every shortcut today creates an owner tomorrow
Using a prebuilt application can accelerate launch, but the partner accepts more of the provider’s interaction model. Building with an SDK creates more freedom, but the partner also owns more testing and release work. Middleware can remove device plumbing while adding another service boundary.
None of those tradeoffs is a problem if it is intentional. The architecture gets painful when teams discover after launch that they own a layer they never planned to operate.
Architecture determines who owns tomorrow’s change request.
An SDK gives application freedom but leaves more application testing and device behavior with the partner. A prebuilt application can accelerate launch but requires fit with the partner’s workflows. Middleware can reduce fleet burden but introduces another managed layer. Hybrid designs can be powerful when ownership is explicit.
The right question is not which option sounds most technically sophisticated. It is which boundary best matches the partner’s engineering capacity, branding goals, customer support model and speed-to-market requirement.
Options and when to use each approach
SDK-first
Partner builds the device experience and integrates directly with hardware capabilities.
Best for differentiated UX and strong embedded engineering teams.
Prebuilt application
Use TimeTrack or another supported app and integrate at the data/service layer.
Faster deployment and lower embedded engineering burden.
Cloud middleware
Keep device interaction mostly vendor-managed and integrate the partner platform to cloud/device services.
Good for centralized management and lower device complexity.
Hybrid
Use a prebuilt core with partner-specific extensions/integrations where supported.
Balances speed and differentiation; define upgrade ownership carefully.
A practical decision framework
- Pressure-test the choice against the long-term operating requirement: Pick the integration model by ownership: who will build the app, test device dependencies, manage releases, operate the fleet and support customers?
- Resolve this design question early: How much Android/device engineering do we want to own long term?
- Make support, exception and change ownership explicit before production.
Common design mistakes
- Choosing SDK for maximum control when the partner does not want long-term embedded support.
- Choosing a prebuilt app without validating required workflows.
- Treating cloud middleware and device management as afterthoughts.
Test the architecture with future changes, not only initial integration
- A new badge reader is introduced.
- The Android platform moves to a new major version.
- A customer requests a new labor workflow.
- A reseller needs access to only its own customer fleet.
- A device is offline during an application rollout and reconnects later.
Use architecture to control where complexity lives
- SDK-first fits when the partner wants to own the employee UI and has Android engineering capacity.
- A prebuilt application fits when speed to market matters and required workflows fit the supported experience.
- Cloud/device middleware fits when the partner wants centralized fleet operations and less endpoint-specific infrastructure.
- Hybrid models fit when product ownership is shared intentionally rather than accidentally.
The architecture is strongest when each layer has one clear owner. Avoid designs where both the partner and the device platform can independently change the same workflow or configuration without coordinated governance.
Questions leaders should ask
- Where does our software genuinely differentiate?
- How much Android/device engineering do we want to own long term?
- Who supports device incidents and software updates?
- Do we need customer-specific UX or mainly reliable data exchange?
- How will the architecture evolve across future hardware generations?
Choose the integration boundary that matches the product ownership you actually want.
ZKTeco WFM supports multiple software-partner architectures because partners do not all want the same boundary. Ultima can serve as the purpose-built endpoint underneath a partner-developed application; TimeTrack can provide a ready workforce interaction layer connected through APIs; and CirrusConnect can support centralized device connectivity and operations where that model fits.
The strategic advantage is avoiding a forced architecture. A software company can preserve the layers that differentiate its product while using ZKTeco WFM for specialized endpoint, device and manufacturing capabilities. The architecture should be selected during product strategy—not discovered during the first difficult customer implementation.
Key takeaway
SDK, prebuilt application and cloud middleware are not simply three integration features. They are three different answers to the question “who owns what?” Choose the model that aligns application control, fleet responsibility, support and speed to market—and verify how that ownership model behaves when devices, customers and requirements change.
SDK, Prebuilt App or Cloud Middleware?
Talk with ZKTeco WFM about the engineering ownership, speed-to-market and support tradeoffs behind each partner architecture.
Talk to an Expert