Individual Software Development vs. Tooling Configuration

Most managers are familiar with the traditional “make or buy” decision.
With digital projects, it is not that simple

Whenever you start to build a new digital project, no matter if is a simple website or a complex enterprise application, you face the following major question:
Should we buy and customize existing systems or build it from scratch?

Imagine this question as the one, you should ask immediately after “make or buy”.
Mind that no matter if you make it yourself or buy it by paying some external service provider, you need to decide “from scratch or configure existing things”.

What to expect

This article sheds more light on the difficulties of this question, while highlighting its importance and impact, as well as providing you with some decision helpers.

It is mainly written for business managers, who need to make decisions in digital matters without being IT architects themselves.

The Difficulties

Multiple Levels

To be honest, this is no real black or white decision.
This question happens on multiple levels and even when it is smart to choose “from scratch” at one, “configuring existing things” can become handy at another.

To name the most important levels:

1. Infrastructure. It often starts with the question, where to host an application. You could take care of all infrastructure details (from scratch) or use service offerings to minimize effort here. See the article “PaaS vs. IaaS vs. running your own Server Network — a Management Perspective” for more details.
2. Application.
   You could use an existing Customer Relationship Management (CRM) software like Salesforce or start building your own one. Here, the choice usually is quite clear. But how about using WordPress vs. setting up an own Content Management System (CMS) solution? Even for more complex web and native apps, there are visual editors like appgyver or unqork.
3. Templates.
   So, you have decided for WordPress as your CMS. But this is basically only your backend. Should you use an existing frontend template from some marketplace? It is often easy with many options, but slows down your page at the same time. Developing your own template leads to better performance and even better customization, but takes time and money.
4. Frameworks / Libraries.
   You might have decided to develop your website from scratch. But even there, you could decide to work with a strong framework (e.g. Angular) or Library (e.g. React). This often helps, but in some cases can also be a big overhead.
5. Code Snippets and Packages.
   Getting to the lowest level, the code. Even when writing the code from scratch, developers have the option to use code snippets from other people or integrate external packages for specific functions. It saves them time, but many of those things are outdated, what can break your application later or open backdoors for hackers.
6. Minding all parts.
   And of course, you can make different decisions per part of your application. The contact form can work differently than your support page than your CRM middleware. Even when it seems to be only about one application, there are often many different systems involved.

Holistic Approach

Facing that many levels, it gets even more confusing, when you consider the relevant aspects of this decision.

Examples:

1. One technology could be a better fit, but if you do not have access to respectively skilled people, another solution might be even better.
2. Configuring existing tools might speed up things first at lower cost, but if you need to get into more specifics later, it could become even more expensive. What still works for a startup, could be a real problem for CAPEX-driven corporations.
3. You might want to go with your from-scratch solution XYZ, but this means that the system of your supplier has no pre-configured connector to your solution. So, you would need to build some kind of middleware in addition.

To be able to consider and discuss all of those and even more issues at the same time, you need experienced tech-skilled business managers. This often is the real limiting factor.

Keeping it flexible

Yes, this is not easy. That’s the reason, why it often might become necessary to change the approach along the way.
To be able to do so, you need to implement respective flexibility right from the beginning. This starts with telling people about this potential switch.

The Impact

When you think this is of lower importance or should be discussed by developers only: STOP!

Of course, some details should happen at the operational level, but as a manager, you need to guide and set the direction.

Those decisions are strongly connected to spending.
Even when a developer decides to build some part by himself instead of using an established existing package, it costs you not only a lot of money, but furthermore, blocks this resource.

Of course, this also leads to an important timing and roadmap issue.
Often, it is not only about the time to build the initial application, but also maintenance and further development. Going for “from scratch” easily, can cost you years!

Last, but not least, it is about long-term strategy and ROI!
You could save time and money now, but it can easily backfire 2 years later. Or you might save money, but are not able to build those killer features, your customers really need. This can quickly lead to a failing product and then, even a small price tag is still too high.

Decision Helpers

But how to decide, which way to go?

Unfortunately, there is no simple matrix, which could help you in every situation.
The following issues and questions help you to challenge the people around you, to get as close to the ideal setup as possible.

General Thoughts

• Budget: Going with existing things is usually cheaper than starting from scratch.
• Control: Starting from scratch means 100% control. Mind different levels of control per existing tool, when you need to decide for one of them.
• Speed: Starting from scratch takes a lot of time and future updates could last even longer, depending on your internal resources. Configuration is also not done overnight, but usually faster.
• Individuality: Building something from scratch enables you to create a real product USP. Rule of thumb: The cheaper and easier your solution, the smaller your market advantage. If you want to just test something or your USP is more on the business side (e.g. lower prices), go for existing tools!
• **Fit **with existing skillset: Making use of existing things is usually no problem for technical skilled people. If you are going for a specific tech stack from scratch might require new hires, if you do not have the skills on board.

Things to ask your Project Manager

• Does your project manager (make) or the service provider (buy) offer you those different ways per level, pointing out risks, chances, advantages, and disadvantages?
  No? This should ring all alarm bells and you should absolutely think about finding another project lead!
• Ask for alternatives — always! Let people point out pros and cons, but also let them add a degree of familiarity. If Python would be a good choice as programming language, but your people do not know it, you should not consider it.
  For large, important projects, it is often good to hire some independent consultant — only for this check-up. Pro-Tip: If he does not see a follow-up project coming, you have better chances of seeing more truth.
  Also mind knowledge gaps: If an advisor points out multiple best practice approaches, that no one in your team would be able to handle, you should maybe think about rather “buy” than “make”.
• Do a system dependencies evaluation. Often, projects are focused on one tool or system, not considering the more complex environment around it. Do you have suppliers, which should connect their systems to yours? Or do you work with other external systems? Are you planning to migrate another system any time soon, which could interfere with this projects’ plans? Let your project manager draw the complete landscape, pointing out potential problems!
  Sometimes, it can be better to use existing tools, because they are already connected, sometimes, you need to build from scratch, because existing tools do not provide proper options to connect.
• The small details (e.g. code snippets) are usually not pointed out to you in the beginning. Ask about them proactively. Usually, it is a good idea to make use of other people’s work here. But mind to list all dependencies not only within the code repository, but also somewhere, business people have access to. Also let developers point out the risk of those dependencies and how actively they are maintained. A high-risk code, which had been last updated 5 years ago? Critical!
• Cost, Budget, Time, Maintainability, Long Term Drawbacks, Dependencies, Reliability, Performance, Security.
  Repeat those words over and over again. This should keep you in the driver’s seat.

Conclusion

No matter how you decide in the end, put this question at “Priority A+” and put respective resources into it!

Moving too fast at this point or not considering all details, can let your whole project fail — usually not immediately, but 12 months later.
I’ve seen this happening multiple times with my own eyes.

Remember:

“Make or Buy” + “From Scratch or Configuration”.