Embed vs CTO-led pod vs fixed-scope

Which Bigcircle engagement fits: an embed, a CTO-led pod, or a fixed-scope build? The homepage already sorts this choice into three panels you can buy. Embed when you have the direction and the team, and what you lack is AI depth in the repository. Take a CTO-led pod when you have a roadmap and no senior AI leadership to run it. Buy fixed-scope when you want the working system, and you do not want the hiring or the management.

The engineers on all three panels are the same bench. What changes is how much of the delivery we run.

That sort is the whole decision, and the rest of this page only makes it usable. Buyers stall because the three panels look like three team sizes, and team size is the least interesting difference.

The difference that changes your calendar is who sets priorities, who makes the hard technical calls, and who is still accountable after the first demo. If you want the staffing choice one level up, embed versus a full-time hire versus an agency, that is a different question and it has its own guide: embedded AI engineer vs hire vs agency.

	Embed an engineer	CTO-led pod	Fixed-scope build
Who leads	You	We lead	We own the outcome
What you bring	Priorities, a team, a codebase	Product context and a roadmap	The problem, and a definition of done
What we bring	1 to 3 production-proven engineers in your repo. We handle employment	A managed squad of 3 to 8, engineers and QA, with our founder as fractional CTO	Discovery, build, evals, and deployment, one point of accountability, fixed scope and price
You still own	The code, the priorities, the product calls	The product context. We own the delivery rhythm and the hard technical calls	The problem and the acceptance. We own the path to the system
Best when, in the homepage's words	You have the direction and the team, but not the AI depth	You have a roadmap but no senior AI team to run it	You want the result, not the hiring and management overhead
Walk away if	Nobody can set priorities week to week	You want one specialist inside a squad you already run	You cannot say what shipped means, or the system will keep changing with no owner

The size bands in that table are the ones printed on the homepage: 1 to 3 embedded engineers, a managed squad of 3 to 8, and a fixed outcome. The hire page describes the same pod and prints the squad as 4 to 8. Treat both as "a squad, not a single engineer." Neither page publishes a rate, and this guide will not invent one. Headcount on a given engagement is set on the call.

Which model is the homepage describing?

The homepage sorts the buy by who runs delivery, and the picture below turns that sort into a sequence you can walk. Start with what you are buying, a finished system or people in the repository, and only then ask whether you can direct the work. Teams reverse that order, pick a team size they find comforting, and discover in week three that nobody owns the priority list.

This figure is a framework. The questions are the homepage best-when lines, placed in the order that stops a mismatched contract. If you are buying the working system and you can already say what shipped means, the matching panel is fixed-scope: discovery, build, evals, and deployment under one point of accountability, against a fixed scope and price. If you cannot say what shipped means, the flowchart does not send you to a cleverer model.

It sends you to write the test. A fixed price on an undefined outcome is how scope arguments start, and no squad structure fixes a missing acceptance test.

If you are buying people in the repository, the next question is whether your leads can direct the AI work. When those leads can direct the work, embed an engineer. The homepage calls that the low-risk way to start: a production-proven engineer in your codebase and your timezone window, you set priorities and own the code, and we handle employment.

When they cannot, because the roadmap exists and there is no senior AI lead to run it, the matching panel is the CTO-led pod. An embed into a team with no one to direct it produces activity. The pod exists so the direction comes with the squad.

If two answers feel true, ask who must be able to change the system in six months. If the answer is your team, you are on the right-hand branch even if a fixed scope sounds quieter. If the answer is "we want it finished and we do not want to manage it," you are on the left-hand branch even if you like the idea of an engineer in standup.

The flowchart is a sequence, not a score, and it does not rank the engineers. The homepage line above the three panels is that the bar of talent stays the same.

Who owns what on each model?

Ownership on these three models is published in pieces, on the homepage and on the hire FAQ, and the grid puts the pieces on one page so a contract review can see them together. The words in the colored cells are the homepage's, with one row that comes from elsewhere: code and IP. The hire FAQ states that you own the code and the IP, and that engineers work in your repositories under your confidentiality terms.

That sentence is how we read all three models. It is not a special rule we invented for the pod or for fixed-scope.

This figure is a framework restating published copy, not a RACI from a project plan and not a survey of how engagements happen to run. Embed: you lead, you set priorities, your leads direct the technical calls, the rhythm is your sprint, you own the code, and we handle employment, payroll, and compliance.

