What we look for in a software project before we say yes

Not every software project should be built. The most expensive ones are the ones built well that nobody actually needs. Before we agree to a custom development engagement, we work through the same set of questions.

The questions

1. What is the business outcome? Not the feature. The outcome. Reduce close-of-month from 5 days to 2 days. Cut the time to onboard a new client in half. Concrete.
2. Has anyone tried this with off-the-shelf tools? Custom is expensive. Off-the-shelf is often a 70 percent fit at 10 percent of the cost.
3. Who will use it on day one? If the answer is vague, that is a warning. Usage assumptions need to be specific.
4. Who will own it after we hand it off? Nothing kills internal software faster than ambiguous ownership.
5. What does success look like in six months? If we cannot agree on this, we cannot build the right thing.

When we say yes

When the outcome is clear, alternatives have been considered, ownership is defined, and success is measurable. When we say no, it is usually because one of those four is missing and worth resolving before any code gets written.