Question 1

Does this apply to Training and Audit too, or only to builds?

Accepted Answer

The discipline applies to all three offers: scope before we act, lead with evidence, and leave you owning the artifacts. The four phases on this page are the in-depth method for Build & Run specifically, when the work is to ship and operate AI in production. Training and Audit & Consulting are shorter engagements that share the same habits but produce different deliverables (a trained team, a sequenced roadmap).

Question 2

At the end, do we own the AI: the prompts, models, and evals?

Accepted Answer

Yes. The code is in your repositories from the first commit, the IP transfer is in the contract, and the handover includes the prompts, the eval suite, and the guardrails, not just a running endpoint. The point is that your team can change the system safely after we step back, including swapping in a better or cheaper model, without depending on us.

Question 3

Do you work on a fixed price or time-and-materials basis?

Accepted Answer

Both, depending on the engagement shape. Scoped deliverables (an audit, a defined-scope build) work on fixed price against a written statement of work. Open-ended engagements (a long-term build with an evolving roadmap, or a support retainer) work on T&M with a documented monthly ceiling. We are explicit about which model fits your project during phase one.

Question 4

What does the team composition look like during a typical project?

Accepted Answer

Two to four senior engineers full-time on the engagement, drawn from the discipline leads you can meet on the about page. There is no junior bench, no offshore overflow, and no separate project manager. The lead engineer on the project is your single point of contact and stays accountable from scoping through delivery.

Question 5

Do you sign NDAs and DPAs?

Accepted Answer

Yes. Mutual NDAs are standard before phase one begins. For projects that involve personal data, a Data Processing Agreement (DPA) is signed before any production data is touched, and our processing posture is documented in the security engineering page.

Question 6

What happens if scope changes mid-project?

Accepted Answer

Scope change is a structured event, not a surprise. Change requests go through a written change-order process that reviews the technical and timeline impact, and we sign on the change before we ship against it. We do not silently absorb scope creep, and we do not pretend the change was always in scope.

Question 7

Do you offer post-launch retainers?

Accepted Answer

Yes. After the defined support window, we offer ongoing engineering retainers for clients whose product we built, typically two days per week scoped to maintenance, security, and incremental feature work, with a documented monthly ceiling. We do not retainer products we did not build, because we cannot vouch for the underlying engineering.

Question 8

Do you guarantee timelines?

Accepted Answer

We commit to milestones with written acceptance criteria; we do not guarantee a date against an ambiguous scope. The honest answer is that any vendor who guarantees a date against a vague scope is either lying or planning to cut corners, neither of which is the engineering we want to ship. Once scope is defined, our delivery dates are reliable because we say no to scope changes that the timeline cannot absorb.

Question 9

Can we audit the code while it is being written?

Accepted Answer

Yes, you should. The code is in your repositories from the first commit, your engineers have read access, and we expect the CTO or accountable technical sponsor on your side to spot-review pull requests during the engagement. The visibility is the point.

How we work,
across every offer.

One path to
AI autonomy.

How the pieces connect

What each phase produces

Approach:
questions about engagement.

Let's build something.

One path toAI autonomy.