Our Process

One pipeline. Seven phases.

Every program starts with engagement — then moves through the same disciplined seven-phase lifecycle, run on an Agile/Scrum cadence with DevSecOps practices the whole way down.

Overview
01
01

The Lifecycle

Seven phases from discovery to maintenance — the iterative backbone every project moves through.

02

Agile / Scrum

The cadence the lifecycle runs on: sprints sized to the program, a visible backlog, a demonstrable result every iteration.

03

UX & Human Factors

The human side of the system — task models, operator workflows, and validation with real users, from discovery on.

04

DevSecOps

Security and automation built into every phase — not bolted on at the end.

The Lifecycle
02

The lifecycle reads as a sequence — it doesn’t run as one. Within a sprint, or a group of sprints, several phases run in parallel against the same unit of work, and each phase is revisited again and again along the program timeline.

Engage00
00

Engagement

Once per program

Contract type, fees and initial costs, and scope agreed up front — everything required to move forward officially, contract in hand. Engagement typically happens once per program.

▸ Entry gateQualified opportunity — mutual fit, budget range, decision-maker at the table▸ Exit gateSigned contract · contract type & fees · statement of work
Define01–02
01

Discovery

Requirements, domain research, and early prototypes to retire technical risk before the build starts.

▸ Entry gateContract in hand · stakeholder & domain data access granted▸ Exit gateRequirements baseline · risk register · prototypes
02

Design

Architecture and technical design — plus UX and art direction where the work calls for it — built for the target hardware from day one.

▸ Entry gateApproved requirements baseline▸ Exit gateArchitecture & design documentation
Build03–04
03

Development

Sprint-based build against a prioritized backlog. Every sprint ends with working, demonstrable software.

▸ Entry gateApproved design · prioritized backlog · environments & CI stood up▸ Exit gateWorking software or demonstrable artifact, every sprint
04

Verification

Unit, integration, and performance testing; formal V&V against source data for simulation work.

▸ Entry gateFeature-complete build passing CI▸ Exit gateTest reports · verified build
Ship & Sustain05–07
05

Deployment

Staging → Release

Release candidates run in a production-like staging environment for acceptance testing, then roll out as a versioned, repeatable release — storefront, customer network, or air-gapped installation.

▸ Entry gateVerified build · staging environment matching production▸ Exit gateSigned-off candidate · shipped release
06

Monitoring

Telemetry, crash reporting, and performance metrics from the live system, feeding back into the backlog.

▸ Entry gateLive system with telemetry wired▸ Exit gateLive health & performance data
07

Maintenance

Patches, updates, and long-term support on an agreed cadence. Twenty-five years in, we still support what we ship.

▸ Entry gateAgreed support cadence / SLA▸ Exit gateSupport & update cadence
Agile / Scrum
03

The lifecycle isn’t a waterfall. From discovery through maintenance, work runs in sprints sized to the program — planned against a backlog you can see, ending in something you can evaluate, and re-prioritized as the program learns.

Have a formal, nailed-down requirements baseline? We also run traditional waterfall programs when the contract or the mission calls for it.

01

A demonstrable result, every sprint

Sprints end in something you can evaluate — working software once the build is underway; prototypes, designs, or findings in early and design sprints. Demos are the status report.

02

A backlog you own

Priorities live in a backlog you can see and reorder. When the mission changes, the plan changes with it — without a change-order fight.

03

Retros that change the process

Every sprint closes with a retrospective, and what we learn adjusts how the next one runs. The process itself is iterated.

UX & Human Factors
04

Whether the user is a player or an operator, the interface is where the software succeeds or fails. UX runs through the lifecycle — heaviest in discovery and design, validated continuously through development.

For simulation and defense work that means human-factors engineering: task models, operator workflows, and interfaces built for high-workload, high-consequence environments. For games, the same discipline shows up as playtesting and feel.

Understand the user
Journey maps · task models
Discovery includes the humans: who operates the system, under what workload, toward what mission. Journey maps and task models capture the workflow before any interface is drawn.
Design the interaction
Wireframes · prototypes
Operator workflows and interaction design worked out in wireframes and clickable prototypes — cheap to change on paper, expensive to change in code.
Validate with real users
Usability studies · playtests
Prototypes and sprint builds go in front of actual operators and players. Usability findings feed the backlog like any other requirement.
Design for the environment
Human-factors review
Displays, controls, and alerting designed for the real operating context — high workload, degraded conditions, gloved hands, night ops. Standards-driven where the contract requires it.
DevSecOps
05

Security isn’t a phase at the end — it’s a property of the pipeline. Every commit is built, tested, and scanned automatically; every environment is versioned and reproducible.

The depth is scaled to the program: a defense system with compliance requirements gets the full pipeline below; a commercial title gets the automation that earns its keep — CI, testing, reproducible builds — without the ceremony it doesn’t need.

Commit
Build
Test
Scan
Security gate
Stage
Acceptance gate
Release
Shift leftSecurity requirements are captured in discovery and designed in — threat surface, data handling, and compliance constraints are architecture inputs, not audit findings.
Automated pipelineEvery commit is built, unit-tested, and statically scanned in CI. A build that fails the pipeline never reaches a human tester, let alone staging.
Reproducible environmentsInfrastructure and environments are defined as code and versioned. Staging matches production; any release can be rebuilt bit-for-bit.
Continuous hardeningDependency scanning, least-privilege access, and patch monitoring continue through the maintenance phase — the pipeline keeps running after release day.
Ready to start at phase one?
Tell us about the project. You’ll hear back from us directly.
Start a conversation →