Service-isolated, not a feature inside the PoS
The architectural decision that defined the engagement was the choice to build STARR as a service that integrated with the existing CPOS PoS surface, rather than as a feature inside it. Two reasons.
A real-time, compliance-grade sales tracking system for Ontario Government reporting — built for a company most agencies would not have staffed for the work. Service-isolated, PCI-DSS-aligned, integrated with the PoS systems already in the field. Live in production.
CPOS sells point-of-sale infrastructure. A growing share of their customers operate in categories where Ontario Government reporting is not optional — sales need to be tracked in real time, reconciled against regulated thresholds, and reported in a format the government accepts. Getting it wrong is not a UX problem. It is a license problem.
CPOS had two paths. Build the compliance reporting layer themselves, with a small in-house engineering team that did not have spare capacity for a multi-quarter compliance system. Or find a partner who could own the entire reporting workstream — the integration into the PoS data, the real-time pipeline, the database design that would survive an audit, and the deployment architecture that would meet PCI-DSS expectations.
The first path put the rest of CPOS's product roadmap on hold. The second path was the one they could afford.
Arc10 took the entire STARR workstream — the real-time sales tracking and reporting system — end to end. Architecture, build, deployment, and the integration into the PoS surface CPOS already shipped. Senior engineers, joined CPOS's standups, owned the outcome of "STARR ships, on time, audit-ready."
The architectural decision that defined the engagement was the choice to build STARR as a service that integrated with the existing CPOS PoS surface, rather than as a feature inside it. Two reasons.
Ontario's reporting rules evolve. Isolating STARR in its own service meant that reporting changes did not require redeploying the entire PoS product — the surface customers already trusted in production stayed where it was while the compliance layer absorbed the regulatory motion.
PCI-DSS-aligned design, append-only audit logs, restricted access patterns — these belong tightly scoped to the system that handles regulated data, not diluted across the broader PoS product. Service isolation is what made that scoping enforceable, not just aspirational.
The decision was not a preference. It was the architectural choice that made the rest of the engagement deliverable on a small team's bandwidth without slowing the broader product roadmap.
Senior engineers across the Java / Spring Boot backend, the PostgreSQL data model, the Kubernetes deployment surface, and the PoS-side integration. Arc10 owned STARR end to end while CPOS's in-house team continued the broader product roadmap in parallel.
Sales events flow from the PoS layer into STARR continuously. The pipeline is built on Java and Spring Boot, with PostgreSQL as the system of record and S3 for long-retention storage of reporting artifacts. The pipeline is idempotent — the same sale event arriving twice does not produce two reported transactions — which is the kind of detail that matters when an auditor traces an entry.
PCI-DSS-aligned design choices throughout. Cardholder data is not stored in STARR; PoS-side tokenization keeps it out. Audit logs are append-only and separately accessible, so the reporting system itself cannot quietly be the system that erases its own history. Kubernetes deployments segment the workloads that handle sensitive data from the workloads that don't.
Reporting outputs in the format Ontario Government systems accept, generated on the cadence the regulation requires, with reconciliation against the source pipeline so the report and the database tell the same story. Edge cases — refunds, voids, partial transactions — were specified, implemented, and tested against representative data.
“Arc10 brought technical expertise, dedication, and customer service that we hadn't seen from other partners. The work was delivered well, and the team understood what compliance-grade work actually requires.”
Compliance-grade work, shipped on a small team's bandwidth — without slowing the rest of CPOS's roadmap.
Building a compliance-grade system on a small team? The senior engineer who shipped STARR will take the call.