How I Work
I start with your operation. Before significant implementation begins, I need to understand how your business and systems actually run — the workflows, the rules, the exceptions, the constraints. That understanding is what makes the work fit.
Engagement modes
When Stax owns the project
On Stax-owned engagements, I create the documentation, architecture, delivery plan, implementation, verification, and handoff structure. The process below is how those projects typically run.
When Stax joins an existing team
When I work inside an existing engineering organization, I adapt to the team's established practices rather than creating a parallel delivery system.
I work within the existing planning, architecture, documentation, code-review, CI/CD, testing, and release conventions, adding structure where useful and filling gaps where necessary.
01
Discovery — I learn your operation
We start with a conversation where I ask a lot of questions. Not only about technology — about your operation. What stages does your workflow move through? Who touches what? What are the rules that govern decisions? Where do exceptions happen and how do you handle them today?
Software projects often move into implementation before the operational context is fully understood. I spend real time here, because work built from a shallow understanding of the operation will miss things that matter. Edge cases discovered after launch are expensive. Edge cases designed in from the start are just features.
The discovery call is free. No pitch, no obligation. If I can't help, I'll say that.
02
Groundwork — understand before significant implementation
Before significant implementation begins, the important workflows, constraints, data relationships, business rules, risks, and major architectural decisions should be understood well enough to guide the work. The details continue to evolve as the system is built and tested.
On Stax-owned projects, that understanding becomes the foundation of the Groundwork documentation set — seven structured documents that are built alongside the project and committed to the repository.
architecture.md
System overview, layers, principles, service objects
tables.md
Every database table, column, constraint, and index
model-relationships.md
How data connects — associations, scopes, validations
build-map.md
Every feature in sequence, marked complete or planned
code-notes.md
Non-obvious business logic in plain language
design-artifacts.md
Design system, component patterns, conventions
rules.md
Codebase conventions, naming patterns, what not to touch
These aren't written after the project ships. They're built as the project is built — updated after every session. When you receive the codebase, you receive the full context that makes it legible.
03
Build — against documented context, with you
Development happens in structured cycles against the agreed context. You're in the loop at regular intervals — not buried in technical detail, but able to see progress and weigh in when decisions have operational implications.
I use AI-assisted engineering where it improves delivery, but generated work is treated like any other engineering contribution: it operates against documented context and must pass review, testing, and verification before it ships.
04
Test — smoke, edge, real-world
Every feature cycle ends with manual smoke testing and edge case testing before anything merges. The edge cases identified in discovery are tested directly. Automated tests cover the critical paths. Nothing ships because it demoed cleanly — it ships because it held up under realistic use.
05
Handoff — you own everything
At the end of a Stax-owned project: the codebase, the complete Groundwork documentation set, access to every system — hosting, database, credentials. Nothing withheld. Nothing that lives only in my head.
If you want to bring on another engineer, they'll have everything they need to get oriented. If you want to continue working with me, that's available. The point is that it's your decision, not mine — because you own everything required to make it.
Collaborative
Working inside your process
When I join an existing team, I do not require adoption of Stax's seven-document Groundwork process. Mature organizations already have ADRs, RFCs, issue trackers, architecture docs, API contracts, schemas, test plans, and internal standards — and those should remain the source of truth.
I work within the current architecture, planning, documentation, review, testing, and delivery conventions—filling gaps rather than imposing a parallel process. The goal is focused senior capacity on a difficult system or milestone, not a second delivery system running alongside yours.
Why operation-first matters more now than it used to.
AI coding tools have made it faster than ever to generate software that works at a surface level. They've also made it easier to produce software that doesn't actually fit the operation it was built for — because the tools execute instructions quickly but can't interrogate whether those instructions capture the full complexity of a real workflow.
Starting with the operation — understanding it deeply before significant implementation — is what produces software that fits. The AI tools can accelerate delivery. The operational understanding is what makes the delivery worth accelerating.
Ready to start
Free 30-minute call. No pitch.
Tell me what your operation looks like and what isn't fitting. I'll tell you honestly whether I can help — directly, or alongside the team you already have.