The art of having the right (size) web development team
After 20 years in the software development industry, with most of it in the real estate technology sector, I’ve learned a few things:

More developers won’t necessarily speed things up

Throwing more developers at a problem (project) won’t deliver it faster. It is not a factory, it is pretty much an art to deliver projects on time and it takes years to perfect.

You reach a tipping point where too many people will slow down the project, and end up costing you a lot more. There is also a learning curve for new people, and developers need to be in sync in clearly communicating even the smallest changes that can make or break a project. The right size team (and the right people where everyone pulls their weight) is therefor critical.

The cost of ongoing maintenance and support is underestimated

Both the client and the company developing the software often underestimate the ongoing cost of supporting software. Every new feature you add, adds another layer of complexity and makes for more user support and code maintenance. With time, you get product feature bloat, a bloated development & support team to support customers, and ultimately an inefficient company.

In the long run, ongoing maintenance and support of your project/product will cost you more than the original cost of developing it. Code and the service infrastructure it runs on needs to be maintained and continuously optimized. Optimized code cost you money (even more relevant if that code runs in the cloud where you pay for memory and CPU consumption). There is a constant stream of security updates, API patches and upgrades. You have the option to leave it and save cost, but it will end up burning you, and kill your product prematurely.

Having too few developers exposes you to risk

Having too few developers exposes you to the same risk as having too many developers. The risk of having one or two people that support your product/system exposes your business to the immense risk. You effectively create a single point of failure. A developer leaving can have a dramatic impact as they leave with a lot of know-how on how things work on a higher level, but also on a more detailed coding level. Good documentation and a highly optimized system design can however protect you to a certain point…

Replacing a developer will cost time, that person needs to get to grips with all the code and infrastructure and your business processes. The switch-over will cost you double unless (in the highly unlikely event) of the new developer figuring everything out on their own. Taking over existing code is a challenge and you need a brave developer with a cool head.

Just like any other business, there is a balance to strike on being efficient vs greedy when developing products. Greedy is getting things done as soon as possible at all cost, with as many developers possible, without caring on how easy it will be to maintain or extend that code. Efficient is: spending more time on perfecting the architecture than what you will do coding it; and searching relentless for the perfect developers that share your efficient way of thinking and takes pride in building solid systems.

Not all developers are created equal

Hence, not interchangeable. You may spend months before finding the perfect developer. Maybe even more than a year. Never evaluate a candidate on paper only: communication is king (even more so if you are a remote team like us). Giving them an actual small project to proof their skills first, works better. Thing is, a small team of brilliant developers can easily outperform much bigger teams. Why I always just laugh when a company brags on how big their development team is.

At Entegral, we strive to take the efficient path that promotes organic growth. Yes, we are still perfecting our efficiency but getting there with small steps and learning along the way.

Building software, is art.
['Adriaan Grové']
['Remote Working', 'Software Development', 'Web Development', 'Product Development', 'Remote Work']