Many shops use eXtreme Programming (XP). They skip planning and focus on building at high throughtput. The result normally costs 10x more than what the client expected. Sometimes this happens because the client thought that one feature would be simple, but if he knew it was that complex, both parties would be able to haggle the scope. That's why we use a boring architeture that is easy to estimate based on objective parameters such as the number of columns or fields you need for each page. Plus, by planning a sprint before build, we're able to analyse the consequences of each decision and decide a better solution, avoiding the need of rework in many cases.

Sometimes this higher cost happens because the software is built more technologically complex than the scenarios that are the target of the business. Some shops will opt for microservices/modular (recommended for mission critical software such as fraud detection or e-commerce), or clean architeture (recommended for planning system such as school time table), when the simple architeture MVC (recommended for most of ERP, CRM and BI system) would be enough. Plus, some shops will add too many components into the architecture that only make sense for big projects such as multiples databases, creating data inconsistencies and a lot of work to try to keep everything synchronized.

The Web was built through broad debate among the brightest minds and several companies. Decades of experience building system formed the base of it, but it would be always open to be extent. Many shops will recommend to take advantage of the ability to extent the web to create a Facebook-like experience. All these customizations are called the frontend and are built using JavaScript. It adds 30% to 80% more on the projects costs. One reason is that you have to built, test and fix bugs of features such as request data or update the screen, things the browser is cable of doing by default.

The another reason is that highly customized frontends break with basic Web 1.0 principles that were thought to maintain everything simple. The MVC architeture, that we already mention, fits perfectly over these standards. The site offers options (such as links or forms), the user make a small decision, the site offers new options based on his prior decision, and so on. The navigation is incremental, it easy to build, maintain, and to use. To break with these standards means poor integration with SEO, a much complex architeture to handle multiple decisions at once (payload), duplicating the work of creating an interface for API and another for Web, and making harder to scale.

The #1 cost in software development are the so called technical debt, which boils down to bugs hard to fix. Most of shops will build your software using a procedural (or object-oriented procedural) language. A procedure is a very powerful tool that enables you do anything, especially to change the value stored in memory. This means you can test the software thousand times and it will work, but someday the memory will change just to the right configuration that make it spoil. Sometimes will be even hard to discovery for which memory configuration that algorithm not work, let alone what is the issue with the algorithm.

When it is not strictly necessary, we'll use functional or even descriptive languages instead of procedural. In the same way that we already discussed architectural constraints that help to simplify the software, we can also have system level constraints in the language (many shops will tell you that language doesn't matter anymore because of Vibe Code, huge mistake). By working with a less powerful language that can't change the memory, one is able to build a software that is also less error-prone. Remember your Math classes, when you defined $x=1$, it continued to be 1 no matter what happens. If you find out $x=2$ some place else, you got an obvious contradiction and know that something went sour. Is this kind of imutability that makes our software more realiable.

Most shops will create solutions from scratch, no matter if they built it over a framework or not, that need to be tested and fixed over the years, the technical debt we already talked about. The same way they will build custom JavaScript instead of using the browser's native resource, they will build custom backend instead of using the database native resource, and they will create custom integrations instead of using a integration tool. Even worst, they will create their own abstractions to avoid duplicate code that shouldn't even exists in the first place, and then it will be cumbersome to read a code full of undocumented abstractions that nobody else know.

Unless there is no way to achieve something similar, we'll rely always on battle proven OpenSource tools. The extra work of learning these tools easily pays off with dependability and standarization. Plus, by using die-hard OpenSource tools we can some how be less dependent on extreme vendor lock-in, artificial labor price fluctuation, and crazy fads of new technologies. Most of long stading OpenSource project are maintained especially by volunteers that work on SMB. This means that the tools need to be simple to build, to maintain and to use, provided that one have technological knowledge.