How to Evaluate a Software Development Proposal When You're Not Technical

You have a quote in front of you. Maybe three of them. One is forty thousand, one is ninety, and one is a hundred and sixty for what sounds like the same thing.

You can’t tell which one is right. Not because you are not smart, but because the documents are not written to be compared. They are written to be signed.

I get asked to look at these fairly often, usually by someone who has already read the proposal four times and is now reading it a fifth to see if the discomfort goes away. It doesn’t. Here’s what I look for, and what you can look for without knowing anything about software.

---

The number is the least useful part

Start here, because it saves a lot of wasted worry.

You can’t tell whether a price is fair by looking at it. Neither can I, not from the number alone. Two vendors quoting the same project can be building genuinely different things, and both can be honest.

A cheap proposal for something badly defined is the most expensive thing on your desk. You’ll pay the difference later in change requests, and by then you have no room to push back, because changing vendors halfway through costs more than the change request does. Everyone in this industry knows that. Some of them price for it.

---

What does a software proposal have to define?

If any of these is missing, the proposal isn’t finished, and you are allowed to say so.

What it does, in your words. Not features. Outcomes, described the way your staff would describe them. “Volunteers can sign up for a shift and get a reminder” is a scope. “Volunteer management” is not a scope, it’s a category.

What it does not do. A good proposal tells you what’s out. If there is no exclusions section, one of two things is true: they haven’t thought about it, or they are leaving room to charge you later. Ask for it in writing and watch how easily it comes.

Who owns the software, and what happens if they disappear. Ask directly and get it in writing. There are three common answers, and what matters is not the category but what each one does to you.

You own it: if the relationship ends, you can hand everything to another company and carry on. You rent it: it keeps working while you keep paying, and stops when you stop, so the annual fee is not really optional. They own it and you have no rights: if they close or you fall out, you start again.

In all three, ask the separate question about your records. Your donor data should be yours, exportable in a normal file format, on request, without a fee. Get that sentence into the contract even if everything else is fine.

What happens after launch. This is the one that is almost always vague, and it is the one that decides your real cost. Who fixes it when it breaks in month seven. What that costs. How fast they respond. Whether the price is fixed or hourly. A project that costs sixty thousand and then eighteen thousand a year forever is a different decision from one that costs ninety and then two. And it’s usually the harder one, because the upfront number can often come from a grant or a designated reserve, while the annual number has to come out of unrestricted money, which is the tightest dollar you have.

What happens to the records you already have. This is the one that hurts, and it’s missing from most proposals. You have years of donors and volunteers spread across a system somebody bought in 2009, four spreadsheets, and one person’s memory. “We’ll import your existing data” is not a plan. Ask how many records they’re expecting, who is responsible for cleaning them up before the move, who checks afterwards that they arrived intact, and what happens to the ones that can’t be matched. Then ask what that costs, because the honest answer is often a meaningful fraction of the project, and the dishonest answer is that it’s included.

What they need from you. Every software project fails partly on the customer’s side. A proposal that does not tell you how many hours of your staff’s time it needs, and from whom, is going to surprise you. If your operations lead needs to be available two days a week for four months, you want to know that before you sign, not in week three when she is already behind.

What it is built on. Not so you can judge it. You can’t, and you shouldn’t have to. It’s there so you can ask one question out loud: if we had to hand this to a different company in three years, how many firms could pick it up? You don’t need to understand the answer. You need to watch whether it’s a number or a speech.

---

The questions to ask

You don’t need technical questions. You need questions that are hard to answer vaguely. These six are the ones I actually use, and you can send most of them by email.

What is the smallest version of this that would still be useful to us, and what would that cost?

The best question on this page. A good vendor will engage with it and will often talk you down. A vendor who can’t break the project into a smaller first piece either doesn’t understand it or doesn’t want to.

What is the riskiest part of this project?

Everyone in software knows where the risk is. Someone who says there isn’t any is either inexperienced or managing you.

