What Makes a Software Project Successful?

A successful software project is not simply one that gets delivered. It is one that solves a real problem, produces meaningful evidence, and earns the right to keep going.

One of our clients was growing. That was the good news.

We had been their technology partner for more than three years, and as their business grew, something else was growing with it: the number of questions that needed answers.

Some came directly from our client. They wanted to understand how something in their software worked, whether a business requirement could be supported, or what it would take to make a change.

Others originated with their own customers. A customer would ask them a question. They would bring it to us. Someone on our team would investigate, find the right person, gather the necessary context, and respond.

For a while, that worked. Then volume started to catch up with us.

The people who knew the answers were still there. The problem was getting the right question to the right knowledge quickly enough. Requests accumulated. Some answers took days. Occasionally, they could take weeks.

Our client was growing, but neither they nor we wanted the number of people supporting the operation to grow proportionally with it. That seemed entirely reasonable.

If every increase in demand requires a corresponding increase in headcount, software isn't creating much leverage.

So we had a problem worth solving.

The obvious solution wasn't necessarily the right first step

The obvious answer might have been to add more people. Another increasingly obvious answer today would have been:

“Let's build an AI assistant.”

We did neither. At least not at first.

The first problem wasn't AI

When we looked more closely, we realized something important. The knowledge required to answer most of these questions already existed. It was just scattered.

Some of it lived in the heads of people on our team and some with people on the client's team. Business discussions were buried in Slack conversations. Technical documentation existed in Notion and Google Drive. More knowledge lived inside the software repository itself.

What looked like a capacity problem was partly a knowledge problem.

We had people repeatedly doing the work of finding, reconstructing, and explaining information the organization already knew.

So our first intervention wasn't sophisticated. We started documenting what we knew.

We held a session internally and another with the client. We divided the knowledge into categories. Within each category, we identified common questions and documented the answers.

We began turning tribal knowledge into organizational knowledge. Only after doing that did an LLM become useful.

We connected it to the relevant technical and business sources and made it accessible to our client directly through Slack. Now they could ask questions where they were already working.

This is the distinction we try to make when thinking about AI system development : intelligence creates value when it becomes part of an actual workflow, not when AI is added simply because the technology is available.

That was the first version. Not because it represented everything we thought the system might eventually do, but because it was enough to test whether we were moving in the right direction.

Then we waited for evidence

It worked, so we moved to the next problem.

Many of the questions coming through the system weren't simply questions about existing functionality. They were requests for changes.

Could the software do this? What would be involved? How difficult would this modification be?

Historically, answering those questions required technical people to understand the request, investigate the system, and estimate the effort.

So we taught the system more about how our team estimated development work.

The solution began doing something different. It wasn't only retrieving knowledge anymore. It was helping evaluate future work.

Again, we didn't try to solve everything. We added another capability because the previous one had given us enough confidence to take the next step.

Within eight weeks, the difference was visible

The number of unresolved requests dropped substantially. The waits of days — and sometimes weeks — were disappearing. Our client could respond more confidently, and our team had more operational capacity.

Importantly, we had achieved this without simply adding people to absorb the additional demand.

The evidence gave us permission to make the next investment.

The next phase had earned its way in

What we had built was originally intended to solve a problem for one client. But the underlying pattern wasn't unique to them.

Other Soluntech teams also had valuable knowledge distributed among people, conversations, documentation, and code, so we started applying the same approach to other accounts.

Again, we expanded because we had evidence.

And now we're testing another step. If a request from an end customer can be understood, contextualized, and estimated, could the system also begin producing an initial prototype of the requested change without affecting the production product?

We're working on that now. The early signs are encouraging, but I don't yet know exactly how far we will take it.

And that's the point.

Good software projects follow the evidence

Looking back, what interests me most about this project isn't the AI. It's the sequence.

We didn't begin by deciding to build an intelligent system capable of answering questions, estimating development, and generating prototypes. Had we done that, we could have spent months designing something far more ambitious.

Instead, we started with a problem. Then we made the smallest useful intervention we believed could improve it. Then we looked at what happened.

