Armakuni Contact us
← All case studies

A substitute teacher worked the day.
Getting paid ran through three separate systems.

A U.S. K–12 staffing provider serving more than 900 school districts ran payroll for over 100,000 educators across three platforms built on different technology, and slowed down every school morning. We connected payroll and invoicing across the three, put every application on one route from code to production, and added security checks before and during runtime.

Before

A substitute's day went through three separate systems.

The platforms slowed down in the school-morning rush.

After
40%less manual payroll processing
30%lower cloud costs
5×faster deployment cycles

As the company reported.

A substitute's day went through three separate systems

The company places substitute teachers and support staff in K–12 schools across the U.S. It runs three platforms: internal staffing, virtual instruction (from a company it acquired) and invoicing, each on a different technology stack. Payroll for more than 100,000 educators moved between them by hand, which meant repeated data entry, delays and difficulty tracking what virtual teachers were owed, especially during the peak hiring season.

The platforms slowed down in the school-morning rush

School hours, and mornings in particular, brought the heaviest demand, and the platforms slowed down exactly then, disrupting instruction scheduling and administration. Some resources were publicly accessible and security practices varied between platforms, a real risk with educator and student data under strict education-data rules.

The three products connected at payroll and invoicing

We left each product doing its own job and connected them where the work crosses from one to another, at payroll and invoicing. Every application then got the same route to production, with the same scaling and security checks.

How we built it

4 decisions, in the order we made them. Each one says what we did and why, with what it did drawn beside it.

  1. Payroll and invoicing as one workflow
  2. One route from code to production
  3. Security checks at every stage
  4. When the timesheet system kept restarting

Payroll and invoicing as one workflow

Built withLambda
A substitute's day, entered oncePayrollInvoicing
The engineering

We used Lambda to orchestrate payroll and invoicing across the staffing and virtual-instruction products, integrated with the existing payroll tools. Each product keeps its role, and the shared workflow handles the data staff used to enter twice.

Why: replacing three platforms would have taken years, and connecting them where the money moves took the pain away now.

One route from code to production

Built withGitLabTerraformCodePipelineECSFargateCloudWatch
Every changeGitLab pipelineTerraformECS on FargateCloudWatch alarms

“I am pleased to recommend Armakuni for their exceptional technical expertise and collaborative approach. … Armakuni's technical proficiency was vital to the success of our project. They provided clear, actionable solutions that helped us overcome challenges and meet our goals. … Thanks to Armakuni's expertise and support, we've achieved significant improvements in efficiency and performance.”

CIO, an education staffing company
The engineering
  • GitLab pipelines and Terraform set up consistent build, deployment and provisioning paths for every application. We recommended GitLab pipelines over AWS CodePipeline for their flexibility and how well they integrate with the other tools in use.
  • Dockerized services run on ECS, with Fargate for container execution and scaling, so capacity rises with the school-morning peak and falls after it.
  • CloudWatch dashboards and alarms expose failures, latency and resource use across environments.
  • Right-sizing cut unused capacity: Fargate Spot for non-production workloads, reserved RDS and EC2 capacity or Savings Plans for the steady part, lower data-transfer costs, and unused S3 buckets and NAT gateway charges removed.

Security checks at every stage

Built withSonarQubeSnykCrowdStrikeSecurity HubKMSRDS
Every appIn the buildIn the pipelineIn production security checks at every stage
The engineering

Security runs at three levels: SonarQube and Snyk scan code and dependencies before runtime, continuous scanning covers the running environments, and CrowdStrike adds runtime protection on the hosts. IAM policies and infrastructure definitions standardize access and resource configuration, closing the publicly accessible resources. Security Hub and Config monitor continuously, VPC flow logs record network traffic, KMS encrypts RDS snapshots and S3, the virtual-instruction platform was planned behind WAF with ACM certificates and a private RDS, and IAM Identity Center was proposed in place of individual IAM users.

When the timesheet system kept restarting

Built withKeycloakRDSECS
More room firstThen the cause fixed
The engineering

During the work, the timesheet system's HRIS API and its Keycloak sign-in service restarted repeatedly under load, with optimistic-locking errors in the database behind them. The incident plan ran in order: contain it by scaling the RDS instance and the ECS task count, rate-limit the HRIS API so a burst couldn't take it down again, then reduce lock contention in the application code and add retries, so the fix sat at the cause instead of in a bigger server.

What we'd tell another CTO

1Connect platforms where the money moves before replacing them, and give every application the same route to production, because consistency is where the 5× came from. School mornings are known in advance, so scale for that peak.
2Scan at three stages, code, environment and runtime, and close public access first, since with education data exposure is the risk that matters most. When something does fail under load, contain it first and then fix it at the cause, as the timesheet incident showed.

How a substitute's day now becomes a paycheck

  1. A substitute teaches a virtual class. The virtual-instruction platform records it.
  2. The staffing platform records the placement. Before, someone re-entered it by hand.
  3. Lambda brings the two together and calculates the pay.
  4. The payroll tools receive it through the integration, and the invoicing platform bills the district.
  5. The morning rush hits. Fargate scales the busy services, and CloudWatch shows it happening.
  6. A fix ships the same day through GitLab and Terraform, scanned by SonarQube and Snyk before it runs.

What else changed

As the company reported.

  • Consistent scaling at school-morning peaks, on ECS and Fargate.
  • Security checks before and during runtime, and standardized access.

What comes next

More of the work that crosses the three platforms brought into shared workflows, with the same pipelines and checks. The proposed data flow would replace manual inputs with API Gateway and Lambda, bring files in through DataSync or Transfer Family, replicate the source systems continuously with DMS, and replace the SSIS jobs with Glue, EMR and Step Functions, feeding an S3 data lake with Redshift, Athena and QuickSight on top.

How we'd do it today

This project came before our current offers. Here's how we'd approach the same work now.

This engagement already touched three of the four parts we now run as one service, and today AK Run, our AI-native managed service, would take on all of them together. In production, the three platforms on ECS and Fargate would be watched through the school-morning peak by what teachers and districts actually feel, with AI agents taking the first look at every alert and drafting the fix for a named engineer to confirm. In the applications, a payroll or timesheet bug gets fixed in the code, with a test, through the company's own GitLab pipeline. On security, SonarQube, Snyk and CrowdStrike findings, patches and certificates are dealt with before they turn urgent, and each finding has an owner until a tested fix is live. For the companies we run, the median AWS bill falls 40% in the first quarter.

On AK AI Factory, an AI agent could match teachers to openings and flag payroll exceptions, with its own identity, only the tools it needs and Cedar policies checked outside the model on every call, and a person approving every payment change. Once live, it would join the same service as its fourth part, on one register, with every model call through Agent ControlPlane's gate.

Have a problem like this one?

A free workshop: a few hours with the architects who'd do the work, on your own systems. No cost.

Book a free workshop