You’re not buying a project. You’re giving someone keys.
A vendor quoted $82,523 to rebuild software that already worked. Here’s how to vet a vendor before you sign — and before they get access to anything.
You’d background-check a bookkeeper
You would. Someone handling fifty grand a year of your money gets references, a trial period, maybe a credit check.
Then a development firm shows up with a proposal and gets admin credentials, a copy of your database, and a standing connection into your network. And the vetting is “do we like the price?”
That’s backwards. The bookkeeper can steal from you. The vendor can take the whole business down — and usually walks in with more access than anyone you’ve ever hired.
Most businesses have no way to vet a vendor
They have a way to compare quotes. That’s not the same thing, and the difference is expensive.
When a proposal arrives, the owner evaluates the proposal — scope, price, timeline, references. What almost nobody evaluates is the decision underneath it: whether the work needs doing at all, whether something already owned does most of it, and what the business is signing up to own forever once the invoice is paid.
Those questions don’t get asked because of who’s in the room. A vendor quoting an $82,523 project is paid to answer one question: what will we build? Nobody present is paid to answer the other one: what does the client actually get?
That’s not dishonesty. It’s incentive. The firm writing the proposal makes money when the project happens and makes nothing when the honest answer is “you already own something that does most of this.”
What $82,523 was going to buy
A marine terminal operator ran a line-of-business application. On-premises, .NET front end, SQL behind it. Old, but working.
They asked an outside development firm what to do about it. Two options came back.
Keep the on-prem stack. Bolt cloud services onto it for OCR and mobile.
Move the database to the cloud, rewrite the application.
Both were competently scoped. Both were priced honestly. Neither answered a single question that mattered to the business.
Read your last proposal again. Does it say what you asked for?
Somewhere at the start of that engagement, the client sat down with the firm and explained the situation. What was slow. What was manual. What it was costing them.
None of that was in the proposal.
The document went straight to architecture — options, components, prices. It never restated the problem in the client’s own words. It never said what the business would be able to do afterward that it couldn’t do now.
That’s the tell. A proposal that doesn’t reflect your problem back at you wasn’t written for you. It was assembled from a menu.
Go pull the last one you received. Read the first page. If it opens with what they’d build instead of what you said was broken, you’re holding a quote, not a plan.
The four questions they never answered
What’s broken right now? The app worked. “Aging” isn’t a business case. If you can’t say what the company can’t do today, you’re paying to rebuild something that already does the job.
Does this already exist for sale? Nobody checked. There’s a market of SaaS products doing most of what that application did. The honest scope was probably: buy the thing that covers the common 80%, custom-build the piece that’s actually specific to running a marine terminal.
How does this fit what we already run? They were already paying for Microsoft tooling. Nobody checked whether licenses already on the invoice could do part of it.
Who runs it after you leave? Both numbers were build costs. Neither said who operates it, who patches it, or who picks up the phone when it stops at 6am.
Ask a builder what to build and you’ll get a build
That’s not a scam. It’s a menu.
A development firm’s revenue scales with how much gets custom-written. “Buy this product for a few hundred a month and we’ll bridge the gap” is the single recommendation that costs them the project. It doesn’t get proposed — not because anyone’s dishonest, but because nobody in the room is paid to propose it.
Which is why the buy-versus-build question can’t be asked of the person quoting the build.
How I’d have run it
Not a counter-quote. A different order of operations.
- Write the problem down first, in their words. Then hand it back and ask whether it’s right. If the client can’t agree with the problem statement, nobody should be pricing a solution yet.
- Ask what changes when it’s fixed. Hours back, revenue unlocked, risk retired, a person freed up. If nobody can name it, the project doesn’t have a business case — and that’s a finding, not a delay.
- Inventory what they already pay for. Licenses, platforms, the tools sitting on the invoice that nobody is using.
- Survey what’s already for sale. Somebody has probably built most of this and sells it for a few hundred a month.
- Scope custom work to the gap only. Whatever is genuinely specific to this business, and nothing else.
- Decide where it lands before building it. Which platform, and who supports it on day 400.
- Then price it.
Run in that order, here’s what came out for this client. The first two steps aren’t development at all.
They were running a self-managed backup product that wasn’t what we’d have recommended, on a server that was already aged. Before you move anything, you need to be able to put it back. Replace it with a cloud backup covering the entire Microsoft tenant and the bare-metal server.
Now the migration has a safety net underneath it.
Survey the SaaS market for the common 80%.
Only what’s genuinely specific to running a marine terminal, and nothing else.
On Microsoft platform and licenses they already owned, serviceable by the MSP already on retainer. Cheaper than either option on the table, and more than Option A delivered.
Here’s the part that should bother you: both proposals moved a production database to the cloud, and neither said a word about backup.
Nobody quotes “fix your backup first” when they’re pricing a rewrite. It isn’t billable to them. It’s also the step that makes every step after it survivable.
The number isn’t the point. The order is. Price is the last question, and it kept getting asked first.
And none of this is an argument about programming languages. Python’s fine. The firm was fine. It’s about where the finished system lands — Option B drops something into the business that the people already supporting the business can’t touch. You didn’t buy a project. You bought a vendor you can’t leave.
Where this came from, and what my stake was. I was Technical Director at the MSP that supports this client — running MSP operations and serving the clients as their CIO. We were engaged on their business continuity plan when the development proposal came across the desk.
So I already knew two things about that environment: the backup they were running wasn’t what we’d have recommended, and the server was aged. Neither was a discovery. That’s just what you know after sitting in the CIO seat for a client.
At Dawn never asked about either one. Their proposal moved a production database to the cloud without addressing what it was running on or whether it could be restored.
And my own incentive — since this whole piece is about incentives. I wasn’t bidding on the build. But a recommendation that keeps the work on a platform the existing MSP can support is a recommendation that favors the existing MSP, and that was us. Weigh the argument on its merits rather than on my neutrality, because I didn’t have any.
My tenure ended before the client decided. Nobody saved $82,523, and a piece about vendors overstating what you get isn’t going to overstate what happened.
And that’s what the seat is for. Whoever evaluates a proposal should know the environment it lands in — and should be asking about the parts the proposal doesn’t mention.
Because here’s the general rule underneath this whole thing: what a vendor doesn’t ask about is what they won’t be accountable for. At Dawn didn’t ask about backup or server age. That wasn’t an oversight. It was scope.
The real question isn’t the quote. It’s the perimeter.
Every vendor you bring in gets inside something. Credentials. Data. A network path. A seat at the table where decisions get made.
Procurement treats that as a purchase. It’s an access decision wearing a purchase order.
And here’s the part nobody says out loud. Verizon’s 2026 Data Breach Investigations Report found that 48% of breaches involved a third party — with third-party involvement up 60% year over year.1
Not your staff clicking a link. Roughly half the time, it came through somebody you let in.
So the question was never “is $82,523 a fair price.” It’s who are we letting inside, and what do they have to answer first.
Ten questions to vet a vendor before anyone gets a key
If a vendor can’t answer these in a first meeting, that’s your answer.
- What access do you need, and why that much?
- Who at your company touches it — employees, or subcontractors you don’t control?
- Where does our data sit, and whose data sits next to it?
- What happens to your access the day the project ends?
- Does a product already do most of this? And what would it cost to buy it and build only the gap?
- What do we already own that does part of this?
- Who maintains it when you’re gone — us, our current provider, or only you?
- What does year three cost?
- What happens if you get breached? Who calls us, and how fast?
- What does leaving you look like?
None of it is technical. All of it is answerable in a first meeting. Most vendors have never been asked.
Does this sound like something happening in your organization?
If there’s a proposal on your desk and nobody’s asked who’s getting the keys, that’s the conversation to have before the purchase order. Not after.
This is the work — sitting on your side of the table while vendors sell to you, and staying long enough to be accountable for whether the call was right. That’s what a fractional CIO does.
If you want that done for your business, start with the CIO Review — two weeks, a flat fee, and the four questions answered in writing.
Book a call- Verizon, 2026 Data Breach Investigations Report — 48% of breaches involved a third party; third-party involvement up 60% year over year. Verizon newsroom · full report (PDF)