What Would It Take?

A client recently came to me with a fairly straightforward question:

What would it take to build this?

They had a specific business need, an idea for how to solve it, and a deadline. So we started there.

We worked through what the solution actually needed to do, who would use it, how it would be managed, and what a reasonable first version would look like. It was completely feasible. A focused first version looked like roughly 50–75 hours of development, with more likely to follow as it was used, refined, and connected to other systems.

That gave us one answer to the question. But once the requirements were clear, we also knew enough to ask whether there were other ways to solve the same problem.

We looked at several existing products. Some weren't a fit. Others were close but had limitations that mattered. Eventually we found one that appeared to cover most of what the client needed.

Appeared to wasn't enough. There were still questions about some of the requirements, so we worked through those with the vendor and confirmed what the product could and couldn't do.

Two viable paths

Now there were two viable paths, and they solved the problem in different ways.

A custom application would take longer and require more investment upfront, but it was the stronger long-term solution. The client would have control over the experience, could shape it around their own processes, integrate it more deeply with their other systems, and continue developing it as the offering evolved. If this became an important part of their business, custom software gave them a platform they could build on.

The existing product offered almost the opposite tradeoff. It came with more restrictions and less control, but it could be put into use almost immediately. The client had an opportunity in front of them and didn't have to wait for a custom application to be designed, built, tested, and deployed before they could start offering the capability.

So this wasn't really a choice between a good solution and a bad one. The custom application was arguably the better long-term answer. The existing product was the better answer if the priority was getting started now.

The better answer for now

The client had a deadline and a decision to make. Our job was to make the options and tradeoffs clear enough for them to make it.

They chose the existing product.

We helped configure it, worked through the remaining details, tested the process, and had a solution in place in time for what they needed. They could move forward with the opportunity now rather than waiting for the longer-term solution.

That doesn't mean the custom application was the wrong idea. If the offering grows, the limitations of the existing product may eventually outweigh the advantages of using it. At that point, greater control and deeper integration could justify building something specifically for the business.

Or the existing solution may continue to be good enough.

The question behind the question

Answering the build question meant going a little further: What would it take to solve the problem? What other options were available? What would each one require? What would the client gain or give up with each choice?

Sometimes the right answer is the solution that gives you the most control for the future. Sometimes it's the one that lets you solve today's problem today.

What would it take?

By the end, there wasn't one answer. There were two viable paths, each with a different cost, timeline, and long-term tradeoff.

The value was in understanding where each path could lead before choosing one.