How we work
Every engagement — greenfield or joining an existing codebase, hourly or fixed-scope — moves through the same five phases. What changes between engagements is how much of each phase already exists to build on, not whether the phase happens.
Delivery phases
- 01
Discovery
- What we do
- We interview the team, read the existing codebase where one exists, and turn requirements into a written specification with an architecture decision record and a phase plan with estimates.
- What the client does
- Answers questions, provides access to any existing codebase or systems, and reviews the specification before it's accepted.
Produces: Written specification, architecture decision record, phase plan with estimates
- 02
Architecture
- What we do
- We design the system: data model, interface contracts, and a threat model for anything handling sensitive data or user funds.
- What the client does
- Reviews the architecture decision record and interface contracts, and flags any constraint we couldn't have known about — a compliance requirement, an existing system we need to integrate with.
Produces: System design, data model, interface contracts, threat model
- 03
Build
- What we do
- We build in working increments on a fixed cadence; each increment is demoable and covered by tests before it's considered done.
- What the client does
- Sees each increment as it ships, not just at the end of the phase, and raises anything that doesn't match the specification while it's still cheap to fix.
Produces: Working increments on a fixed cadence, each demoable and tested
- 04
Hardening
- What we do
- We extend test coverage, run failure-mode and load testing, review our own work against the threat model from architecture, and confirm the performance budget is met.
- What the client does
- Reviews the hardening results — test output, load-test numbers, and any issues found and fixed — before agreeing the phase is complete.
Produces: Test coverage, failure-mode and load testing, performance budget met
- 05
Delivery
- What we do
- We deploy the system, write the runbook, hand over credentials, and walk the client's team through operating it.
- What the client does
- Takes operational ownership — credentials, deployment access, and the runbook are now theirs, not something we hold onto.
Produces: Deployed system, runbook, documentation, credential handover
How we verify our own work
"Verified" means one thing here: CorpiXo verifies its own work. Everything below is something we do to what we build, produced during delivery rather than after the fact — not a review, audit, or sign-off on a system someone else built.
- Invariant and property tests
- For contract work, properties that must hold regardless of input — not just the cases someone thought to write a test for.
- Simulation tests
- For Cosmos-SDK modules, randomized operation sequences run against the state machine to surface state transitions a hand-written test wouldn't think to check.
- Reproducible benchmarks
- Committed alongside the code that produces them. A number on this site without a benchmark script behind it isn't a number we'll publish.
- Evaluation harnesses
- For AI systems, a fixed test set and a defined pass/fail criterion, run against every change rather than checked once before launch.
- Threat models
- Produced in the architecture phase, before build starts, for anything handling sensitive data or user funds — not written retroactively to justify a design already built.
- Key management design
- Specified and reviewed as its own artifact when a system depends on it, since a flawed recovery path is expensive to unwind once users depend on it.
Working style
- Written-first
- Specifications, architecture decisions, and acceptance criteria are documents, not a shared understanding that lived in a call.
- Async by default
- One weekly synchronous checkpoint; everything else happens in writing, on the client's schedule as much as ours.
- Decisions recorded
- An architecture decision made in a conversation gets written down before it's acted on, so the reasoning outlives the conversation.
- Direct access to the engineer doing the work
- No account-manager layer between the client and the person writing the code — questions go to whoever can actually answer them.