A lot of software projects are evaluated around the wrong question.
Can it be built?
That question matters, but it is often not the question that kills the project.
In many business systems, especially internal tools, workflow platforms, healthcare coordination software, operational dashboards, and custom enterprise applications, the bigger risk comes later.
Will anyone actually use it?
That sounds simple, but it is not. It is the point where many otherwise promising projects start to stall.
The software exists. The screens work. The data model is mostly right. The workflow is close enough to test. But the users do not enter the data. Managers do not enforce the process. Sales teams keep using spreadsheets. Operations teams keep using paper. The founder keeps asking for the next feature before the current version has become part of daily work.
At that point, the failure is no longer primarily technical.
It is organizational.
The product can work and still not become real
There is a strange stage in software development where the product is functional but not yet real.
It may have a working login flow, database, permissions, reporting, and mobile interface. It may even solve the stated problem. But until people change behavior around it, the product is still only a technical artifact.
This is especially common in systems that replace messy internal workflows.
A company might say it wants to replace spreadsheets, clipboards, phone calls, text messages, and manual reporting. A developer can build the replacement. But the organization still has to do the hard part: move people from the old workflow into the new one.
That requires ownership, training, accountability, and repetition.
Without that, software becomes shelfware with a better UI.
The second death valley
Early software projects often face a first obvious risk: can the team build the thing at all?
Many projects die there. The architecture collapses. The budget runs out. The prototype never becomes usable. The team cannot execute.
But there is another stage after that.
The second death valley is adoption.
This is where the system exists, but the organization has not absorbed it.
The signs are familiar:
The pilot is “lightly used.”
The data is incomplete.
The team wants to move to version two before version one has been tested.
The manager says the users are too busy right now.
The process still depends on one champion pushing everyone manually.
The software is described as promising, but nobody can point to consistent daily usage.
This stage is dangerous because it can look like progress. There are meetings, demos, feature discussions, roadmap ideas, and excitement. But the actual question remains unresolved.
Has the workflow changed?
Funding does not solve adoption by itself
A project can be funded and still die here.
Funding proves that investors, owners, or executives believe there may be something worth building. It does not prove that users will change behavior.
That distinction matters.
A startup can raise money and still fail to convert pilots into real usage. A company can spend heavily on a custom internal system and still have employees revert to spreadsheets. A founder can believe deeply in the product and still underestimate the organizational work required to make the product stick.
This is why “going full time” into an early product can be risky for an engineer or consultant. If the remaining risk were mostly technical execution, deeper engineering commitment might solve the problem. But if the dominant risk is adoption, then concentrating your life around that company means stepping directly into a risk path that code alone cannot fix.
At that point, the question is not:
Can I build it?
The question is:
Will the organization adopt it?
Software adoption requires an owner
The strongest signal that a product is moving from build phase to adoption phase is not another feature request.
It is operational ownership.
Someone inside the business must own the rollout. That person must care whether data is entered, whether users follow the process, whether old workflows are retired, and whether the new system becomes the source of truth.
Without that person, the developer becomes a false owner of adoption.
That is a bad structure.
A developer can build the system, improve the workflow, fix bugs, design safer data handling, and advise on rollout. But the developer cannot make the organization care. The developer cannot force the sales team, operations team, schedulers, vendors, clinicians, or managers to use the system every day.
That has to come from the business.
The wrong response is always “more features”
When adoption is weak, the natural temptation is to build more.
More dashboards. More automation. More alerts. More polish. More integrations. More version two.
Sometimes that is necessary. But often it avoids the harder truth.
Version one has not been operationalized.
If version one is not being used, version two may only create a larger unused system.
A better question is:
What specific behavior must change for this product to become real?
Then:
Who owns that behavior change?
Then:
What evidence shows it is happening?
Only after that does the next feature set become clearly justified.
How this changes project evaluation
For a consultant, this changes how anchor clients should be evaluated.
A good anchor is not just a client that pays consistently. It is a client whose product or internal system is moving through the adoption hurdle.
That means looking for signs like:
People use the system without being begged.
The data becomes operationally important.
Managers ask about missing usage.
Old workflows are retired.
Customers or internal teams would feel pain if the system disappeared.
The system becomes part of how the business runs.
Those are stronger signals than excitement, funding, feature requests, or founder conviction.
The honest consultant position
The healthy position is not cynicism.
It is sequencing.
Keep building for pay. Keep improving the system. Keep helping the client move forward. But do not confuse technical progress with business adoption.
A product that has not crossed the adoption threshold may still become valuable. It may still deserve work. It may still be worth supporting.
But it is not yet a stable foundation for major personal risk.
That is the difference between a good paid consulting engagement and a full-time commitment.
Until adoption is real, the right answer is often:
I am happy to keep helping build this.
But I am not ready to concentrate my life around it.
The real milestone
The milestone is not the demo.
It is not the funding round.
It is not the feature list.
It is not the founder’s enthusiasm.
The real milestone is when the product becomes embedded in actual behavior.
That is when the risk profile changes.
Because software does not become valuable when it is merely built.
It becomes valuable when people organize their work around it.
