Straight answers, before you have to ask for them.

An agency sells capacity: you bring the plan, they staff it. We will not take a build brief we do not believe in, and every engagement starts with a diagnostic that can conclude you should not do the project at all. The people who scope the work are the people who deliver it.

In almost every case, yes. It is short, fixed-price, and ends in a document you own whether or not we work together again. Quoting a build before understanding the constraint is how engagements go wrong, and we would rather lose the deal than start there.

Typically companies between roughly $2M and $100M in revenue, plus funded startups past their first product decisions. Below that, the honest answer is usually that a full engagement is not yet the right spend, and we will say so.

Frequently, and it is usually the better outcome. We work alongside in-house teams, reviewing architecture, taking the pieces they lack capacity for, and raising the standard of delivery practice rather than routing around it.

Diagnostics can usually begin within two to three weeks. Delivery phases are scheduled against current commitments. We run a small number of engagements concurrently and will tell you the real date rather than an optimistic one.

Remote-first, with on-site time where it genuinely helps: kickoff, the diagnostic interviews, and the working session where the recommendation is stress-tested. Most delivery work is better done remotely with a strong written cadence than in a room with poor documentation.

Your team runs the system. We hand over documentation and run a walkthrough, and we stay reachable. Many clients return for a later phase; none of them are required to.

Yes, and it happens. A declined engagement costs everyone less than a bad one, and a firm that has never talked a client out of something is a firm that sells capacity rather than judgment.

Only where a specific workflow justifies it. The useful question is not whether AI could do a task but whether the task runs often enough to pay back a build, whether a plain script would do the job more cheaply, what a wrong output costs, and whether anyone can define what a correct output looks like. If a workflow fails any of those four tests, automate it conventionally or leave it alone.

In unglamorous internal operations rather than customer-facing features: reading unstructured inbound documents and email, classifying and routing high-volume intake, extracting data from non-standard formats, and drafting first passes that a person edits. These have high frequency, tolerable error cost, and a checkable definition of correct.

Buy when the workflow is standard across your industry and a vendor's product already fits it. Build when the workflow is specific to how you operate, when vendor pricing scales with your headcount rather than your usage, or when configuration costs are already approaching the cost of building. Frequently the best answer is to buy the platform and build only the thin layer that is genuinely yours.

A two-week assessment to find and size the opportunity typically starts around $9,000. A production pilot on a single workflow, with real integration, an evaluation harness, and monitoring, typically runs $25,000 to $60,000 over four to eight weeks. Ongoing inference costs at those volumes are usually tens to low hundreds of dollars a month.

Data handling rules are set at the start of the engagement, in writing: which data can leave your environment, which providers may process it, whether any of it may be retained, and what is logged. We use providers with contractual terms against training on customer data, and we design around not sending sensitive fields at all where the workflow does not need them.

In most mid-sized companies it removes hours from roles rather than removing roles, and the hours it removes are usually the ones nobody wanted. We would rather scope automation around a capacity constraint you are already feeling than around a headcount reduction, because the first is measurable and the second tends to produce systems people quietly work around.

With an evaluation harness: a fixed set of real inputs with known-correct outputs, scored automatically so quality is a number you can watch rather than a feeling. Without one, a prompt change, a model upgrade, or a shift in your input data can degrade quality silently and you find out from a customer.

Model providers upgrade and retire models on their own schedules, which can move quality without warning. We pin versions where the provider allows it, re-run the evaluation suite before adopting a new one, and set alerting so drift is visible. Any vendor who describes model upgrades as purely automatic improvement has not thought about this.

Almost never at mid-market scale. Retrieval over your own documents, careful prompting, and structured output solve the large majority of business workflows at a fraction of the cost and complexity. Fine-tuning becomes worth considering when you have a large volume of high-quality labelled examples and a narrow, stable task.

Usually one of four things, none of them technical: no operational owner accountable for adoption, no success metric agreed before work started, testing on exported sample data rather than live systems, or a budget that covered the demonstration but not the evaluation and deployment work that production requires.

