Build vs Buy for GenAI: An Engineering Decision Framework

Build versus buy is really a three-way choice: buy a finished tool, configure a platform, or build custom software. The right answer differs by workflow, and often within one company.

Decision criteria

• Differentiation: does this workflow set you apart?
• Data: does it need deep access to your private systems?
• Change rate: how fast will requirements move?
• Compliance: where can data legally live?
• Time to value: what is the cost of waiting?
• Exit cost: how hard is it to leave a vendor?

Scoring

def recommend(c):
    """c: dict of 1-5 ratings. High 'differentiation' and 'data_depth' favor building."""
    build_pull = c["differentiation"] + c["data_depth"] + c["change_rate"]
    buy_pull = c["time_pressure"] + c["commodity"] + c["small_team"]
    if build_pull - buy_pull >= 4:
        return "build"
    if buy_pull - build_pull >= 4:
        return "buy"
    return "configure a platform"

Treat the output as a conversation starter. The ratings are judgments, and the thresholds are examples.

Hidden costs of buying

• Per-seat pricing that grows with adoption.
• Limits on customization and on how your data is used.
• Integration work to connect it to your systems.
• Dependence on the vendor's roadmap.

Hidden costs of building

• Maintenance: models, libraries, and APIs change often.
• Evaluation and monitoring that you must build.
• Security review and compliance for custom code.
• Staffing: people who understand both the domain and the stack.

A hybrid pattern

Buy for commodity tasks such as meeting notes and general drafting. Build for the few workflows that use your proprietary data or define your service, and put them behind a thin internal gateway so models and vendors can be swapped.

Exit planning

Whatever you choose, keep your prompts, evaluation sets, and data exports under your control. They are the assets that make switching possible.

A worked comparison

Take a contract review assistant. A packaged legal AI product might deliver value in weeks, with predictable per-seat pricing, but limited ability to use your clause library and playbooks. A configurable platform could ingest your playbooks and let you tune the workflow, at the cost of integration and setup. A custom build gives full control over data, workflow, and evaluation, and demands engineering capacity and ongoing maintenance.

• Choose the packaged product if your needs match the standard feature set and speed matters most.
• Choose the platform if you need your own content and workflow but not custom infrastructure.
• Choose custom when the workflow is a competitive differentiator, the data is highly sensitive or specialized, or integration needs are deep.

Total cost over three years

Compare options on a three-year horizon with the same cost model: licences or build costs, integration, run costs, internal staff time, and the cost of switching later. Include an adoption scenario with twice the expected users, since per-seat prices and usage-based charges can change the ranking.

def three_year_cost(upfront, annual_run, annual_staff, annual_license=0, growth=1.0, years=3):
    total = upfront
    for y in range(years):
        total += (annual_run + annual_staff) * (growth ** y) + annual_license * (growth ** y)
    return total

Proof before commitment

Whichever direction looks right, run a time-boxed proof on your own data with a fixed evaluation set. For a vendor, make that a paid pilot with exit rights. For a build, make it a four-week prototype with a go or no-go review. Evidence from the proof should drive the decision.

Questions for each path

• Buy: how does it handle our permissions, our data residency, and our audit needs? What can we export?
• Platform: how much of the workflow is configuration versus code? Who maintains it?
• Build: who will own it in year two? What is our plan for model changes and evaluation?

Reversibility

Prefer decisions that are cheap to reverse. Keep prompts, evaluation sets, and data in formats you control, put a gateway between your applications and any model or vendor, and avoid designs where only one supplier can run your core workflow. If the choice does turn out to be wrong, switching should be a project, not a crisis.

How we can help

We run a short build-or-buy assessment for a specific workflow, with a costed comparison and an exit plan, and we implement the build side when that is the answer. Contact us to scope it.