Custom software projects fail more often than they should. Not because the technology is too hard. Not because Indonesian developers are not capable. They fail because of decisions made before a single line of code is written — and sometimes because of the wrong decisions made throughout the build.
After more than 25 years of building custom web and mobile systems for Indonesian businesses, the failure patterns are consistent. The same problems appear in different industries, at different company sizes, with different teams. Understanding them before you start a project is the most valuable preparation you can do.
What "Failure" Actually Means
When people say a software project failed, they usually mean one of three things: the project went significantly over budget, the project delivered late (or not at all), or the system was delivered on time and on budget but nobody uses it.
The third type of failure is the most common and the most painful. The money was spent. The system was built. The launch happened. And then, over weeks and months, usage drops — reps find workarounds, managers stop checking the dashboard, the system becomes optional, and the operational problem it was supposed to solve remains unsolved.
This is not a technology failure. The technology usually works. It is an adoption failure, and adoption failures almost always have roots in decisions made during planning and scoping, not during development.
The Most Common Failure Patterns
1. Requirements Written Around Screens, Not Workflows
The most consistent problem: projects that start with "we need these screens" instead of "this is the workflow we need to support."
When requirements are written around screens — the list of features, the set of menus, the design mockups — everyone focuses on whether the screens were delivered. Did the app have a dashboard? Yes. Does it have a form for logging visits? Yes. Did it pass UAT? Yes.
But the question that matters — does the system match how the team actually works? — was never the measuring stick. So the screens get delivered, they look right, and then nobody uses them because the workflow the screens require does not match the workflow the team actually has.
The fix: before writing any feature list, document the operational workflow. Who does what, in what sequence, in response to what trigger, with what output. Features exist to support that workflow. If a feature does not support a step in the documented workflow, it should not be in version one.
2. No Agreement on What Success Looks Like
"Better visibility" is not a measurable outcome. Neither is "more efficient" or "easier to use." Projects that begin without specific, measurable definitions of success have no reliable way to know whether they worked.
When the success criterion is vague, the project stays vague. Development continues past the point where a focused release would have been possible. Features get added because nobody can say "this is enough to prove the system works." The timeline grows. The budget grows. And at the end, the evaluation is subjective: some stakeholders feel it worked, others feel it didn't, nobody knows who's right.
The fix: before starting development, agree on two or three specific measurable outcomes that the system should produce within the first 90 days of real use. "Follow-up completion rate visible in the dashboard within 24 hours of activity" is measurable. "Managers spend less time on weekly report compilation" can be measured if you know the current baseline. Define the outcomes, then scope the system to produce them.
3. Reporting as an Afterthought
Reporting is almost always the last thing specified in a project and the first thing that disappoints stakeholders after launch. Managers discover that the data they most need is not captured, or is captured in a format that makes reporting difficult, or requires manual extraction that defeats the purpose of having a system.
This happens because reporting requirements are often not part of the initial scope conversation. Development teams build the transactional features — the forms, the workflows, the data capture — and at the end someone asks "how do we report on this?" and the answer requires additional work that was not planned for.
The fix: define reporting requirements at the start of scoping, not at the end. What does a manager need to see? How often? In what format? What decisions will they make based on this report? Answers to these questions directly inform how data is structured during development — and data structure decisions made early are cheap; ones made late are expensive.
4. User Adoption Not Planned For
Software does not adopt itself. Even a well-designed system, built for the right workflow, requires a deliberate plan for getting the team to use it — and keep using it.
The most common adoption failure looks like this: the system is launched with a one-time training session. For the first two weeks, usage is decent. Then the manager's attention shifts to other priorities. Reps who found workarounds in the old system quietly go back to them. Within a month, usage has dropped to the minority of reps who are genuinely enthusiastic about new tools.
This is not a technology problem. It is a change management problem. And most software projects do not include a change management plan.
The fix: before launch, answer these questions. Who is responsible for adoption within the team? How will usage be monitored in the first 30 days? What happens when a rep stops using the system — who notices, and what do they do? Is there a clear reason for reps to use the system daily (does it make their job easier, or does it create additional work)? If the system creates additional work without a clear personal benefit to the user, adoption will be low regardless of system quality.
5. Scope That Grows Without Control
Projects that start focused often do not stay focused. As development progresses, stakeholders think of new features. The development team, wanting to be helpful, accommodates requests. Timelines extend. Complexity grows. The focused first version becomes a large, expensive first version that takes much longer to ship.
By the time the system launches, the market has shifted, the team has changed, or the original problem has been partially addressed through workarounds that developed while waiting for the system. The system that finally ships is too complex for easy adoption.
The fix: maintain a strict version boundary. Everything that is not essential for the first version gets documented in a version two list, not added to the current build. The first version should be the smallest system that can be put into real daily use and tested against real operations. Version two is planned based on what was learned from version one.
6. Choosing the Wrong Development Partner
A low quote is not a deal — it is a risk. The most expensive custom software project is the one that gets rebuilt because the first version failed.
The wrong development partner typically appears in one of two ways: an inexperienced team that underestimates complexity, underdelivers on quality, and produces code that is difficult to maintain; or a team that delivers technically but does not understand the operational context and builds features that do not match how the business works.
The fix: evaluate partners on their ability to ask good questions about your operations, not on their ability to present an impressive portfolio. A developer who, in the first conversation, asks "walk me through how a rep currently handles a follow-up" is thinking about the right things. One who jumps straight to technology choices is not.
What Good Planning Looks Like
Based on the patterns above, a well-planned custom software project has these characteristics before development begins:
The operational workflow is documented. Not the desired future state — the actual current state, with all the manual steps, WhatsApp messages, and spreadsheets. This is the baseline the system needs to improve on.
Two or three specific measurable outcomes are defined and agreed on by the key stakeholders.
Reporting requirements are part of the scope specification, not left for later.
An adoption plan exists: who is responsible, how usage will be tracked, and what will happen when adoption is low.
A version one boundary is defined and defended. Everything outside it is documented as version two.
The development partner has demonstrated that they understand the operational context, not just the technical scope.
One More Thing: The System Has to Make Sense to the People Using It
All the planning in the world does not fix a system that reps find genuinely harder to use than the alternative. Before launching any field-facing system, put it in front of two or three actual users in real conditions — not in a conference room, but in the actual workflow environment. What they find difficult, confusing, or unnecessary is real feedback that is cheap to act on before launch and expensive to address after.
Systems that your team actually uses every day are not accidents. They are the result of understanding the workflow, designing around real use, and planning for the human side of adoption — not just the technical side of delivery.
Planning a Custom Software Project?
If you are early in planning a custom system and want to work through the scoping questions that determine whether a project succeeds or stalls, a 30-minute discovery call covers the key decisions before any commitment is made.
Erick Wellem is a technology consultant and software architect based in Indonesia. He has been building custom web and mobile systems for Indonesian businesses since 2000.
Need a system like this?
Discuss your process, bottlenecks, and the right software approach.