Build vs. buy: a dealer portal

A developer on staff, or a cousin who "does web stuff," makes building your own ordering portal look free. Here is what the honest math looks like once it's actually running your order flow.

Why build looks free at the start

If you already have a developer on staff, or someone on the team who builds things on the side, a dealer portal looks like a weekend project: a login page, a product table, an order form that emails you when it's submitted. The first version usually does get built, and it usually does work well enough to show a buyer. The cost that build-vs-buy comparisons miss isn't the first version — it's everything after it ships.

What keeps costing money after launch

A wholesale ordering system that's live and taking real purchase orders needs more than uptime. Someone has to add every new SKU, fix pricing when a rate changes for one buyer, handle the buyer who says they can't log in on a Tuesday afternoon, and keep the whole thing working when a browser update breaks a form that hasn't been touched in a year. None of that is a one-time cost. It's a recurring claim on whoever built it — usually the same person who was already doing their actual job before the portal existed.

The single-owner problem

Most in-house dealer portals are maintained by one person. That's fine while they're around. It stops being fine the day they leave, take extended leave, or simply get pulled onto something else for a month and a pricing bug sits unresolved because nobody else understands how the exceptions were set up. A system that takes purchase orders and feeds pricing to buyers is business-critical the moment a buyer depends on it — and business-critical software owned by exactly one person is a risk most distributors wouldn't accept anywhere else in the business.

When building it yourself is the right call

Build-vs-buy isn't a one-sided argument. If your ordering workflow is genuinely unusual — tied tightly to a proprietary quoting process, or bundled into a larger internal system you've already invested years into — and you have a development team whose job already includes maintaining internal tools, building makes sense. The math works when the team exists regardless of the portal, not when it's assembled specifically to build one.

What buying is actually paying for

Dealer portal software built for welding and industrial distributors is priced to cover exactly what a homegrown system quietly defers: catalog and pricing changes that take effect the moment you make them, a buyer login that keeps working without anyone maintaining it, and support that doesn't depend on one person's schedule. The comparison isn't "free" versus "a monthly cost" — it's an unpredictable, deferred cost that lands on one person's desk, versus a fixed one that doesn't.

• Build makes sense when: a development team already exists for reasons beyond the portal, and your ordering workflow is unusual enough that off-the-shelf software would require heavy workarounds.
• Buy makes sense when: your workflow is standard for the industry — negotiated pricing, restricted catalogs, PO-based ordering — and no one's job is to maintain internal software full time.
• The real cost to weigh: not the first version's build time, but who fixes it, updates it, and answers for it eighteen months from now.

The question that settles it

The question worth asking isn't "could we build this." Most distributors with any technical help could. It's "who owns this in two years, and what happens the week they're out sick and a buyer's pricing is wrong." If there's a confident answer to that, building may be the right call. If the honest answer is "whoever's around," that's the cost build-vs-buy comparisons tend to leave out.

See how buyer access and pricing work in SupplyDesk →