The Issue: Nobody documented what you actually asked for.
Here's something I see over and over again. A start-up invests serious money into custom software. The vendor builds it. Something goes wrong the first time a customer uses it. The founder turns around and says "this isn't what I asked for."
And then I ask the question: "Can you show me where the requirements are documented?"
Blank stare. Maybe someone points to an email chain, a Slack thread or a call recording. Maybe nothing at all.
Without documented requirements, you cannot prove what you asked for. You cannot test whether what was built is correct. And you cannot argue that something is a bug rather than a missing requirement, which means your vendor can charge you more to "fix" something that should have been included from the start.
What I See Every Day: Retrospectively building what should have existed from day one.
I previously supported a start-up that had custom software built. The vendor is a good person. Genuinely well-intentioned, responsive, wants the best for the client. But when I came in and asked to see the requirements documentation, there was almost nothing to point to. The contract scope was broad. Conversations had happened, but nobody had written down what was actually agreed.
So weeks into an active build, I was running weekly sessions to capture requirements that should have existed before a single line of code was written. We were sitting on calls asking "as a user, what do I actually need this system to do?" while the system already existed.
The founder was anxious. They felt that something was off but couldn’t articulate exactly what, because there was no baseline to measure against. The vendor was saying "I delivered what was asked for" and in fairness, without documented requirements, how would either side prove otherwise?
This is what happens when the process is skipped. Even with good people on both sides, everyone ends up frustrated.
I think this keeps happening for two reasons. First, founders assume that "standard" software doesn't need documented requirements. A CRM is a CRM, right? Why write anything down? Second, founders assume the vendor has captured what was discussed in sales calls and discovery sessions. They trust the vendor to handle this, and most vendors should, but many don't.
What Needs to Happen: Write it down. In any format. Before the build starts.
Here's the good news: your requirements document doesn't need to be a 40-page enterprise specification.
I advise a founder right now who recorded a Loom video walking through what they needed and shared it with their developer via email. That's it. It's not a formal document. But it means they have something to reference when the developer says "it's done" and they're not sure it is.
The point is not the format. The point is that something exists, in writing or on record, shared in an evidencable way (email, not a passing comment on a call) that captures:
What you need the software to do. Focus on the must-haves. The things that, if they don't work, you cannot go live. I recommend writing these as user stories: "As a [type of user], I want to [action] so that [outcome]." It forces you to think about who is using the system and why, not just what buttons to press.
What is out of the box vs. what is custom. If you read the first newsletter in this series, you'll know this distinction matters. If your vendor hasn't split this out, ask them to. It directly impacts cost, timeline, and risk.
What "done" looks like. How will you know the software is finished? What does the vendor need to deliver before you sign it off? If you can't answer this question, neither can they.
A good vendor will take whatever you provide, turn it into a structured format, and build on it. They'll add requirements they know from experience. A common CRM vendor, for example, should have a standard set of requirements they know their software delivers. They should be proactively sharing that with you, not waiting to be asked.
If your vendor isn't doing this, that tells you something.
One more thing: before you sign with any vendor, ask to speak to their existing customers directly. Find them on LinkedIn if you have to. Don't rely solely on references the vendor provides. Ask those customers one simple question: "What do you wish you'd known before you started working with them?" The answers will tell you everything.
Tip of the Week: Turn your working software into a requirements document.
If you're reading this and thinking "it's too late, the software is already built", it's not too late. You just need to work backwards.
If your software already exists but you never documented requirements, you can retrospectively build that baseline. This matters because without it, you can't test properly, you can't evaluate whether what was built is what you needed, and you can't brief a future vendor if you ever need to move on.
Open your software, walk through every screen and feature, and use this prompt:
Context: I am a non-technical founder. I have custom software that has been built for my business, but the original requirements were never formally documented. I am going to describe what the software currently does, screen by screen or feature by feature. [Describe your software here, or paste in screen recordings/screenshots if your AI tool supports it.]
Role: Act as an experienced IT business analyst who specialises in helping non-technical founders document and evaluate software that has already been built.
Action:
Based on my description, create a retrospective requirements document. Write each requirement as a user story: "As a [type of user], I want to [action/feature] so that [benefit/outcome]."
Group the requirements by functional area (e.g. user management, reporting, integrations, notifications).
For each requirement, flag whether it appears to be working as described or whether I've indicated any issues.
After listing what exists, suggest 10 requirements that are commonly expected for this type of software but that I have not mentioned. These are potential gaps.
Finally, generate a list of 10 questions I should ask my vendor to clarify how specific features were built, where data is stored, and what happens if something breaks.
Format: Present the requirements in a numbered table with columns for: Functional Area, User Story, Status (Working / Issue Flagged / Unknown), and Notes. Present the gap analysis and vendor questions as separate numbered lists.
Target Audience: The output should be written in plain English that a non-technical founder can understand, challenge their vendor with, and use as a baseline for future testing.
It won't replace having done this properly from the start. But it gives you a foundation you didn't have yesterday, and that foundation will save you time, money, and arguments from here on out.
This is the second 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.