80% of projects and companies don't need 100% custom-coding!

Unfortunately new developers that started learning to code since around 2010-2014 onward  have been regressing to the 1970s but with a disturbingly increasing lack of discipline, training, experience, education, and comprehension.

Most egregiously they have reverted back to an increasingly blatant disregard for documentation and design, pushing more "code-first", 90% coding and maybe (if you are lucky) 10% shoe-horned-in documentation after the fact (at best), losing sight of the decades of proven to be effective design and coding principles. They have all but scrapped everything learned from millions of developers prior to the past 10-15 years, and are now repeating the mistakes of  many decades ago (a la 1970s and 1980s).

So far, for projects run and developed by people who started working in tech around 2010+ increasingly over 90% of the custom-coded projects I have seen (and I've been looking at code for over 40 years), has increasingly become terrible spaghetti code,

Developers with experience from only the past 10 years or so now  just try to solve this by throwing more cloud resources at it rather than clean up their horrible mess (proper refactoring principles), or better yet taking what they have learned from their mistakes and throwing their "MVP" code in the dumpster where it belongs, and starting over with a much more sustainable design-first approach (80% design, 20% code). They refuse to learn from their prior mistakes, and keep repeating the same ones over and over, spreading their mess and infecting others under them.

And now they are undermining the decades of progress made thanks to open source, and sabotaging all of those principles and benefits, leading to making this problem that much worse.

I have directly and indirectly managed thousands of developers in my lifetime, with development teams anywhere from just me, to 35+ in most cases per project, and some times with over 200 in especially large projects/organization (not counting all of the other very important SysOps, DBAs, etc  doing what the coders can't or won't do, more on the systems side instead of the new platform building side).

In recent years I am increasingly finding myself in a downsizing phase for the development teams.

So many code bases have become so entangled, and the teams trying to unravel them so bloated, in recent years at so many companies because of being terribly mislead about what should be custom-coded, and what is already available as "off the shelf" products or services,  commercially, in the cloud, or from open source.

I have helped many clients over the decades get away from the "trap" of 100% custom-coded platforms, that don't scale, are severely insecure, and take much longer for time-to-market.

Instead I help them move to more of a model of conglomerations of multiple off-the-shelf (usually open source) solutions that better meet their scope and needs. This is generally the best approach for about 80% of the companies and projects I've seen from bootstrapped unfunded startups, funded startups, SMBs through multinational top Fortune-listed enterprises, and everything in between.

Every now and then there is something really truly new, that does need 80% custom code, but even those can be adjusted, for example, do you really need to custom code yet another CMS? Or can you use something that provides those functions already for you, supported by a large community, and you can focus instead on all of the underlying original, innovative, "secret sauce" code that makes your product/service/organization distinctive?

I have done this for many individuals and organizations.

I have literally directly saved saved them millions in development costs. And in many cases made it possible for them to get  full 1.0 (forget just MVP) out the door in weeks or just a few months, for 1/100th cost it would have been for custom-coding!

Of course, this it is critically important to have clearly documented scope about the actual needs to determine if this methodology actually makes sense.

Sometimes (as I stated, maybe 20% of the time) custom-coding is really the best solution, but about 80% of the time it does not.

This approach of recommending that you "don't reinvent the wheel from scratch" in areas that aren't relevant to the company's innovative market leadership, and taking this most-off-the-shelf approach and then just "Gluing" or customizing the last 10-20% that is specific to the scope that makes their product/service/organization stand out from the crowd, as the organization's "secret sauce", is a much better approach most of the time.

This is a more effective, faster, scalable, and all around better approach (for about 80% of companies/projects).

This has been effective in reducing bloated dev teams of 30+, or even over 200 developers, down to generally a more reasonable 2-6 with far better quality, scalability, security, performance,  and long-term manageable results.

This is generally a much faster time to market approach as well.