The CI/CD Pipeline SEM Nexus Built for Itself, And Now Ships to Clients

Most agency-built mobile apps ship with whatever continuous-integration setup the agency had when they started — often years out of date, often optimized for the agency's last shop, often a fragile chain of scripts that breaks when someone joins or leaves the project. SEM Nexus rebuilt our internal CI/CD pipeline in 2024 and we ship the same pipeline to every client on every build. This post is what's inside, why we standardized, and what it means for your project.

What we ship to every client

The CI/CD setup is consistent across all SEM Nexus builds regardless of stack:

1. Source control with branch protection. Migration/feature branches, mandatory PR review, no direct pushes to main.
2. Automated test runs on every PR. Unit, integration, and key end-to-end tests. PR can't merge if tests fail.
3. Lint + type checks on every PR. Enforced consistency across the codebase.
4. Automated builds for both platforms on every push to the main/develop branch.
5. Automated TestFlight + Internal Track deployment for the QA team and the founder.
6. Manual-trigger production deploys to App Store / Play Store with version-bump automation.
7. Crash monitoring, structured logging, and performance budgets wired into the pipeline.
8. Secrets management with no API keys, certificates, or credentials in source.

The setup runs on GitHub Actions for most clients (or Bitbucket Pipelines / GitLab CI when the client's stack requires). The cost is moderate — typically $50–$300/month of CI compute, well within what a serious mobile build budget should expect.

Why we standardized

Before 2024, every SEM Nexus build had a slightly different CI setup. Different scripts, different stages, different debugging surfaces. When an engineer rotated between projects, they spent a sprint learning the project's CI. Bugs in the pipeline took a senior engineer to debug because the patterns weren't consistent.

We rebuilt the pipeline as a single template that adapts to the stack. Now:

• An engineer can move between projects without re-learning CI
• Pipeline bugs get fixed once and the fix benefits every project
• New clients inherit the proven pipeline immediately
• The maintenance cost compounds in our favor instead of against us

This is what an agency mature enough to invest in tooling looks like. Most don't. The result for clients is a CI/CD pipeline that doesn't break in week 4 of the build.

What each pipeline stage does

PR validation

When an engineer opens a PR, the CI runs:

• Linter (ESLint, dart analyze, swiftlint, ktlint — depending on stack)
• Type checker (TypeScript, Dart's static analyzer, Swift compile, Kotlin compile)
• Unit test suite
• Integration tests (where applicable)
• Build verification on both platforms (does the app actually compile?)

A PR that fails any of these can't merge. The senior engineer reviewing the PR sees the failures explicitly. The team doesn't spend reviewer time on PRs that don't even build.

Build + automated deploy to test track

When a PR merges to the main branch, the CI:

• Bumps the build number
• Builds iOS and Android artifacts
• Signs both with the client's certificates (managed in secure CI secrets)
• Uploads iOS to TestFlight (internal testers)
• Uploads Android to Google Play Internal Testing track
• Notifies the team in Slack

Result: the founder and QA team can install the latest build on their phones within ~10 minutes of a merge. No manual build steps. No "the engineer needs to push the build" friction.

Production deploys

Production deploys are explicit, manually triggered, and traced. They:

• Tag the release in source control
• Generate release notes from PR titles since the last release
• Submit to App Store / Play Store production tracks
• Update internal release dashboard

We don't auto-deploy to production. Founder approval is the trigger. The pipeline makes the deploy clean once approval is given.

If your current build has a CI/CD setup that requires senior engineers to babysit, SEM Nexus's builds include the standardized pipeline as a default deliverable. The pipeline is part of what you're paying for — not an upsell.

Three CI/CD failures we designed against

Flaky tests blocking deploys. When a test fails intermittently (network timing, ordering issues), the team learns to ignore failures, which means real failures get ignored too. SEM Nexus has a quarantine pattern for flaky tests — they're marked, isolated, and either fixed or removed within one sprint. The CI signal stays meaningful.

Certificate / provisioning profile expiry. iOS certificates expire. Most projects find this out at midnight before an App Store submission. Our CI monitors certificate expiry and warns 60 days before, with an automated path to renewal where possible. This is the most common cause of "we tried to ship and couldn't" incidents in mobile, and we eliminated it structurally.

Secrets leaking into source. API keys committed to git happen even to careful teams. Our CI runs secret scanners on every PR (truffleHog or equivalent) and blocks any PR with a detected secret. The client doesn't have to worry about a leaked AWS key making it into a public repo.

What this signals to clients

CI/CD is invisible when it works. It's catastrophic when it doesn't. The fact that your build has a clean, reliable, modern CI/CD pipeline from day 1 is one of those things you won't notice during the build but you'd notice immediately if it weren't there.

Three things this enables for your project:

• Faster iteration. The founder gets new builds on their phone in 10 minutes, not 2 days.
• Reliable production deploys. When you want to ship a hotfix, it ships.
• Lower handoff cost when you take the build in-house. Your future engineers inherit a pipeline that's standard and documented, not a one-off the prior agency built.

What this looks like in practice

On a typical SEM Nexus build:

• ~20–40 PRs per week during active development
• ~95% of PRs pass CI on the first run (the 5% fail on linting, type errors, or test issues that get fixed quickly)
• TestFlight build delivered to QA within 12 minutes of a merge
• Production deploys take ~45 minutes from "founder approves" to "live on App Store"
• Zero certificate-expiry incidents across our portfolio in the last 18 months

This is what "production-grade mobile development" looks like at the infrastructure layer. Most agencies don't operate this way. The ones that do ship cleaner builds.

What to ask any agency you're evaluating

Three CI/CD-specific questions:

1. "Show me the CI/CD pipeline for a recent client. What stages, what tools?" A real answer is specific. A vague answer means there isn't a standard pipeline — it's per-project chaos.
2. "How do you handle iOS certificate renewals?" A real answer involves monitoring + advance warning. A bad answer is "we deal with it when it expires."
3. "What happens to the CI/CD pipeline when we take the build in-house?" A real answer involves clean documentation + transition support. A bad answer is "you'll have to rebuild it."

SEM Nexus answers all three with specifics. If your prospective agency can't, you're going to inherit fragile infrastructure that bites you in month 6.

If you'd like a build that ships on a modern, reliable CI/CD pipeline from day 1, SEM Nexus delivers it as part of the build — not an add-on, not a separate quote. The infrastructure is one of the structural reasons we ship on time.