The Issue: Your contract is protecting your vendor, not you.

Here's a scenario I see too often. A founder invests tens of thousands into custom-built software, bootstrapped money, money that matters, and the scope line in the contract reads something like:

"Build custom CRM."

That's it. One line. Maybe a handful of bullet points if they're lucky.

That single line is doing a lot of heavy lifting for a five-figure investment. And your vendor knows it.

What I See Every Day: Founders trusting vendors to fill in the blanks.

I speak to start-ups and scale-ups regularly, and this challenge comes up more often than it should. A founder has a great idea, finds a vendor, has a few promising conversations, sees a polished demo, and signs a contract. The vendor seems credible. The demo looked slick. Why wouldn't you trust them?

However, then something shifts. Functionality that was pitched as "out of the box" during the demo quietly becomes a custom build once the contract is signed. The project gets more complex. Costs creep up.

When I come in, I'll ask to see the requirements documentation, it doesn't exist. A design document? Nothing. A high-level architecture diagram? Blank faces. I'm not a software engineer, and I could sketch you a high-level architecture map in an afternoon, it is not a difficult thing for a vendor to provide. The fact they haven't should concern you.

The founders I speak to? When I point this out, I've seen embarrassment. I've seen anger. Because it's one thing for a founder not to have an IT delivery background, that's completely understandable. But the fact that a vendor hasn't done the bare minimum to look out for their client? That's a sucker punch to the chest.

I think this keeps happening because founders have a hundred things to balance, and IT delivery governance ends up falling through the cracks. If you have a technical co-founder, they're likely heads-down building the product, not necessarily overseeing how vendors structure contracts and deliverables. Nobody's dropping the ball deliberately. But the gap is real, and it's costing people serious money.

What Needs to Happen: Know what you're paying for before you sign for it.

Let's start with the basics. At minimum, your vendor contract should cover:

• Scope of work and deliverables: what's being built, what's out of the box vs. custom development, and what documentation you'll receive (design docs, architecture diagrams, requirements)

• IP rights: who owns what's being built? This catches more founders out than you'd think

• Payment terms and milestone structure: when do you pay, and what needs to be delivered before you do?

• Timeline and project management: how will the project be managed, how will progress be reported, and what are the key dates?

• Warranty period and testing process: what happens when something breaks after go-live, and how will the software be tested before it's handed over?

• Data protection: especially critical if you're handling customer data

• Maintenance and support: what happens after delivery? Who fixes bugs? For how long? At what cost?

If any of these are missing from a contract you're about to sign, stop and ask why.

Now, within that scope of work line, there's a distinction that trips up almost every non-IT founder I speak to: what's out of the box vs. what's custom development.

Out of the box means the functionality already exists, it comes as standard with the software. Custom means they're building it from scratch for you, and that's where cost, time, and risk all escalate. If your vendor hasn't made this split crystal clear, ask why. Because functionality that gets pitched as "out of the box" during a slick demo has a habit of quietly becoming a custom build once the contract is signed.

Beyond the software itself, your deliverables should include design documentation, a high-level architecture diagram, and a clear record of what was built and how. I'm not a software engineer, and I could sketch you a high-level architecture map in an afternoon, it is not a difficult thing for a vendor to provide. These documents are your safety net. Without them, you're entirely dependent on that vendor forever.

And finally, responsibilities on both sides. What does the vendor need from you to deliver? What are they accountable for? If this isn't written down, every future disagreement becomes a he-said-she-said.

A quick aside for founders planning to seek investment down the line, how you approach spending matters. Investors look at due diligence. A well-structured vendor contract and a clear procurement process signals you're running a serious operation. It's one of the reasons I've supported start-ups with formal RFP processes, even at an early stage.

Tip of the Week: Turn your vendor calls into a requirements list.

If you've already had conversations with potential vendors, chances are you discussed what you actually need, features, workflows, integrations. If those calls were recorded or transcribed (and most video call tools do this automatically now), you're sitting on a goldmine.

Take those transcripts, feed them into an AI tool, and use the prompt below:

It's not a perfect requirements document but it's a brilliant starting point, and it takes minutes.

Before you sign anything, compare that list to the scope in your contract. If there's a gap between what you discussed and what's written down, that's a conversation you need to have before the ink dries.

This is the first in my series, What Your IT Vendor Isn't Telling You, written for founders and non-IT leaders navigating software delivery without a safety net.

• If any of this sounds familiar, I'm happy to give you 20 minutes of my time to talk through whatever you're dealing with. No pitch. This stuff irks me, and I'd rather you had an experienced pair of eyes on it before it becomes a bigger problem.

helen.beckford@felicetteconsultancy.com 
www.felicetteconsultancy.com | www.linkedin.com/in/hebeckford