The engineer is full-time in your tools, not a vendor you brief and wait on. That day-to-day description is the "what embedding actually looks like" block on the hire page.

The pod column follows the homepage panel: we lead, you bring product context, we own the delivery rhythm and the hard technical calls, and the squad is engineers and QA with our founder as fractional CTO and architect. The hire page uses a slightly different verb for the same shape. It says we share accountability for each sprint, and it calls the group a managed squad with a tech lead and QA.

Both pages leave the roadmap and the product context with you. If you need a single phrase, use the homepage: we lead the delivery, you keep the product judgement. Do not expect the pod to invent the product.

Fixed-scope is the column where you stop managing the build. You bring the problem. We own the path: discovery, build, evals, and deployment, under one point of accountability, at a fixed scope and price. Employment is not your headcount, which is the "not the hiring and management overhead" line on the homepage.

Code and IP stay yours under the hire FAQ, so "we own the outcome" does not mean we own the repository. Read that distinction into the statement of work anyway, because a buyer who hears "we own it" can miss the IP sentence sitting on a different page.

One cell the picture refuses to invent is on-call after launch. The site does not publish a single on-call rule for all three models. On an embed, the engineer is in your sprint and your tools, so operational duty follows your team's practice. On a fixed-scope build, what continues after acceptance has to be written into the scope, or it does not continue. If on-call matters, name it as an acceptance item rather than assuming the diagram implied it.

When do you embed an engineer?

Embed is the low-risk way to start, and only when someone on your side can direct the work. You already have the team, the repositories, and a view of which system should move this month. The gap is AI depth: retrieval that cites a source, an agent whose tools are scoped, evals that can fail a release, guardrails on the output, and observability when a run goes wrong.

Hiring that depth onto your payroll is a different decision, covered in the staffing guide. Embedding it is how you get the depth into the repo without opening the req.

The published pace is specific. A 30 minute call, a shortlist within two to five business days, your interview or an optional paid trial on a real task, and someone in the repo inside two weeks. You confirm the fit before you commit. If the match is wrong after that, we replace the engineer at no extra cost. You own the code. We handle employment.

The engineer takes direction from your leads the way any other member of the team does, which is why this model fails when those leads do not exist. There is nothing to embed into except a backlog nobody will prioritize.

Embed is also the wrong buy when you want to stop thinking about the build. You will still set priorities, still review pull requests, and still decide which failure matters. That is the point of "you lead. If that sentence is unattractive, look at fixed-scope rather than asking an embedded engineer to also be your AI lead, your product manager, and your on-call rotation.

One person can add depth to a team. One person cannot be the team and the leadership at the same time.

When do you take a CTO-led pod?

A roadmap with nobody senior to run it is the pod's buyer. You can describe the systems you want in production, and you do not have a staff engineer or a CTO who can make the hard calls: what to eval first, where tool calling is allowed to write, which model is worth the latency, when a hallucination is acceptable because a human reviews it.

Embedding one engineer into that gap does not create the missing lead. The engineer will ask you for priorities you cannot give, and the roadmap will sit in the same place it sat before the contract.

The homepage describes the shape directly. A managed squad of engineers and QA, led by our founder as your fractional CTO and architect. We own the delivery rhythm and the hard technical calls. You bring the product context. The printed size is 3 to 8 on the homepage and 4 to 8 on the hire page, and both mean a squad you are not line-managing.

The depth on offer is a senior AI leader without the hire, which is the panel's own phrase. You are not receiving a substitute product strategy. You are receiving technical leadership of a build whose product context you still have to supply.

The public build that names this leadership shape is Solarpunk. The case study says our team delivered the product with a fractional CTO leading the build: an agent that plans a goal, acts across the systems a leader already uses, and checks its own work. Plans completed with no human intervention rose from roughly 55 percent to 80 percent once the agent was grounded in the user's own workspace.

That figure is our internal measurement, not yet reconfirmed with the client, and the case study says so. We are not claiming the commercial paperwork was labeled "CTO-led pod.

We are claiming the leadership shape the pod is named for is a shape we have already used on a shipped product, including dynamic tool discovery across more than a hundred tools, roughly six months before the labs published the same pattern as a standard. The count and the timing are the ones on our MCP servers page.

Take the pod when the roadmap is real and the senior seat is empty. Do not take it when you want a single specialist beside an engineering manager who already runs the squad. That is an embed, and paying for a fractional CTO you will not use is how the middle panel gets bought by mistake.

