The SaaS demo is going great. The salesperson glides through dashboards, the ops director nods, someone says this could actually work. Then your dispatch lead raises a hand and asks the question that ends every software demo: can it handle our exception workflow, the one where a partial shipment splits across two carriers and billing needs a manual override? The salesperson's smile does not move, but the answer is some version of that is on our roadmap.
Welcome to the awkward middle of the build vs. buy software decision, the part with a third option nobody puts in the demo. The SaaS covers 70% of your workflow beautifully, the missing 30% is where your actual margin lives, and the custom dev shop just quoted $500k and nine months to rebuild everything, including the 70% that already works.
There is a door number three. An embedded engineer sits with your team, keeps the SaaS for the 70% it handles, and builds the missing 30% as tools your company owns, priced in weeks instead of quarters.
The one-paragraph answer: buy when the gap is small, build when your process is your product, and use an embedded engineer for the wide middle, where off-the-shelf is close but not close enough. The rest of this post is how to tell which situation you are actually in, with numbers.
The Third Option in the Build vs. Buy Software Question
Frame the three paths honestly. Buying rents a workflow designed for the median company in your industry; if you are the median company, stop reading and buy. Building from scratch means paying a team to rediscover everything the SaaS already knows, then owning a codebase you have to feed forever. The embedded path keeps the working parts, replaces the workarounds, and ends with assets on your balance sheet instead of a vendor's roadmap promise.
Scoring the Three Paths
Score each option on five axes, one to five, and write the scores down before anyone gets attached to an answer:
- Workflow fit. What share of your real process, including the ugly exceptions, does it cover on day one?
- Three-year total cost. Licenses plus implementation plus the labor of working around the gaps. That last line is where buy quietly loses.
- Speed to value. Weeks until someone does real work in it, not until go-live theater.
- Switching costs. If this fails in year two, what does leaving cost?
- Maintenance ownership. Who fixes it when it breaks at 4pm on a Friday, and what do they charge?
The 70-30 Rule
After watching a lot of these decisions, the pattern compresses into a rule of thumb. If the SaaS gap is under 10%, buy and accept the workaround; your edge is elsewhere. If the gap is 10-40%, that is embedded-engineer territory: big enough to cost real money, small enough to build in weeks. Above 40%, either you picked the wrong SaaS or your process genuinely is your product, and full custom earns its quote.
A quick worked example. A regional 3PL scores its dispatch workflow: the TMS covers load posting and billing, call it 65%, but driver check-calls, detention tracking, and customer ETAs live in a group text. That is a 35% gap, dead center of embedded territory. Six weeks of embedded work later the group text is a dashboard, the check-calls answer themselves, and the TMS stays exactly where it was, doing the two things it is genuinely good at.
The Money Math
Take a typical mid-size distributor, 60 employees, evaluating a quoting-and-dispatch workflow. Illustrative three-year numbers, the kind worth doing on your own spreadsheet:
- Off-the-shelf plus workarounds: $310k. Licenses $85k, implementation $40k, and $185k of workaround labor: two coordinators at roughly 12 hours a week each, re-keying data the tool cannot hold, at loaded cost.
- Full custom build: $620k. $480k to the agency across nine months, $140k in internal time, hosting, and the maintenance retainer they mention after the contract is signed.
- FDE engagement: $235k. A 90-day embedded build at $95k to close the gap, plus $20k a year of part-time upkeep, and the SaaS license you keep for the parts it handles.
The count-the-invoices method makes buy look cheapest. The count-the-hours method, the one that prices coordinator copy-paste time, usually flips it. If you want the full formula for your own numbers, the spreadsheet-ready FDE ROI calculation walks through it line by line, and the honest FDE cost breakdown covers what engagements actually charge.
When the Third Option Loses
Fairness time, because the middle path is not magic. It loses when you need a platform, not a tool: if three departments will run on this for a decade, buy the platform and staff the admin. It loses when nobody can explain the workflow out loud, because an engineer cannot build what the business cannot describe. And it loses when the engineer cannot get floor access, since a builder locked in a conference room with stakeholders is just an expensive consultant.
It also loses when the gap is genuinely tiny. Building custom software to avoid a $200-a-month annoyance is not strategy, it is vanity with a Git repo. Save the custom work for the gaps that show up in payroll.
Running the Play
If you pick door three, structure the engagement so it cannot become a retainer trap. Ninety days, scoped in writing, with a working tool live by week six or an honest conversation about why. Weekly demos to the people who will actually use the thing. And a handoff clause with teeth: the code lives in your Git org, the data in your database, the runbook written for your most technical employee, not for the engineer's replacement.
Pricing structure matters too, and the day-rate vs. retainer vs. outcome pricing comparison explains who bears the risk in each model. Whatever you pick, the test at the end is simple: your team runs the tool without the engineer in the building, and the workaround spreadsheet has not been opened in a month.
Build vs. buy was always a false binary. The companies that win the third option are the ones that counted their workaround hours honestly, and then stopped paying them.