HOW WE WORK
Outcome-based delivery. Sized to the problem.
Two accountable principals with a specialist bench behind them, an agreed metric, and visible outcomes in weeks rather than quarters.
9 hrs/week
In production today
Admin time returned to staff in a live community-to-CRM build.
40+ products
Catalog records restructured so shopping agents can read specs, stock, and terms.
Evaluated before launch
Nothing goes live until it clears a documented eval threshold on your own data.
You own it
Code, data, connectors, and runbooks stay in your accounts after handover.
THE ARC
Define → Design → Build → Measure
Every engagement runs these four phases. How long each takes, and how many cycles you run, depends on the problem, not on a template.
Define
We inventory the signals you already generate, agree the metric that matters, and write the constraints down.
Signal map · success metric · constraint list
Design
Architecture, agent graph, data contracts, and the evaluation plan that will prove the system works.
Architecture doc · agent graph · eval plan
Build
Production deployment with observability and guardrails from the first commit, not retrofitted later.
Deployed system · dashboards · runbook
Measure
We report against the metric we agreed in Define. If it did not move, we say so and fix it.
Outcome report · iteration backlog
WHERE YOU START
Your industry decides the pattern. Your readiness decides the first engagement.
Most businesses arrive somewhere on this ladder, including at stage zero, with real demand and no system to hold it. We scope to the stage you are actually at, not the one the brochure assumes.
One question
Where does your customer signal live today?
Your answer sets your starting line, then four short questions decide which pattern applies.
The Ladder
← Swipe to view stages →
ENGAGEMENT MODELS
Five ways to work with us.
Fixed price is our default because it removes the incentive to bill hours. Each model states the team shape it usually carries, the core pair is the constant, everything around it is sized to the assignment.
Fixed-price sprint
A scoped outcome with an agreed price and date. The core pair leads; specialists are costed into the price where the scope needs them, so the number you approve is the number you pay.
Typical team · 2 core + 1–2 specialists as scoped
Good fit · Audits, pilots, first production system
Retained capacity
A monthly block of senior time you direct across a roadmap. The team shape is re-cut every cycle, more data engineering one month, more front-end the next, without renegotiating a contract.
Typical team · 2 core + rotating specialists per cycle
Good fit · Ongoing iteration, multi-system programmes
Embedded pod
A standing squad working alongside your team: the core pair plus dedicated engineers, design, and security review for the length of the build, in your rituals and your repos.
Typical team · 4–8 people, scaled up or down mid-flight
Good fit · Larger builds, regulated environments, tight internal handover
Programme delivery
Several workstreams running in parallel under one architecture and one accountable principal, for example commerce integration, identity data, and governance moving at the same time.
Typical team · Multiple pods, one architecture owner
Good fit · Multi-quarter transformations, several systems at once
Enablement and training
Cohort workshops and pair-building so your team can run and extend what we ship, with us on call rather than in the critical path.
Typical team · 1–2 facilitators + practitioner guests
Good fit · Teams that want capability, not dependency
TEAM SCALINGTwo owners. As many hands as the work needs.Our two-person model describes accountability, not capacity. Open this for how a team is assembled around it for any assignment.Show the layersHide the layers
Core pair
Two senior people own the engagement: architecture and delivery. They scope it, they build it, and they stay to the last commit. This never changes.
Scoped specialists
During Define we name the crafts the build needs, data engineering, integrations, front-end, security, design, change enablement, and the hours each requires. They join for those phases only.
Studio and network
Fractal KX studio operators and our vetted practitioner network extend the pod when depth or parallelism is required, under the same contract and the same accountability.
Your people
Where you have capable engineers, we pair rather than replace. Blended pods are normal and usually cut both cost and hand-over risk.
FIT
Who this is for, and who it isn't.
Self-select fast. We would rather you close the tab today than discover the mismatch in week three.
A good fit
- Roughly 10–200 people, with an owner who can decide without a committee.
- An active community, storefront, or audience already producing signal, Discord, Slack, support inbox, reviews, DMs.
- Systems we can reach: a CRM, commerce platform, or database with API access.
- Budget starting at the fixed audit price for a diagnosis, and a named person on your side for two hours a week.
Not a fit (yet)
- Pre-launch with no live community, customers, or data to work from, there is no signal to connect yet.
- Looking for staff augmentation, hourly bodies, or a subcontracted dev shop. We sell outcomes, not seats.
- A single chatbot on a website with no downstream systems. Buy an off-the-shelf tool and keep the money.
- No internal capacity for two hours a week, start with Training, from $297 instead.
THE HONEST COMPARISON
Why not just build this in-house?
Our most common alternative isn't another agency, it's your own team getting to it next quarter. Sometimes that's the right answer. Here's how to tell.
Build it in-house
Right when you have engineers with spare capacity, someone who has shipped an agentic system to production before, and no urgency on the date. The cost is rarely the licences, it's the six weeks spent learning evaluation, tracing, and identity resolution the hard way.
Buy a platform
Right when an off-the-shelf tool already covers your exact workflow end to end. In the community-signal category specifically, the products that served mid-market buyers have consolidated, moved upmarket, or shut down, check before you assume one exists.
Bring us in
Right when you want the architecture decided correctly once, a working system in 30–60 days, and your team paired into it so they own it afterwards. You keep the code, the data model, and the runbook. We are not a dependency by design.
THE FINE PRINT, IN PLAIN WORDSWhere we flex, and where we don't.Scope is agreed before we start. If scope changes, we price the change before doing the work, no surprise invoices, no discovery billing, no bench you're paying to keep warm. Open this for the eight questions we get asked most.Show the fine printHide the fine print
What if the timeline needs to be longer than 60 days?
Then it is longer. 30–60 days is our typical time to a visible outcome, not a ceiling. Larger programmes are sequenced into outcome-sized stages so you see value before the whole thing lands.
Do we always get exactly two people?
No. Two senior people always own the engagement, but the delivery team is sized to the assignment, a typical build runs four to eight people across engineering, data, design, and security, and programme work runs several pods in parallel. The pair is your accountability layer, not the headcount ceiling.
How do you scale the team mid-engagement?
Capacity is reviewed at the end of every phase and every retainer cycle. If a workstream is under-served we add the craft it needs, usually within a week, and you see the revised team sheet and cost before anyone starts.
Who are the specialists, exactly?
Named practitioners we have delivered with before, drawn from the Fractal KX studio and our own bench, not anonymous subcontractors. You get their names, their role on your build, and direct access in the working channel.
Can you scale down again?
Yes, and we do it by default. Specialists roll off as soon as their phase closes so you are never paying for idle capacity, while the core pair carries continuity and context forward.
Can you work inside our process and tooling?
Yes. We fit into your sprints, ticketing, repos, and review gates. The four phases are how we think, not a ritual we impose on your team.
What if scope changes mid-flight?
We price the change before doing the work, including any team change it implies. Small in-scope adjustments are absorbed; anything material becomes an explicit decision with a number attached, made by you.
Can you take over an existing build?
Often. We start with a short architecture read of what exists, tell you plainly what is salvageable, and price the path from there.
NEXT STEP
Still deciding if we're a fit?
The fit check tells you which stage you're at, including when the honest answer is 'not yet'.