How a construction SaaS took releases off developers’ machines and cut critical cloud risks to zero
A construction project management SaaS owned by a Fortune 500 manufacturer moved four apps to company-controlled releases, rotated hundreds of exposed secrets, cut 30,000+ critical cloud findings to zero and kept 99.99% uptime.
The situation
The company builds construction project management software for enterprise customers, and it's owned by a Fortune 500 manufacturer. When its software is down or broken, work slows on real job sites.
How the software was built and run didn't match those stakes. There was no standard process. A one-person DevOps function was stretched across many projects, so in practice developers were running the show: building, releasing and handling credentials however each of them saw fit.
It showed up everywhere. The Windows desktop app was built by hand by one developer. The mobile app was built on a developer's own machine, outside the company's control. Keys were hardcoded in code and scattered across repository secrets and pipeline variables. Services were still running under roles tied to an administrator who had left. And nobody had a clear view of the misconfigurations piling up across the cloud.
Meanwhile, the main web application had to scale to serve 300 enterprise customers.
The constraint
- Four applications, four ways of working. A Windows desktop app, a multi-component web app, a serverless app and a mobile app, each built and released differently.
- Developer-dependent releases. Shipping relied on specific people and their machines.
- Hundreds of exposed secrets. Keys sat in code repositories where anyone with access could read them.
- 30,000+ critical cloud findings. Too many to fix one at a time without a plan.
- Leftover privileged access. Services ran on roles tied to a departed administrator, so his access couldn't be removed without first giving every service its own role.
- Enterprise expectations. A Fortune 500 owner and 300 enterprise customers expect measurable reliability and a clean security posture.
- A migration in motion. The web application had to move from Azure to AWS while customers kept using it.
What we did
- Brought order to how software shipsWe replaced developer-run releases with pipelines the company controls, one for each application, all built on the same principles: company infrastructure, repeatable, logged and secure.
- Windows desktop app: from hand-built executables to signed installersAutomated builds in a CI/CD pipeline, so any release can be produced on demand without a specific developer. MSI installers generated automatically for consistent installs on customer machines. Code signing, so customers and Windows can verify the software is genuine and hasn't been tampered with. Code obfuscation, protecting the company's intellectual property in the shipped application.
- Web app: automated, then migrated from Azure to AWSAzure DevOps pipelines to build and deploy each component. Ansible to configure servers and deploy the application the same way every time, with no hand-configured machines. Migration from Azure VMs to AWS to scale the application for 300 enterprise customers, with automated, repeatable deployments.
- Serverless app: infrastructure as code from day oneAWS Lambda and Amazon API Gateway for the application logic and its APIs. Terraform to define all of it as code, so every environment is reproducible and reviewable. Bitbucket Pipelines to test and deploy changes automatically.
- Mobile app: builds back under company controlFastlane builds, signs and packages the iOS and Android apps on company infrastructure, not a developer's own machine. Firebase for distributing builds and supporting the app. Traceable releases: what went in, when, and from which pipeline.
- Found and fixed exposed secretsGitleaks scanned the repositories and found hundreds of secrets, including keys and credentials committed in code. Every exposed credential rotated, so leaked keys stopped working. AWS Secrets Manager became the single source of truth. Applications now read secrets from one controlled place. Secret scanning stays on, so new secrets don't slip back into the code.
- Cleaned up the cloud with WizWiz scanned the AWS and Azure environments and surfaced more than 30,000 critical findings. Prioritized by risk and remediated, starting with exposed resources and over-broad permissions, until critical and high findings reached zero. Continuous scanning, so new issues are caught as soon as they appear and never pile up again.
- Closed the access gapsRetired the departed administrator's access. We gave each service its own dedicated role, moved every workload onto it, then confirmed his access was completely removed, with nothing broken in the process. Least-privilege access across both clouds: each person and service gets only what it needs. Datadog watching for unusual activity.
- Kept it running with SREDatadog for observability, with SLOs and uptime targets, so reliability is measured, not assumed. PagerDuty on-call, routing alerts to an engineer with a clear path to resolution. MySQL reliability for the data layer, and cloud cost management across both providers.
How releases work now, for every app
- 1A developer pushes code to the company's repository.
- 2The pipeline builds it on company-controlled infrastructure, not a laptop.
- 3Secrets are pulled from AWS Secrets Manager, never from code.
- 4The output is packaged for its platform: a signed, obfuscated MSI installer, an Ansible-deployed web release, a Terraform-managed serverless deployment, or a signed mobile build.
- 5It's deployed or distributed automatically, and every step is logged.
The result
Technology
Technology
CI/CD: Azure DevOps · Bitbucket Pipelines · Fastlane · Ansible Cloud: AWS Lambda · Amazon API Gateway · AWS Secrets Manager · Microsoft Azure Infrastructure as code: Terraform · Ansible Security: Wiz · Gitleaks · AWS Secrets Manager · code signing · code obfuscation · least-privilege IAM Observability and on-call: Datadog · PagerDuty Data, mobile, desktop: MySQL · Firebase · MSI installers
Find out what your stack is hiding.
If your developers are running releases from their own machines, keys are scattered across your code, and former employees' access is still in use, you're not alone, and it's fixable. Book a free audit and we'll show you where to start.