DomeWorks · Software Factory Sprint
Build a software factory your team can run.
Turn one useful delivery workflow into a working software factory in your codebase. We build the agent workflows, testing, and review gates, then work alongside your engineers to make them part of everyday delivery—with quality and model costs under control.
Who it is for
Your team uses agents. Delivery still gets stuck.
For engineering leaders at product and SaaS teams of about 10–50 engineers, and services companies scaling agent-assisted delivery. You have a live codebase, work that needs to ship, and engineers ready to adopt a shared workflow.
Small changes wait for review. Agents miss decisions buried in the codebase. Releases need manual checking. The sprint connects those pieces so more work can reach production with the team you have.
01 · What we build
One working path from requirements to release
We start with a bounded workflow, such as taking a well-specified product change through implementation, verification, and review. The scope covers the parts needed to make that workflow usable in your environment.
Requirements and context agents can use
A way to turn incoming work into clear tasks with acceptance criteria, backed by current codebase documentation and access to the tools agents need. The team can maintain that context as the product changes.
Implementation with evidence it works
Agent workflows connected to your repo, development environment, and CI. Agents can run the product, test their changes, and bring the results back with a reviewable pull request.
Review gates and deliberate model choices
Automated checks and human review matched to the risk of a change. Models chosen for each stage, with usage and retries visible so you can weigh quality against cost.
A team that can keep it running
Working sessions on real tasks, documented workflows, and clear ownership. Your engineers practice reviewing output, handling failures, and updating the setup as part of everyday delivery.
02 · How we work
Build with your team. Leave it in use.
Kick off
Put the agreed plan to work
Confirm the audit's workflow, acceptance criteria, ownership, and review boundaries against your codebase. Begin implementation with the environment and testing work identified in the plan.
Build
Run real work through it
Connect the workflow to your codebase and tools. Test it on agreed tasks, inspect the failures, and refine the context, checks, and model choices. Review progress together each week.
Embed
Make it part of delivery
Work through tasks with the engineers who will own the system. Document how to operate and change it, check it against the acceptance criteria, and agree what to improve next.
You work directly with Piers Rollinson, drawing on 15 years building and leading engineering teams at DoorDash, Square, and Mudflap. That experience goes into the decisions that make the workflow useful: what to automate, what context to supply, and where people need to review.
03 · Measure the result
More work shipped, with quality and cost in view
We use one shared checkpoint, 30 days after the initial audit baseline. The sprint does not restart the clock. We review the work completed by that date, including changes shipped, issues caught in testing and review, and the model usage and retries needed to get there.
That gives your team evidence for the next decision: improve the workflow, change a model or review gate, or extend the system to more work.
Price
Scoped fixed price, set after the Eng OS Audit
We agree the workflow, deliverables, timeline, and team involvement before the build starts. The audit stands on its own; commissioning the sprint is a separate decision.
The entry step is the Eng OS Audit at $5–15k.
FAQ
Do we need the Eng OS Audit first?
The audit is the starting point: it identifies the delivery constraint, establishes a baseline, and scopes the first workflow worth building. If you already have an equivalent diagnosis and baseline, we can review them together before scoping the sprint.
What do we need to provide?
Access to the agreed repo, development environment, CI, and relevant work-tracking data, plus an engineering owner who can make decisions and engineers who will use the workflow. We agree access, responsibilities, and time commitments when we scope the sprint.
We already use coding agents. What would change?
We build around the tools your team already uses. The work connects requirements, context, implementation, testing, and review into a repeatable delivery workflow, then helps the team use it consistently.
Will agents merge and deploy changes on their own?
We agree review and release permissions for the workflow before building it. Automated checks provide evidence; human review stays where the risk requires it. Any increase in autonomy is a separate decision based on how the workflow performs.
How do you keep model costs under control?
We choose models for the work each stage needs to do and make usage, retries, and review effort visible. We assess cost alongside accepted changes and rework, so a cheaper model is useful only when the overall workflow benefits.
How long does a sprint take?
We agree the timeline with the scope after the audit. It depends on the workflow, the state of your development and test environments, and team availability. Weekly checkpoints keep progress and decisions visible.
What happens after the sprint?
Your team keeps the documented workflows, context, and review setup in your tools. You can maintain and extend the system yourselves, or continue with an optional AI Ops partnership.
When do we review the delivery measures?
There is one shared checkpoint, 30 days after the initial audit baseline. We review whatever changes are in place then; the sprint does not restart the clock. If you bring an equivalent baseline, we agree its reference date before starting.
Do we need Patina to run the factory?
No. Patina is an optional context product, priced separately at $149/month per workspace. The workflows, context, and review setup live in your tools, and the factory can run without Patina.
Start with the workflow that would make a difference.
The Eng OS Audit identifies where delivery gets stuck and scopes the first build. From there, we work with your team to get the software factory running and keep it in use.