You do, in full, on payment. Source code, infrastructure, accounts, credentials, and documentation transfer to you at handover. We keep no license requiring you to stay with us.

By what your team can maintain after we leave, not by what is interesting to build. That usually means widely-used, well-documented technology with a large hiring pool. Where a client already has a stack and in-house skills, we work within it unless there is a specific reason not to, and we state the reason in writing.

Scope changes get priced at the moment they are proposed rather than argued about at the end. Phases are short enough, four to eight weeks, that most changes can wait for the next one, which is a large part of why we structure work that way.

No, and the handover is designed so you do not. You receive architecture notes, runbooks, and a walkthrough with your team or your next vendor. Some clients keep us on a small retainer for continuity; it is a preference, never a dependency.

Budget roughly 15 to 25 percent of the original build cost annually for dependency updates, small changes, integration repairs, and hosting. Any build-versus-buy comparison that omits this line is understating the cost of building.

Often, yes, starting with an assessment of what is there. Inherited systems need an honest read on architecture, test coverage, security posture, and how much of the original intent is documented. Sometimes the recommendation is to maintain and extend; sometimes it is to replace one component at a time. We will not tell you to rewrite everything by reflex.

There is a written weekly update whether or not there is a meeting, saying what moved, what did not, and what we are worried about. Progress is measured in deployed software, not in percentage complete. Bad news arrives early and in writing, because a schedule slip you learn about in week three is one you can still solve.

Fixed price per phase, agreed in writing before work starts, invoiced on a schedule set in the statement of work. Retainers are monthly. We do not bill hourly, because hourly billing rewards the wrong thing.

Diagnostics start around $9,000 and run two to six weeks, with a full strategic diagnostic starting at $18,000. Fixed-scope delivery phases start around $40,000 and run six to ten weeks. Retained advisory starts at $6,500 a month and the fractional CTO seat at $9,000, both on a three-month minimum. These are starting points; the diagnostic exists so that the number you are given reflects the actual shape of the work.

Because hourly billing pays a firm to take longer, and it makes you responsible for policing that. Fixed scope puts the estimating risk on us, which is where it belongs, and it means a conversation about approach never has a meter running.

Phases are short and end at a decision point, so stopping is a normal outcome rather than a dispute. You pay for the phase in progress, you keep everything produced to that point, and the handover obligations still apply.

We guarantee the scope in the statement of work at the price in the statement of work, and we guarantee that everything produced transfers to you. We do not guarantee business outcomes, because those depend on decisions and market conditions we do not control, and any firm promising otherwise is selling you something.

Yes to NDAs, before any detailed discussion of your business. We are equally willing to work under your master services agreement or ours, whichever gets to signature faster.

Takes the seat: standing presence in leadership and architecture forums, accountability for delivery, technical due diligence on what exists, role definitions and technical interviews for hires, and vendor evaluations with the tradeoffs written down. Decision rights are agreed in writing at the start so it is clear what the role can and cannot commit to.

When technology is the product, or when the engineering team passes roughly eight to ten people and running the organisation becomes a full-time job. Before either condition, a permanent hire usually buys more capacity than judgment at several times the cost, and a mis-hire at that level costs the better part of a year.

Typically one to two days a week, on a recurring schedule, with a three-month minimum reviewed quarterly. Retainers start around $9,000 a month for the fractional CTO seat.

It is designed to. Every fractional engagement includes, from the start, a written specification of what your permanent technical leadership should look like and how to get there. An arrangement with no off-ramp is not a bridge, it is a subscription.

Yes, and it is one of the highest-value parts of the role. That means writing the role definition, screening for real depth, running the technical interviews with you, and giving you a defensible read on candidates rather than a gut feeling.

Yes. That is an honest read on architecture, delivery practice, security posture, key-person risk, and technical debt, with severity and remediation cost attached rather than a list of observations.