Embedded build team
Our tools and workflow, working inside your codebase and your daily team meetings.
Sometimes the work is a backlog of tasks that is moving too slowly, with no fixed start or end. We join your existing team and repository, work on your tickets, and follow your review process. The difference is how much work gets done: the same backlog, worked with AI-written code and an eval suite proving every pull request.
Our approach
We adopt your conventions rather than importing ours, because a codebase with two competing styles is worse than one with a style you dislike. Everything goes through your review process, and every pull request has to pass the eval suite written from your specification before it reaches your main branch, whatever wrote it. Runs month to month, growing or shrinking as the backlog changes.
Other builds
Common questions
How is an embedded build team different from a normal outsourced team?
The work happens inside your existing repository and your existing daily meetings, on your ticket backlog, rather than as a separate project delivered back to you at the end. What changes is how fast the backlog you already have gets done, using AI-written code and an eval suite proving every pull request. There is no separate stream of work you have to combine with yours afterward.
Whose coding conventions and style get used on the codebase?
Yours. We adopt your conventions rather than importing ours, because a codebase with two competing styles mixed together is worse for your team to maintain long-term than one with a style they personally dislike but is at least consistent. That also means the eval suite written for your specification enforces your standards, not a generic one.
Does our existing review process still apply to this work?
Yes, everything goes through your existing review process exactly as if the pull request came from an internal engineer. Every pull request additionally has to pass the eval suite written from your specification before it reaches your main branch, regardless of whether a person or an AI tool wrote the change, so the standard stays the same whoever wrote it.
Can the size of the embedded team change month to month?
Yes, this pattern runs month to month and grows or shrinks as the backlog changes, rather than committing to a fixed team size for a fixed contract length. That fits the actual problem it is meant to solve, which is a backlog that is not moving fast enough right now, not a headcount plan set a year in advance.
What kind of backlog is this pattern meant for?
Work that is not a project with a defined start and end, but an ongoing backlog of tickets that is not moving as fast as the business needs. If the actual need is a single project with a clear end point, one of the other engagement patterns, like MVP to market or legacy modernization, usually fits better than an embedded, ongoing team.
Do we lose visibility into what's being worked on with this model?
No, since the work happens inside your existing repository and daily meetings rather than in a separate system you have to check. You see the same tickets move through the same board your team already uses, and the same pull request history your own engineers' work goes through, with AI-written code that must pass the eval suite before it is merged.
How does the eval suite fit into an existing ticket-based workflow?
Each pull request written against a ticket has to pass an eval suite written from your specification for that ticket before it can reach your main branch, which fits into a normal ticket-to-merge workflow rather than replacing it. The specification for the eval suite comes from the same requirement that generated the ticket in the first place.
What happens if the backlog suddenly grows or shrinks?
The embedded team grows or shrinks with it, since this pattern is explicitly designed to run month to month rather than under a fixed long-term contract. A sudden jump in the backlog does not require negotiating a new engagement, and a quiet month does not mean paying for capacity nobody is using, because the arrangement adjusts to the backlog rather than the other way around.