Most software projects fail before any code is written. What business owners in Nepal should ask developers about scope, security, and second-year costs.
Most people who commission software describe the same experience afterwards. The project ran late. The final product did some things well and other things strangely. Nobody could say exactly when it went wrong.
That last part is the interesting one. Software projects rarely fail in a single dramatic moment. They drift. And the drift almost always starts in a meeting room, weeks before anyone opens a code editor.
The lists of "common development mistakes" that circulate online are not wrong, but they are written from the developer's chair. Poor code, skipped testing, no version control. If you are a shop owner in Newroad or a clinic administrator in Pokhara, none of those are things you can inspect. You are buying something you cannot see, from people whose work you cannot evaluate, using a vocabulary you do not speak.
So this is written from your side of the table.
The most expensive part of a project is the conversation nobody had
The Standish Group has tracked software project outcomes since 1994 through its CHAOS research. Its 2015 report put fully successful projects at 29 percent, with 52 percent challenged and 19 percent outright failures. That definition of success has been criticised by researchers for resting on cost, time and features alone. Take the exact number loosely. The pattern behind it is harder to argue with: from the earliest editions onward, incomplete requirements and weak user involvement have ranked among the leading causes.
Here is what that looks like in practice. A client asks for an online store. The developer hears "online store" and starts building the version of an online store that lives in their head. Six weeks later there is a wishlist feature, a loyalty points system, and a dashboard with four charts nobody asked for. Meanwhile the one thing that actually mattered, letting a delivery boy mark an order as paid on his phone, was never discussed.
A pattern in almost every first meeting is that clients describe what they want the software to be rather than what they want it to do. "I want a professional booking system" tells a developer nothing. "On a busy Saturday my receptionist takes forty calls and loses three bookings because she cannot see the doctor's schedule from the front desk" tells them everything.
The original research on this topic recommends writing requirements down before development begins, which is fine advice as far as it goes. My disagreement is with the implied finality. Written requirements are useful mainly as a record of what everyone believed at the time, not as a contract with reality. You will discover things in week five that nobody could have known in week one. A requirements document that cannot change is just a more formal way of building the wrong product.
What matters more is who is allowed to answer questions. Projects stall when developers raise a decision and it sits unanswered for nine days because the person who can decide is travelling. Standish's 2018 work on decision latency argues that slow decision-making is a root cause of failure in its own right. Naming one person with authority to answer within twenty-four hours does more for a project than any planning template.
You are paying for two products, and you can only see one
Every piece of software has a visible layer and an invisible one. The visible layer is screens, buttons, colours, the things you point at during a review. The invisible layer is how the code underneath is organised, whether it was tested, whether changes are tracked, whether anyone else could pick it up.
You are paying for both. You will only ever inspect one.
This asymmetry explains a lot of bad outcomes that get blamed on dishonest developers. A team under budget pressure will always cut from the layer the client cannot see, because the client will not complain this month. The bill arrives later, when a small change takes three weeks and the developer cannot explain why.
Clean code, testing and version control get treated as three separate items on a checklist. They are really one thing: the ability to change the software safely later. Version control, using tools like Git, means nobody overwrites anyone's work and you can go back to a version that worked. Tests mean a change in one place does not silently break something else. Readable code means the next developer can understand the last one's intentions. Remove any of the three and the software becomes a building you can live in but never renovate.
Testing deserves a caveat, because the standard argument for it is shakier than most people realise. You will often see the claim that a bug costs a hundred times more to fix in production than in requirements. That figure traces back to work by Barry Boehm in the 1970s and to a widely reproduced chart attributed to an IBM training course whose original data nobody has been able to locate. Boehm himself later suggested the ratio is closer to five to one for smaller, non-critical systems. The largest study to revisit the question, covering 171 real projects, found no consistent effect at all.
So the honest version is this. Late bugs are usually more expensive, but not catastrophically so, and the difference depends heavily on what kind of system you are running. That should change how you buy testing rather than whether you buy it. Exhaustive test coverage on a five-page brochure site is money burned. The same coverage on anything touching payments or patient records is cheap insurance. Ask your developer where the test effort is concentrated, not how much of it there is.
Security is a shape, not a feature
Nepali businesses are being pulled online faster than their internal practices are adapting. The World Bank's March 2025 country economic memorandum on Nepal found that the overwhelming majority of firms have fixed broadband access, yet under ten percent of them pay electronically. That gap is closing quickly, which means a large number of businesses are handling customer data and money for the first time, with no prior habits to fall back on.
The framing of security as something you add is where most of the damage begins. OWASP, which maintains the reference list of web application risks, put broken access control at the top of its 2021 Top 10 after it moved up from fifth place, with more occurrences in the contributed data than any other category. Broken access control usually means something unglamorous: a user changes a number in a web address and sees somebody else's invoice. No hacker, no malware, just a missing check.
You cannot bolt a permission model onto finished software. It has to be part of how the thing is shaped from the start, which is why the timing matters more than the budget. My own view, and this is a view rather than a fact, is that small businesses over-invest in the visible parts of security, the padlock in the browser bar, and under-invest in the boring parts: who on staff can see what, what happens when an employee leaves, where the database backup actually lives.
Ask a prospective developer what happens if your office laptop is stolen tomorrow. The quality of that answer tells you more than any certificate.
Simplicity is a discipline, not a starting condition
Nobody sets out to build complicated software. Complexity arrives one reasonable request at a time.
There is a version of this problem that gets blamed on clients, the endless "can we also add" during a build. There is a second version that is entirely the developer's doing, where a straightforward site gets built on an elaborate technical stack because the team wanted to work with it. Both produce the same result: a system only its authors can maintain.
Standish's 2015 data offers an uncomfortable hint here. Purchased applications used without modification showed the highest success rate in that analysis, at 57 percent, while systems built from scratch with traditional languages and methods showed the highest rate of being challenged, at 61 percent. Read plainly, that suggests a share of custom software projects should never have been custom software projects. For a lot of small retailers and restaurants, an existing platform configured properly will outperform something bespoke, because the bespoke version carries a maintenance burden the business is not staffed to absorb.
The trade-off is real and cuts both ways. Off-the-shelf tools mean living inside somebody else's assumptions and paying rent forever. Custom software fits your process exactly and is yours. What tips the decision is usually not the feature list but whether your process is genuinely unusual. Most are not. The businesses that benefit most from custom work are the ones doing something their competitors are not.
At Webpal, the conversations that go best are the ones where we talk a client out of half of what they came in asking for. That is not modesty. A smaller build finishes, gets used, and generates real feedback. A large one is still being discussed a year later.
Launch day sits in the middle of the project
The single most common financial surprise in software is that the invoice does not stop at launch.
Estimates of maintenance as a share of total lifecycle cost vary widely in the literature, from roughly 40 percent at the low end to 80 percent or more for long-lived systems, with 60 to 80 percent the range most often cited by IEEE-affiliated sources. The spread is wide enough that no single figure should be quoted as settled. The direction is not in doubt, though. Building the software is the cheaper half.
Many companies discover this too late because the initial quote is the only number they ever planned around. Browsers update. Payment gateways change their integration. A security patch arrives for the framework your site runs on. None of this is anyone's fault and all of it costs money.
The practical response is to treat maintenance as a line item from the first day rather than an unwelcome surprise in month eight. Ask for it in writing during the quotation stage. A developer who has not thought about the second year is telling you something about how they work.
There is a quieter risk worth naming here. This one is observation rather than research, so weigh it accordingly, but it comes up often enough in this market to be worth stating plainly. A lot of small businesses build with a freelancer or a very small team, and the software becomes dependent on one person's availability. When that person moves abroad or takes a full-time job, the business is stranded with code it does not own in any meaningful sense. Owning the source code and the hosting accounts in your company's name, from day one, costs nothing at the start and everything to fix later.
What actually reduces your risk
Reduced to what a business owner can control, it comes down to four things.
Describe problems, not solutions, and keep describing them as the build progresses. Give one person authority to answer questions quickly. Insist on owning your code, your domain and your hosting from the beginning. And plan for the second year before you sign for the first.
None of that requires you to understand a line of code. It requires you to ask harder questions in the first month, when questions are still cheap.
The teams that deliver well are rarely the ones with the most impressive technology. They are the ones willing to say "we would not build that" early, when saying it is still awkward, rather than nine months later when it is expensive.
Frequently asked questions
How do I know if a developer is any good before hiring them? Ask them to explain a past project's biggest problem and how they handled it. Vague answers usually mean they were not close to the work. Ask who owns the code and hosting when the project ends. Ask what their second-year support looks like and what it costs.
Should I choose a ready-made platform or custom software? If your business process resembles others in your sector, an existing platform configured well is usually the better value, since the maintenance burden is lower. Custom work pays off when you are doing something genuinely unusual, or when an off-the-shelf tool forces you to change how you operate.
How much should I budget for maintenance? Published estimates place maintenance somewhere between 40 and 80 percent of total lifecycle cost, so the honest answer is that it varies a great deal by system. Get a written annual figure from your developer before signing, and treat any quote that ignores year two as incomplete.
What is version control and why should I care? It is a system, usually Git, that records every change made to your software. It matters to you because it means work cannot be accidentally lost, several people can work at once, and a broken change can be undone. If a developer does not use it, walk away.
Is my small business really a security target? Most attacks are not targeted at anyone in particular. The weakness that appeared most often in the data behind OWASP's 2021 Top 10 was broken access control, where a user simply views data they should not be able to see. Size offers no protection against that.
When is the right time to start thinking about security? Before the design is finished. Permission rules and data handling shape how software is built, so adding them afterwards means rebuilding parts of it. Asking a developer how they handle access and backups during the quotation stage is a reasonable question, not a rude one.
Planning a build and unsure whether custom software is the right call? Webpal works with businesses across Kathmandu on that decision before any code is written. Talk to our team about your project — the first conversation costs nothing.
Sources referenced
Photo by Vitaly Gariev on Unsplash