Which parts of this are you buying rather than building?

Almost every project assembles pieces that already exist, and that’s good news: less to build, less to go wrong, and someone else maintaining the hard parts. What you want to know is which pieces, because each one is a company you now depend on and usually a fee that recurs. Ask what happens if one of them raises its price or shuts down.

Who will actually do the work?

You are often shown senior people and delivered junior ones. That isn’t automatically bad, but the answer should be a real one, with names and a rough split of who does what.

What happens if we stop halfway?

What do we have. What can we use. What do we own. If the answer is nothing, then your payment schedule is the only protection you have, so pay in stages tied to things you can see working rather than to dates in a calendar.

Can you show us something like this that you built, and can we talk to that client?

And then actually make the call. Ten minutes with a previous customer will tell you more than the whole document. Ask them one thing above all: what did it end up costing, all in.

What are the warning signs in a software proposal?

A fixed price with a vague scope. These two can’t both be true. Either the scope is tight enough to price, or the price is a guess and one of you is going to lose. Usually you, because they have done this more times.

No discovery phase. For anything sizeable, a vendor quoting a firm number without a paid week of understanding your situation is either recycling a previous project or guessing. Paying a small amount to find out what you actually need is nearly always the cheapest money in the whole project.

The demo answered a question you didn’t ask. Impressive isn’t the same as suitable. If you went in asking how staff would do a specific job and came out having watched charts move, notice that.

Everything is bespoke. Sometimes custom is right. But if a vendor is proposing to build from scratch something you could buy for a monthly fee, they should have a reason, and “so it fits you exactly” isn’t a reason on its own. It fits you exactly today. You are also the only customer it will ever have, which means you fund every improvement forever.

Nobody asked whether you need software at all. A surprising amount of what gets quoted as a system is really a handful of repeated tasks, and some of those are worth automating and most are not. A vendor who sells software will propose software. That’s not dishonesty, it’s just the shape of who you asked.

Urgency that comes from their side. Discounts that expire, a team that is available this month and not next. Real constraints exist. But your project timeline should be about you.

You cannot understand the proposal. This is the one people ignore because they assume the problem is them. It usually isn’t. Anyone who is good at this can explain what they’re going to build in plain language. Complexity in the document often means complexity in the thinking, and you’ll be paying for that complexity for years.

---

The thing nobody tells you

You’re allowed to say no slowly.

The pressure in these conversations is almost always toward deciding, because the vendor wants a decision and you want the discomfort to end. There is usually a board meeting in it somewhere too, and a feeling that turning up without a recommendation looks like you have not done the work.

It doesn’t. Turning up and saying we asked all three what the smallest useful version would cost, and one of them couldn’t answer, is doing the work. That is a finding. Boards understand findings.

But usually nothing bad happens if you take three more weeks. Just make it a decision rather than a drift: if your committee meets quarterly, three weeks can mean three months, so say out loud which meeting you’re aiming for. Nothing bad happens if you ask for the exclusions in writing and they take a week to send it, and you learn something from the fact that it took a week.

The most expensive technology projects I have seen weren’t badly built. They were badly decided, early, by someone who felt they had to be decisive in a room where they were the only person without the vocabulary.

You don’t have to have the vocabulary. You have to have the questions, and you have to be willing to sit in the silence after you ask one.

So, the three quotes on your desk. You are not going to pick between them by comparing the numbers, because they aren’t describing the same thing. Send all three the same two questions: what is the smallest version of this that would still be useful to us, and what does year two cost. Then compare the answers rather than the documents. The gap between how those three replies read is usually larger and more useful than the gap between the prices.

If you want someone technical reading the proposal with you, that is what a technology assessment is for. Sometimes the answer is that the price is fair and the vendor is good and you should sign. Sometimes it is that you don’t need the project at all, which is a strange thing to pay someone to tell you and usually the most valuable version of the conversation.