Only after seeing evidence did we invest in the next capability.

Problem → Intervention → Evidence → Next decision

That pattern sounds simple. But after years of building software, I've come to believe it is one of the biggest differences between projects that create value and projects that merely deliver scope.

A good software project isn't a race to complete a backlog. It's a sequence of increasingly informed decisions.

It is also why we put testing the assumptions that matter before committing too much budget, scope, or engineering effort.

A phase isn't just a smaller piece of scope

This is why I'm sometimes skeptical when I hear that a large software project has been “de-risked” because it has been divided into phases.

Breaking a $500,000 project into five $100,000 phases doesn't necessarily reduce much risk if you've already decided that all five phases will be built.

You've divided the scope. You haven't necessarily divided the commitment.

A real phase should create a decision point.

“Did we achieve or learn enough to justify the next investment?”

Sometimes the answer will be yes. Sometimes the evidence will tell you to change direction. And occasionally, the best outcome will be to stop.

Stopping a project because you've discovered that an important assumption was wrong isn't necessarily failure. Spending another six months building something after discovering that assumption was wrong probably is.

The return can change along the way

This also changes how I think about ROI in software projects. We tend to associate return with money. Ultimately, that matters.

But the return required to justify each stage doesn't always have to be financial, and it doesn't have to remain the same throughout the project.

For an early-stage startup, the return from an MVP might be evidence that a meaningful number of early adopters actually experience the problem and use the proposed solution. That's valuable because it reduces uncertainty before more capital is committed.

For an established company, the return might be reducing the time required to perform an operation, eliminating errors, increasing capacity, improving adoption, or reducing dependency on specific people.

In our case, the early return was proving that fragmented knowledge could be structured and made useful. Then it was faster answers. Then greater operational capacity. Then evidence that the same approach could work elsewhere.

Each result justified asking a slightly more ambitious question.

The ROI of one phase doesn't have to be the ROI of the next.

But every phase should produce something meaningful enough to justify what comes after it.

Must-haves have to earn the right to become more

Most software projects accumulate requirements quickly. Must-haves become mixed with should-haves. Should-haves become difficult to distinguish from nice-to-haves. Eventually everything feels important.

But every additional requirement consumes time, money, and attention before you know whether the fundamental assumptions are correct.

The discipline isn't in building less forever. It's in not building more before you know enough.

That is also the logic behind building the right system : build on what has been validated, focus on what matters now, and leave room for the system to evolve as evidence accumulates.

Build the must-haves. Observe. Learn. Then decide what deserves to become a must-have next.

What looked essential at the beginning may turn out not to matter. Something nobody anticipated may become critical.

The project should be allowed to learn.

Delivery is not the same as success

We traditionally describe successful software projects using familiar measures: delivered on time, delivered within budget, delivered according to scope.

Those things matter. But they aren't enough.

You can deliver exactly what was requested, on the date promised, for the amount agreed — and still build something that shouldn't have been built.

The harder question is whether the software produced a meaningful change in the situation that justified building it in the first place.

That requires starting somewhere different.

Not: What should we build?

But: What problem are we trying to change?

Then: What is the smallest useful thing we can do to learn whether we're changing it?

And after that: What evidence would justify investing further?

This way of working doesn't eliminate uncertainty from software development. It does something more useful.

It prevents us from turning too much uncertainty into software too early.

Our project with this client is still evolving. There are things we're testing today that we wouldn't have considered part of the first version, and there are probably capabilities we haven't thought of yet.

That's fine. We don't need to know the final version to know what to do next. We need enough evidence to make the next good decision.

After years of building software, that's increasingly how I define a successful project.

Solve a real problem.

Build only enough to produce meaningful value or learning.

Measure what happens.

Then let the evidence decide what deserves to be built next.

This is ultimately the thinking behind how we approach software initiatives at Soluntech : validate what matters, build based on evidence, and evolve the system through what happens in the real world.

Because the next phase shouldn't exist simply because it was on the roadmap.

It should earn its way in.