The Issue: No design document, no test evidence, no idea what was actually built.

Imagine you've invested in a restaurant. The chef has cooked the dishes, the menu is printed, and the doors are about to open. But there are no recipes. The chef knows how each dish is made because they created it. But if that chef leaves tomorrow, the next person walking into that kitchen has nothing. They'd have to taste every dish, reverse-engineer every ingredient, and guess how it all comes together.

That's exactly what happens when your software vendor builds you a system and doesn't provide a design document.

I see this constantly. A founder asks me to look at what's been built. I ask for the design documentation. It doesn't exist. There's no diagram showing how the systems connect. No written explanation of what was configured out of the box versus what was custom-coded. Nothing that a new developer could pick up and understand without going line by line through the code itself.

If you don't have a design document, you don't know what was about to be built before it was built. And once it's built, you don't know how it was built. That's a massive risk if you ever want to switch developers, bring in additional support, or simply understand what you've paid for.

What I See Every Day: Vendors who've never experienced the consequences.

I'll be honest. I think the reason most vendors don't provide design documentation is because they've never been burned by not having it.

They built the system. They know how it works. They maintain it. They've never been in the situation where a client leaves and a new developer has to pick up the pieces. So they've never felt the pain of missing documentation.

I hold myself to a high standard. When I leave a client, I document what I've done so they're not left with questions. My measure of success is that the client no longer needs me. When I see vendors not doing this, I see it as a lack of experience in post-implementation support, and sometimes, if I'm being blunt, laziness.

I also have experience working in regulated environments where documentation isn't optional. It's evidence for audits. The consequence of not having it can be fines or a business being shut down. Not every start-up operates in a regulated space, but the principle is the same: if you can't show what was built and how, you're exposed.

What Needs to Happen: The recipe, the taste test, and the review.

Let me extend the restaurant analogy because it makes the whole thing click.

Your requirements are the menu items. What dishes are you serving? (Covered in newsletter #2.)

Your design document is the recipe. What ingredients (systems) are being used and how do they come together? At minimum, your vendor should provide:

• A diagram showing how the systems connect to each other

• A written explanation of what is being built

• A clear split of what is configuration/out of the box versus what is custom code

This doesn't need to be a 50-page technical specification. It needs to be enough that if your vendor disappeared tomorrow, a new developer could look at it and understand what they're working with.

Your test evidence is the taste test. And this is where it gets interesting, because testing isn't one activity. It's a series of steps, and the responsibility shifts between your vendor and your business.

Think of it like this:

• Unit testing (the vendor's job): Testing the quality of individual ingredients. Does each component work on its own? Your vendor should be doing this as they build, piece by piece.

• System integration testing (the vendor's job): Testing the cooked recipe. Do all the ingredients work together? Do connected systems talk to each other properly?

• User acceptance testing (your job): The restaurant owner tastes the full dish before putting it on the menu for a customer to purchase. This is where you or someone in your team tests the software from the perspective of a real user. Get the people who will actually use the system involved if you can.

• Pilot testing (your job, with real users): Invite guests you trust. Run a small, controlled test with real users in real conditions.

I cannot stress this enough: test in the real environment, not just ideal conditions. I learned this the hard way. Early in my career, I tested a mobile application entirely from the office on high-speed WiFi. Everything worked perfectly. Then I joined an engineer in the field on go-live day and it fell apart. Why? They use the app on mobile signal, not WiFi. The engineers lost confidence in the solution almost immediately, and that directly impacted the customer experience. Lesson learned: test in real-life conditions or you'll find the problems when your users do.

• Penny testing: Test it in the live environment for a tiny amount. The name comes from listing a product at 1p (this could be on Amazon, your own website or another channel), purchasing it yourself, and watching whether the order syncs to your ERP, flows to your warehouse, gets shipped. For the restaurant, it's testing the dish during a real night of service alongside every other order. Does the kitchen hold up?

Now, here's the important caveat. Not all of these stages will be possible for every start-up or scale-up. You may not have the team, the time, or the budget for a full testing cycle. That's okay. Be pragmatic. Match your level of testing to the size and pace of your business. But do something. Even a basic walkthrough with a test user is better than going live blind.

Before your vendor hands anything over, ask them for a demo of the build first. Watch them walk through it. Then test it yourself. And ask them to share screenshots or screen recordings of their own testing with a test user. That's your test evidence. If a bug is found later, you want to be able to point to a specific test transaction, a specific order number, a specific scenario and say "this was tested and it passed" or "this was never tested."

Tip of the Week: Ask your vendor three questions before you accept anything.

Before you sign off on a delivery, a phase, or a go-live, ask your vendor:

If the answer to any of these is no, or "we don't usually do that", you now know where you stand.

To help you evaluate what your vendor has provided (or hasn't), use this prompt:

This is the third 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 genuinely 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