Buy or build: an honest tally of when in-house AI work pays

"Why not build this ourselves? We have two good engineers." You can. Sometimes you should. The dishonest version of this article pretends the marketplace always wins. The honest version names the cases where in-house is the correct call, then prices the cases where it is not.

The API call is the easy 20%. The other 80% is integration maintenance, evaluation harnesses, failure handling, audit logging, and re-testing every time a model ships. For a first workflow that has to touch a system of record, a planning range that survives a skeptical engineering manager is 6–10 engineer-weeks to get it out of the lab, then on the order of 15% of an engineer, forever, per workflow that must stay correct. Those are planning figures, not a study of your shop. If your engineers are cheaper, faster, and already live in those APIs, your numbers will be better. If they are the two people keeping billing alive, your numbers will be worse because the opportunity cost is the outage you did not staff.

What you are actually buying when you "just call the API"

A working weekend prototype is: a prompt, a PDF, a JSON blob, a screenshot in Slack. A production job is:

• Auth into QuickBooks, HubSpot, Gmail, Bill.com, or the warehouse system, with scopes you can explain to a customer MSA.
• Mapping that does not silently drop line items when a vendor changes a PDF layout.
• An exception queue with a named owner, not a channel nobody watches.
• Idempotency: the same bill does not post twice because a webhook retried.
• An eval set of real documents, a success rate, and a named failure mode you will defend in a QBR.
• Logs a controller can export. Retention you can print. A rule that customer data is not training data.
• A plan for model deprecation: the provider will retire the endpoint. Someone has to re-run the eval and switch, or the job dies.
• On-call: when it drafts a wrong amount, a person gets paged, not a thread that starts on Monday.

If you already operate that stack for other products, incremental cost is real but smaller. If you do not, the first workflow is a product, not a script.

When you should build

Build when at least one of these is true.

The job is the company. Your quoting engine is how you win deals. Your warehouse allocation is how you hit SLAs. Your claims logic is the product. Buying a generic "quote tool" would flatten the thing customers pay you for. Keep the 20% that is yours. Parts of every process are custom; those parts should stay with your team.

You already have the connective tissue. You have engineers whose job is the CRM and the ERP. You have a staging environment, secrets management, and someone who owns data handling. Adding one more worker on a trigger is then closer to the 20% than the 80%.

The volume or the documents are genuinely unlike the commodity pattern. If every vendor bill is a one-off legal instrument, off-the-shelf coding from the last 12 months of that vendor will fail. If you process 12 invoices a year, a person and a recurring template in QuickBooks is cheaper than any build or buy. Build (or buy) only where the hours exist.

You need the file to never leave the network, and you will run the stack. Self-hosted licensing exists for that constraint. Building your own may still be right if the constraint includes model weights, air-gapped inference, and a security team that will not accept a vendor binary. That is a real architecture choice. It is also a product team. Budget it as one.

You are in the business of selling this capability. If AI operations software is what you sell, you are not the buyer this catalog is for. You are a peer. Do not buy your own category.

When you should buy

Buy when the work is commodity hours that look the same at every 40–180 person company in your industry: reading a PDF, matching a line item, drafting a follow-up, routing a ticket, assembling an invoice that matches the last one to that customer, watching an AP mailbox, sending the reminder on the day AR said they would.

Those jobs are 80% of the hours and identical across the size band. They are not how you differentiate. They are how you leak margin.

Buy also when the scarce resource is not money but attention. A founder with four hours a month to evaluate anything cannot also be the eval harness. An ops director who will be fired for a missed SLA cannot spend a quarter as unofficial ML PM. The cost of the build is rarely the AWS bill. It is the roadmap you delayed.

Buy when the alternative is a consultancy engagement: custom artifact, three-to-nine months, a thing only they can maintain, in a $40k–$250k band. That path is the right answer for complex bespoke work. It is the wrong answer for "vendor bills into a draft in Bill.com." If the job has a name and a system of record you already pay for, a finished catalog item is the comparison, not a blank canvas.

A tally you can actually run

Do this on one page. No vendor ROI slide.

1. Name the job in buyer language. "Code vendor bills and open a draft." Not "unstructured ingestion."
2. Volume × minutes of the current human path. Example shape, not a customer result: 80 bills/month × 8 minutes to open, key, code, and route is 640 minutes, plus whatever you honestly spend chasing exceptions. If your volume is 20, do not keep the 80-bill hours.
3. Loaded hourly cost of the person who does it today. Loaded, not wage. Ask finance. If you type $25 because it feels conservative, you are lying to the model.
4. Build cost. Engineer-weeks × loaded engineering cost, plus 15%-of-an-engineer × 12 months for the first year of keep-alive. Include the retest when the model changes. If you omit that line, you omitted the actual product.
5. Buy cost. Licence or plan, plus credits/usage if the work is unattended, plus setup time as a published number, plus the hours that remain (exceptions, approvals, the awkward call the agent will not make).
6. Risk line. Wrong posting in the books, PII in a model provider, a champion who leaves. Price the governance work. If buy includes human approval, audit export, and a named failure mode, that is part of the comparison. If build skips it, you did not compare equals.

If year-one build is cheaper and the job is a differentiator, build. If year-one buy is cheaper and the job is commodity, buy. If they are close, prefer the option that does not consume the two engineers who keep billing alive.

What a catalog is not allowed to hide

A marketplace that only tells you to buy is a brochure. The honest version of nox.markets is: if it is your differentiator, build it. If it is invoice matching, buy it. If a product cannot fit your process, it should say so before you pay.

We sell tools, agents, workflows, and packs that are already integrated with systems you already use, with a time-saved rationale on the product page. A published eval is planned and not present. We do not staff your change-management program. We do not file your sales-tax return. Custom work is an Enterprise conversation, not how Starter or Growth is delivered.