Do not take it when you want the system and you do not want a relationship with a squad at all. That situation calls for a fixed-scope build, not a pod.

When do you buy a fixed-scope build?

Fixed scope is the buy when you want the working system and you do not want to manage the build. You bring the problem. We ship discovery, the build, the evals, and the deployment, under one point of accountability, at a fixed scope and price.

The homepage's best-when line is the whole test: you want the result, not the hiring and management overhead. If you want to keep the management, you are looking at the other two panels and using fixed-scope language because the price sounds easier to approve.

The acceptance test is the contract. For a retrieval system, done means a recall number on your questions and a citation that resolves, not a demo that answers the happy path. For an agent, done means a check that the action happened, independent of the model reporting that it happened. For a customer-facing flow, done includes what the system must refuse.

Our evals service is the standalone version of that work, and on a fixed-scope build the harness is part of what we leave behind, because a change nobody can measure becomes an argument. If you cannot write the test yet, the flowchart was right: write it before you buy the scope.

A public example of a bounded production system, not a claim about contract type, is the Skionis cloud agent. Template errors before deploy fell from around 10 percent to 4 percent, and the closed loop reached a working product in about four months. Those figures are our internal records from the build. The case study does not name the commercial model, so this page will not assign one.

What it does show is the kind of bar a fixed-scope acceptance clause can point at: a number that moved, on a system an engineer will let near a live account, with every resource tagged back to the request. If your "done" cannot be pointed at, you do not have a scope. You have a research project, and fixed price is the wrong container for it.

Fixed-scope fails when the real need is ongoing ownership. A product you will still be changing next year needs a named person in the repo after acceptance. The fixed-scope panel delivers a system. It does not, by itself, leave you with a senior AI lead. If that is the gap, start on the team path. You can still write acceptance tests.

You should. The tests are how you know the embed or the pod is working, and they are not exclusive to a fixed price.

When do you switch, and when do you not?

Scaling an embed into a pod is the path the hire page publishes, and it is the only switch this site actually describes. You start with one engineer, which the homepage calls the low-risk way to start, and you grow to a squad when the roadmap does, keeping the same people, the same context, and the same accountability.

Growing the team does not mean re-explaining the system to strangers. That sentence is the hire page, and it is the reason the team path is drawn as one line rather than as two separate purchases.

This figure is an illustrative model. It has no week number, because no page publishes the week at which an embed should become a pod. The trigger is qualitative and it is yours to call: the roadmap needs more than one engineer can carry, and you still do not have a senior AI lead of your own.

Until that is true, adding a pod is overhead. After it is true, staying with a single embed means the lead you do not have is still the constraint, and the engineer is still waiting on priorities.

The outcome path is drawn separately on purpose. This site does not publish a rule for converting an embed into a fixed-scope contract, or the reverse. Fixed-scope is chosen at the start, when the buy is the result and the management is the thing you do not want.

If you began with an embed and later want us to own a bounded outcome, that is a new scope with its own acceptance tests, not an automatic next stage of the picture. Treating it as automatic is how a time-and-materials relationship gets renamed without the definition of done ever being written.

How does your situation map to one model?

Match the situation you are actually in, using the homepage lines rather than a preference for a particular team size. The three rows below are those lines. A cell that says Fit is the panel written for that line. A cell that does not is the reason the other panels would answer a different problem, and it is not a judgement of quality. The same engineers sit behind all three.

This figure is a framework, and the rows are not survey segments. "You have the direction and the team, but not the AI depth" is the embed. Buying the pod in that situation pays for leadership you did not ask for, and your own leads will collide with a fractional CTO who is now making calls your team expected to make.

Buying fixed-scope in that situation hands off a build you were equipped to direct, and you will spend the engagement trying to get the management back.

"You have a roadmap but no senior AI team to run it" is the pod. An embed still needs your lead, which is the condition you just said you do not have. Fixed-scope can still be right if, on inspection, you do not want a squad at all and you want one system finished. The mistake is buying a squad because the roadmap looks large, when what you wanted was a single shipped system and a quiet calendar.

"You want the result, not the hiring and management overhead" is fixed-scope. An embed leaves you directing the work, which is the overhead you said you did not want. A pod leaves you supplying product context to a squad we lead, which is less overhead than hiring and more relationship than a scoped delivery.

