Two industrial conduit runs diverging on a plant wall, one continuing straight and one branching away.
Two routes. One of them is cheaper than it looks.
Build vs. buy

Should you build this in-house?

Sometimes the answer is yes, and any agency that tells you otherwise is protecting its own invoice. Your team can ship more today than it could two years ago, and that is a real change rather than a marketing one. Here is where we think it holds, and where we have watched it break.

Build it yourself when

These four are all true

The interface already exists

If the system you need has documented, public APIs, your team plus a good coding model will get there. That is genuinely true now and it was not true three years ago.

Nothing regulated is in the path

No hazardous materials, no multi-state tax obligation, no payment capture, no customer data carrying compliance weight.

Someone owns it in eighteen months

Not the person who builds it. The person still there after they move on. Internal tools die of orphaning far more often than of bad code.

The failure mode is inconvenience

A broken page is embarrassing. A broken order-to-cash path is revenue and a customer relationship.

Where it reliably breaks

Any one of these changes the maths

The interface does not exist yet

A model can only work with the surface it is given. One client’s pricing lived inside a system built in-house over decades with no API at all. Somebody had to specify one, justify it to an engineering team that did not report to them, and stay in the room through the build. That took months before a line of website code mattered. No amount of model capability shortens it.

The rules were never written down

Which customer gets which price. Which products cannot ship together. What your best rep does when a freight quote comes back high. AI cannot extract what was never recorded. Someone has to sit with the person who knows and ask the questions the sector taught them to ask.

Something regulated sits in the path

Hazmat acknowledgement, arbitration capture, sales tax nexus mapped state by state. “The model generated it” is not a position you can take with an auditor. Someone has to be accountable in writing, and that is a commercial arrangement rather than a technical one.

It has to still be running in five years

Generating the code is the cheap part now. We have operated a client’s live real-time infrastructure continuously since 2020. That is not a repository, it is a commitment, and it is the part that does not compress.

There is a third answer

Hiring for this properly means a senior developer, an integration specialist, and somebody who already understands your ERP. That is three people and the better part of a year before the first thing ships. A fixed project has the opposite problem: the work stops when the statement of work does, and the system keeps needing to change.

Most of our clients run a retainer instead. A standing share of a senior team, sized to what the business needs this quarter, without carrying the headcount through the quarters when it doesn’t.

We use the same models your team does.

We run our own agency on a system we built with them. We produce client instructional video through a pipeline that writes and assembles itself. Our project intake is read, triaged and queued by agents before anyone opens it. None of that is positioning, it is how the work gets done here.

So the difference is not access to better tools. It is fifteen years of pointing them at manufacturers specifically, the standing to get an interface built inside somebody else’s company, and staying on the hook once the thing is live.

If your problem is in the left column, build it. We mean that. If it is in the right column, the cost of finding out the hard way is usually measured in a selling season.

Nobody scopes the hard part

Standing up a storefront is a solved problem. Plenty of shops do it well and cheaply, and if that is genuinely your project you should hire one.

A manufacturer's project rarely stays that project. It turns into an integration project somewhere around month four, when the catalogue arrives, or the configurator does, or somebody asks where the price comes from. The team was picked in month one.

We are worth the most exactly where that bar runs out. Not at the top, where we are an expensive way to buy something ordinary. If your project really does stop at row one, we will say so on the call.

The same project, month by monthShops that can take it from here
  1. 01A new site and a rebrand You choose a vendor here
  2. 02The full catalogue has to go in
  3. 03Products are configured, not stocked
  4. 04Pricing has to come from the ERP
  5. 05The ERP has no interface to call The project is here
Nobody scopes row five. They scope row one, pick a vendor for row one, and arrive at row five about a year later with the wrong team in the room.

If the project has gone quiet, it is usually recoverable

This is one of the more common ways we start, and the pattern repeats closely enough to describe. An engagement led by the rebrand runs for a year. The CMS gets delivered standing but close to empty, so the marketing team ends up learning it and loading their own content. Ecommerce turns out to be a separate phase at a separate six-figure number, and what arrives is a storefront bolted alongside the site rather than built into it. By the time anyone asks direct questions, the account manager has changed twice and the answers have become contractual rather than technical.

If that is roughly where you are, the useful thing to know is that starting over is rarely necessary. We have taken over a partially delivered build, stabilised it, moved the commerce onto the same system as the catalogue and rebuilt the ERP integration underneath it. Work that has already been paid for is not always lost, and finding out costs you a conversation.

One practical note, because it is usually the thing people have stopped expecting: you will deal directly with the person doing the work.

Questions worth asking any firm, including us

If a vendor cannot answer these with specifics, that tells you what you need to know.

  1. Which of your integrations required building an interface that did not previously exist? Name the system.
  2. What are you still operating today that you built more than three years ago?
  3. What have you declined to build, and why?
  4. When something you shipped broke outside business hours, who picked up?

Ours are a ventilation manufacturer’s in-house pricing system that had never exposed an interface to anything, a trading platform’s live audio infrastructure running since 2020, projects we have turned down for being a redesign rather than a problem, and Benito, who is usually the one who picks up. We name the companies on a call, not on a web page.

Not sure which column you’re in?

Describe the process. We will tell you honestly if your team should keep it.

Start a project