Why We Don’t Develop Custom Software to Support Millions of Users

As custom software developers, it is our job to deliver a product that is designed and built to address our clients’ unique needs. So when a customer asks us to build their custom software so that it can support millions of future customers, it often comes as a surprise--or even an offense--when we say no.

Planning Custom Software Too Far in Advance

It may seem logical to build a software infrastructure for your company’s growth goals. Custom software should be built to scale up so that two years down the line you won’t need to scrap the whole thing and start over again. But overcompensating is its own danger. Building something too big, too early, can directly impact the success of a business.

Over-engineering a system for needs that you don’t yet have adds unneeded complexity and costs now that can actually limit your future growth.

A recent podcast from Wix--the custom website company--offers one example of how “presumptive” scaling can wreak havoc on a growing business. In the episode, Yuval Perry, an engineer of 25 years, describes working for a growing e-learning company. The success of the company prompted a change: they’d graduate from their existing software, into one that was based on microservices. This is a common step for large companies that employ hundreds of developers spread around the world. He says:

"In just a few years, we had more than 60 micro services in production. We were very proud [of] each and every one of them because we built a sophisticated CICD environment and everything was deployed behind a feature toggle and it was super eventual consistent."

The problem, in this case, was that the company wasn’t yet big enough to make this digital architecture change necessary. Instead, they upgraded in anticipation of needing to in the future. The consequences of jumping the gun like that manifested very clearly, very quickly. Perry continued:

As we grew a little bit more, [. . .] each person that breaks the build or breaks the ongoing development would have affected and impacted every other person in the team and eventually every time something would break, it stopped the development of all of the company. [. . .] We started to feel the load of the management. I mean things started to fail – to break more than often and it got into a point where I couldn’t imagine adding 10 more.

The bigger, more diverse microservices architecture was supposed to help the company work more efficiently. Instead, it had the opposite effect. They hadn’t considered how their legacy system would affect their new one. Their integration environment--where developers test new code to make sure it works--couldn’t be squared with the new microservices infrastructure. Every problem microservices were supposed to solve, instead, became exacerbated.

In the end, the company chose to delete its integration environment entirely. This was a very bold move--akin to shutting off the spelling and grammar check in your Word processor, forever. The company survived, but Yuval and his colleagues learned a valuable lesson in why scaling should be handled with deftness and patience.

The Bottom Line

Buying software is like buying anything else. Would you buy adult-sized shoes for your child, in anticipation of them becoming an adult? It wouldn’t be advisable. The shoes won’t fit for years to come, and by the time your child does reach adulthood, they may require a different size than you’d expected or need a different style. Your money would be better spent on shoes that fit them now.

If you went so far as to seek out a custom software solution, you’re already ahead of the competition. If you then took that extra step of reading an article like this--doing your homework, to gain as much information as you can before making a decision--then you’re the kind of business owner we want to work with. Remember, even though your business might have millions of customers one day, now is not the time to accommodate those millions of users.