How we work
This is the real lifecycle every change to software we build goes through, from the first email to the live release. The size of the job changes how long each stage takes. It never changes which stages happen.
A senior engineer directs the work. AI agents do the building. Guardrails written in code make sure nobody, human or machine, takes a shortcut to production.
The lifecycle
For each stage: what happens, what you see, and what is enforced by the system rather than left to good intentions.
Every ask becomes a task
An email, a call, a text or a problem our monitoring spots becomes a tracked task the moment it arrives, written in your words and filed against your project. Four questions in one email become four tasks, so nothing gets closed by accident when the first one is answered.
Read the real code first
Before anyone commits to an approach, we read the code that is actually there: where the change belongs, what already exists that can be reused, and what it could break. Larger work is broken into small pieces, each one shippable on its own. A senior engineer makes the architecture calls.
See it before we build it
When a change is visual, you see it first: a mockup or a clickable prototype in our real design system, at phone and desktop sizes. It is far cheaper to move a button in a mockup than in shipped code.
Its own branch, its own workspace
Every change is built on a fresh branch in an isolated workspace, never on the live code. The engineer directs and AI agents built on Anthropic’s Claude do the building: reading the code, writing the change and writing the tests for it. When several pieces are in flight at once, each gets its own workspace so they cannot collide.
A paper trail with every change
Each commit says what changed and why, in a standard format, and carries a written changelog entry and any documentation it affects in the same commit, never as an afterthought. Secrets and passwords cannot be committed: the tooling refuses before they ever reach GitHub.
Nothing merges on its own say-so
The change opens as a GitHub pull request with a summary of what changed, why, and how it was verified. On every product and application repository we run, the main branch is locked: it rejects direct pushes, cannot be force-rewritten, and will not merge until the automated check passes.
Proved, not assumed
We run the automated test suite, a security-focused code review of the change (authorization, input validation, anything that touches data), an axe-core accessibility scan against WCAG 2.2 AA, and full-page screenshots at phone and desktop widths. A red suite stops the job.
Ship only what was merged
Our deploy scripts refuse to run unless the code on hand is exactly what was merged, with nothing extra in the working copy. Data changes get a backup first. After the deploy we check the live site, and error tracking and uptime monitoring keep watching it. Releases get a version number, so “what shipped, and when” always has an answer.
Small or large
Two typical jobs, walked through the same pipeline. The small one does not get a lighter version of the process. It gets the same one, faster.
A small change
One field, one form, in a custom app we built. The kind of change most shops would make live and hope.
Typically the same day
A full build
A new product surface with accounts, data and money involved. Weeks of work instead of hours.
Typically several weeks
Who does what
We are an AI-native software company, and we would rather tell you exactly how that works than let you guess. People decide. Agents build. Code enforces the rules on both.
The same operating layer runs our own business every day. See Dembe OS.
The stack behind the process
“We follow best practices” means nothing without the tools that enforce them. These are the ones doing the work, including two we built and run ourselves.
Questions
Because small changes break live software too, and usually at the worst moment. The steps are automated, so on a small change they cost minutes, not days. What you get in return is that nothing reaches your live site without a record, a test run and a way back.
Yes, and we say so openly. AI agents built on Anthropic’s Claude read the code, write the change and write the tests. A senior engineer directs the work, makes the architecture calls and approves the plan before it starts, and the same locked branches, required checks and guarded deploys apply to every change regardless of who or what wrote it. AI-native, not AI-added.
The main branch on our product and application repositories is locked by GitHub itself, so skipping is not a matter of willpower. The only bypass is an emergency hotfix for something broken in production, and that change is landed through a normal pull request the same day so the record stays whole.
We are. Champlin Enterprises has shipped software since 1998, and the same senior engineer is on the first call and the last release. Error tracking alerts us, every release has a version you can roll back to, and the fix goes through the same pipeline as everything else.
Yes. Every change has a pull request that says what changed and why, and a dated changelog entry in plain language. You own the code and its full history, with no proprietary framework holding it hostage.
It applies to every change to software we build: custom applications, SaaS platforms, mobile apps and code-based sites. Routine content edits made in a site’s own editor, like a new photo or a revised paragraph, do not involve code, so they are made directly and checked live.
Tell us what you need built or fixed. It goes through all eight stages, whatever its size.
