Most software proposals we see describe the technology in detail and the work hardly at all. There is a section on AI, a section on the cloud set-up, a diagram of services, and one line about improving efficiency. Nobody has written down what the dispatch team does at nine on a Monday morning. Six months after launch, that missing page is usually why the new system sits open in one tab while the old spreadsheet does the real work in another.
Why proposals lead with technology
A technology list is easier to write. It can be carried over from the last proposal, it compares neatly against a rival quote, and it sounds current. Describing the work means sitting with the people who do it, which takes a day or two that nobody has budgeted for.
Buyers ask for it as well. When the MD asks whether the system will use AI, the vendor says yes, because no is a hard word to say in a sales meeting. Both sides leave with a technology agreed and the job still undescribed.
In my view the technology list is the least risky part of a proposal. Most competent teams can build well with most modern stacks. Projects go wrong in the gap between what the software does and what the business needs on an ordinary working day.
What a poor fit costs after launch
The cost rarely arrives as a failure. The software works. It does not match how the work runs, so people work around it, and the workarounds are where the money goes.
| What you see | Where it shows up | Who pays |
|---|---|---|
| The old spreadsheet stays open beside the new system | Month-end reconciliation | Finance, in overtime |
| The same data is typed into two places | Error reports and customer calls | Operations and support |
| Everyone asks one colleague how to handle the unusual cases | That colleague's calendar | The whole team, when that person is on leave |
| A second project to fix adoption | Next year's budget | Whoever signed off the first one |
The last row is the expensive one. The cost shows up later, under a different budget line, and the original decision is never questioned.
Start from the work the system has to support
Before anyone writes a feature list, sit with the people who will use the system and write down one working day. Note what arrives (an email, a WhatsApp order, a phone call), which tools they open, what they type and where, who they ask when something is unclear, and what they do when it goes wrong. Spend most of your time on the exceptions. The normal path is easy to build, and the exceptions are where the side spreadsheet survives.
Doing this regularly changes the brief. WONDR Media asked us for a Python script to collect player photos for their NBA videos. The first conversations showed two things a script would have missed. A photo has to match its moment, so a recently traded player must appear in his new team's jersey, and a piece about a past season needs photos from that season. And seven to ten editors would be running it, none of them developers. A script handed to that team would have been shelved within a month. We recommended a web app built around how an editor searches, and the WONDR project story describes what came out of it.
Put each expectation in terms someone can check
Words such as AI-powered, real-time and scalable describe the software. They do not tell you whether it did its job. An expectation the business can check names a person, a task and a result you can see on a normal day.
- AI-powered order processing
- Real-time stock dashboard
- Modern platform built to scale
- An emailed order is entered once, by one person
- Stock on screen matches the warehouse count at closing
- Month-end close needs no side spreadsheet
Write the right-hand column before anyone discusses the stack.
Each line on the right gives you something to test at sign-off. Agree who signs off, and against which lines, before development starts. If you leave it to the last week, the argument is about opinions instead of results.
Websites have a job too
Website projects fall into the same habit. The proposal lists animations, a headless CMS and a page builder where the purpose should be. A business website usually has one main job: help a particular visitor understand the offer well enough to take one action. Every section should be judged against that action.
The ProfitLeverPro website we built had an unfamiliar product to explain to business owners and CEOs: a simulator that shows how one decision moves operating, investing and finance results together. A paragraph about simulation would not have made that clear to someone without a finance background. So the homepage carries a small model the visitor can adjust. Move a slider and the return on equity changes in front of them.
The action shaped the form as well. The client's demos go best when the prospect brings a real decision, so the demo request asks one open question, the decision you want to test, with an example in the placeholder. Nothing on the site was chosen to look modern. Each section was there to get a prepared visitor to that form.
When AI or a new technology belongs in the plan
None of this argues against AI or any other technology. It is an argument about order. A technology earns its place when it removes or shortens a step someone does today, and when someone can check its output.
WONDR shows the order working. The AI layer came after the search tool was in daily use. Gemini tags each saved image with the player, team, action and setting, so editors search their own library by keyword instead of paying for a new web search. That feature had a step to remove and an easy check: the editor either finds the photo or does not.
If a vendor cannot name the step a technology removes, ask them to leave it out of the first release. You can add it once the workflow has settled. Taking something out after launch is much harder, because by then somebody has built a habit around it.
Questions to ask before you approve a proposal
Take the proposal to your next review with these questions. A vendor who has done the groundwork can answer them in a few minutes.
- Describe one working day of the people who will use this, in their words. Who did you get it from?
- For each feature, which step that happens today does it remove or shorten?
- For each technology named, what does it do in our workflow, and what would we lose without it?
- Which exceptions have you planned for, and which will stay manual?
- When will people use the first release for real work? Put a date on it.
- Who signs off, and against which expectations?
Be honest with yourself about the answers. A vague reply to the second question usually means the feature came from a template. A long pause on the fourth means nobody has met the users yet.
Where to start this week
Pick the one process that annoys your team most, the one with the spreadsheet everybody keeps just in case. Ask the person who does it to walk you through last Tuesday, step by step, and write it down. Mark the step that takes longest and the step that goes wrong most often. That page is a better brief than any technology list, and it is the first thing worth handing to a development partner.
