How we work
Most agency horror stories come from the same place: a sales conversation that did not match the build. This page is the operating model we use on every engagement, the artifacts you will actually see, the cadences we keep, and the contractual ground rules. Skim it before our first call so we can spend that call on your problem.
Artifacts
Every engagement produces a small set of artifacts. They are not slide decks, not vanity dashboards, and not buried in a project tool you will never log into again. Each one lives in the repo or a shared folder, written in plain English, and is kept current.
After kickoff, before design
A short document that captures goals, users, constraints, integrations, risks, and what success looks like. Written in plain English, not consultant slides. We share the draft, refine it with you, then both sides sign off.
Continuously updated
A living list of known risks with severity, owner, and mitigation. Anything that can quietly kill the project is named here, by week three at the latest. We discuss the top three risks at every review.
Whenever a non-trivial decision is made
Each ADR captures the decision, the alternatives we considered, why we picked what we picked, and what would make us reconsider. Stored in the repo so the next person on the project can read what was already debated.
Every Friday
What shipped this week, what is in flight, what is blocked, what changed, and what is decided next week. Written, not a meeting. Designed to be skimmed in 90 seconds.
Before each release
What has to be true for a release to ship: features verified, edge cases tested, performance budget met, security checks passed, documentation updated. We walk it together before any production push.
At engagement end
Repo access, infrastructure runbook, deployment instructions, environment variable inventory, vendor accounts, known issues, and recommended next steps. Whether you continue with us or move to another team, you can pick the work up cleanly.
Cadence
Code reviews, pull requests, design comments, and quick decisions in a shared channel. We default to writing things down so context survives time zones and follow-up questions.
One 30 to 45 minute review with the named lead and any stakeholders who own decisions. What shipped, what is at risk, what we need from you. The Friday status doc is sent first so the meeting is shorter.
Release notes, an acceptance checklist walk-through, and a short demo. We do not push to production without your explicit go-ahead unless the contract says otherwise.
If a risk turns red, you hear about it immediately, in writing, with options. You will not learn about a missed deadline from a status doc on Friday afternoon.
Engagement shape
We are not a body shop, and we are not a one-week prototype factory. Engagements are scoped in cycles of meaningful work, usually weeks or months, not hours.
Typical span: 12 to 24 weeks for a first production release. Designed in releases. Discovery, then design, then build in cycles, with working software every two weeks.
Typical span: 4 to 12 weeks of stabilization, then a build path. We start with an audit, then either stabilize what is salvageable or plan an incremental rebuild. We do not push for a full rewrite when a partial one will do.
Typical span: 8 to 20 weeks. Old stack, new stack, and a path between them. We plan the migration in slices so the business never goes dark.
Typical span: 6 to 16 weeks. Internal admin, reporting, automation, and integrations. Often shorter than customer-facing builds because the audience is smaller and the constraints are different.
AI in our build process
AI tooling is part of how we build. Senior engineers direct the work and review every change; AI handles boilerplate, scaffolding, tests, and the repetitive parts of refactoring. We don't ship code we haven't read. ADRs still get written by humans. Code review is still where decisions land. The point is to spend senior time on architecture, edge cases, and judgment, not on typing.
Risk and ownership
The questions a careful buyer asks late in a sales process should be answerable up front. Here is where we stand on the questions that matter most.
All work product made for your engagement is yours, on payment. No background-IP claims that quietly retain rights to what we built. The contract makes this explicit, in plain English.
Mutual NDA available before discovery. We can sign yours or use ours. We do not require an NDA to have a first conversation, but we honor one once signed.
We work in your accounts when that is what you want. Where we provision infrastructure, we hand over administrative access at engagement end. Credentials we are given live in a secure vault, not in chat or shared drives.
Invoices reference the engagement, the period, and the work delivered. Hourly burn or fixed milestones, agreed upfront. No surprise line items.
We choose stacks your team can hire for. We document what we built. Another team can pick up the work without a translator.
At engagement end, you receive a handoff package: repo access, runbook, environment inventory, known issues, and recommended next steps. Whether you continue with us or not, the project goes with you.
Engagements are staffed by a small senior-led team. The same engineers stay on the project from kickoff through handoff. We don't rotate juniors in mid-engagement to manage utilization, and we don't subcontract delivery to people you'll never meet.
Every engagement is governed by a written contract. The points above are how the contract reads, in plain English. If your procurement team has additional questions, send them ahead and we will answer in writing.
Tell us what you are building, fixing, or stuck on. We will respond with practical next steps, an honest fit assessment, and the shape of an engagement if it makes sense.