What To Expect When You Commission Custom Software
Custom software has a reputation for surprises. It does not have to. Here is how a well run project actually unfolds, from the first conversation to launch.
Custom software has a reputation. Late, over budget, and not quite what anyone asked for. That reputation was earned by projects that tried to specify everything up front, build in the dark for months, and reveal the result at the end. There is a better way to do it, and it is worth knowing what it looks like before you commission anything.
It Starts With Listening
A good partner does not open with a proposal. They open with questions, and they keep asking until they can explain your problem back to you in your own words. If someone quotes you a price before they understand the process the software has to support, be cautious. The price is a guess and the software will be too.
A Written Scope, In Plain Language
Before work begins you should receive a written scope that a non technical person can read. What the software will do. Who will use it. What is included and, just as important, what is not. Costs, timelines, and how changes will be handled. This document protects both sides. It is the thing you point to when memories differ.
The Smallest Useful Thing First
The single biggest predictor of success is how quickly real users touch working software. A well run project identifies the smallest version that proves the idea on real data and builds that first. Not a prototype that will be thrown away. A thin slice of the real thing.
This does two things. It surfaces wrong assumptions while they are cheap to fix. And it gives you something to show your own stakeholders within weeks rather than months.
Working Demos, Not Status Reports
You should expect to see the software regularly, running, with someone walking you through what changed. A status report says the project is 60 percent complete. A demo shows you the 60 percent and lets you react to it. If a partner resists showing work in progress, ask why.
Change Is Normal
You will learn things during the project that you could not have known at the start. That is not a failure of planning. It is the reason to build in stages. A healthy process expects change, prices it honestly, and lets you decide whether each change is worth it.
What You Should Own At The End
Everything. The source code, the data, the hosting accounts, and documentation good enough that another competent developer could take over. Lock in is a business model, not a technical necessity. Ask about ownership before you sign, not after.
Launch Is A Beginning
Software meets reality on launch day, and reality always has notes. Expect a support arrangement with clear terms: what is covered, how quickly issues are addressed, and what ongoing improvement costs. A partner who disappears after launch was never really a partner.
How To Tell A Good Partner
They ask more than they tell. They say no to things that would not help you. They show you working software early. They write things down. And they are as clear about what they will not do as about what they will. That is what to look for, and it is what we try to be.