Pick the row that describes the next two quarters, not the row that describes the company you intend to be in three years. You can change path later, under the limits in the previous section, and you cannot get a refund of attention on a model that was answering a different sentence.

How do you decide, in order?

Use the flowchart as a checklist and stop at the first box that names your situation.

Write one sentence for what shipped means. If you cannot, do not pick a model yet. The evals guide is the method, and a week on the test will change which panel is honest.
If you want that system delivered and you do not want to hire or manage the people who build it, buy fixed-scope. Put the sentence from step 1 into the scope.
If you want people in your repository, ask whether a named lead on your team can set weekly priorities and review AI work. If yes, embed. The hire page is the operating detail: timelines, trial, replacement, IP.
If no such lead exists and the roadmap is real, take the CTO-led pod. You still owe product context. We owe the delivery rhythm and the hard technical calls.
If you expect the team path to grow, say so at the start. The published mechanism is the same people moving from one engineer to a squad, not a second vendor learning the system from scratch.

Two checks are worth running once you think the list is answered. First, if the sentence you preferred is about price, you have not finished step 1, because none of the three pages publishes a rate and a rate does not identify the model.

Second, if you want AI to be a permanent competency of your own team, the embed or the pod can cover the months while that hire is open, and neither one is the permanent design. That longer choice is the staffing guide.

Questions buyers ask

Which Bigcircle model should we pick?#

Pick from the homepage line that describes the next two quarters. Direction and a team, missing AI depth: embed. A roadmap and no senior AI leadership to run it: CTO-led pod. You want the working system and you do not want the hiring or the management: fixed-scope.

The engineers are one bench, and the models differ in who leads, not in who is allowed to touch production. If you are still choosing between us, a full-time hire, and an agency, use the staffing guide first and come back to this page after.

When is an embed enough?#

When your leads can set priorities and review the work, and the gap is depth in the repository rather than leadership. One to three engineers, in your timezone window, in your repos, with employment on our side. It stops being enough when the roadmap needs a squad and you still have no senior AI lead, which is the moment the hire page describes as scaling up without a reset, or when you realize you do not want to direct the work at all, which is fixed-scope.

When do we need the CTO-led pod?#

When the roadmap is real and nobody senior on your side can run it. The homepage's version is a managed squad of 3 to 8, engineers and QA, led by our founder as fractional CTO and architect. We own the delivery rhythm and the hard technical calls. You bring the product context.

The hire page prints the same idea as a squad of 4 to 8 and says accountability for each sprint is shared. Use either description as "a squad we lead," and do not buy it if you already have the lead and only need one more engineer.

When is fixed-scope the right buy?#

When you want the result and you do not want the hiring and management overhead, and you can say what shipped means before kickoff. The delivery is discovery, build, evals, and deployment under one point of accountability, at a fixed scope and price.

It is the wrong buy when the system will keep changing and nobody on your side will own it after acceptance, and it is the wrong buy when "done" is still a feeling. Write the test, or the fixed price has nothing to attach to.

Can we start with one model and switch?#

You can start with an embed and scale to a pod without resetting the people. That path is published on the hire page, and it has no published week number. The trigger is that the roadmap outgrew one engineer and you still do not have a senior AI lead. This site does not publish an automatic conversion between an embed and a fixed-scope contract.

A later fixed scope is a new acceptance test, not the next slide of the same engagement. Fixed-scope itself is chosen at the start, when the thing you want to avoid is management.

Who owns the code on each model?#

You do, on the terms in the hire FAQ: engineers work in your repositories under your IP and confidentiality terms, and we handle employment on the back end. "We own it" on the fixed-scope panel means we own delivery of the outcome, not the repository. "We lead" on the pod means we own the delivery rhythm and the hard technical calls, and you still bring product context and still own the code. If a draft contract says otherwise, the FAQ is the line to point at, and the diagram on this page is only as strong as that sentence.

Where to start this week

Bring the homepage line that describes you, and the system you need in production. If the line is about depth inside a team you can direct, start with the hire page and a shortlist. If the line is about a roadmap with no senior AI lead, say that on the first call so the conversation is about a pod and not about a single resume.

If the line is about a result you do not want to manage, bring a draft of what shipped means, even a rough one, because fixed-scope cannot be priced or accepted without it. A readiness assessment is useful before any of the three if you are not yet sure the use case should be attempted at all.