This article is a result of Toke Lund 's extensive expertise in navigating intricate tech stack landscapes. Toke is a CEO at Enterspeed with more than 15 years of experience. Enterspeed is a SaaS developer platform that enables you to create high-performing global APIs with no infrastructure. As a company, Enterspeed is dedicated to digital transformation with a strong focus on the opportunities and pitfalls brought on by composability.
I am very fortunate that I get to tap into the tech considerations in a lot of agencies as well as companies. The thing that frustrates me the most on behalf of others is the lack of clarity regarding the advantages, disadvantages, and differences between the popular concepts:
- Custom code;
- Frameworks;
- Accelerators;
- Products.
Unfortunately, the decision to use one concept over the others is not always made consciously – simply because the differences are not clear or even recognized at all. After implementing an IT architecture, it often takes a while before clients realize the consequences of that lack of concept comprehension. The realization often comes when grappling with high maintenance expenses, inflexibility, and strained customer/supplier relationships.
Therefore, with this blog post, I want to try to help decision-makers make their tech choices with open eyes. I strive to be objective, even though I, too, have gained a few "battle scars" over the years… 😉
Custom code
The first one is simple but has a significant impact on your future digital agility and business performance. Custom code is the technology built "by hand" and for tailored purposes. Custom code is often used when a company is unique, has special data, or has business logic that differs from the majority. However, custom code can also be the go-to for many developers, as skilled developers can quickly spin infrastructure, transform data, and set up as the customer wishes – quickly and effectively.
Challenges with custom code
But the challenge with custom code is that it turns into legacy the minute it's done. If the context of the code changes, it’ll need maintenance and adaptation. So custom code can quickly become expensive, even though it initially looks like a "quick fix."
Custom code especially sneaks into projects with time pressure or if a client pushes too much on price and wants to save on licensing costs. Moreover, a significant amount of custom code is due to some companies feeling that there is no software that can solve their problem completely, and they don't want to adapt.
When to use custom code
I usually ask: “Am I really unique, and is the solution business critical?” If you can answer "yes" to both, then custom code might be right for you. BUT I would be cheeky and claim that approximately 99% of all clients should answer “no, we are not that unique, and it's certainly not critical to the business.” And so, they might want to look towards some of the other concepts.
Looking for an alternative to custom code? Consider composable architecture!
Agency frameworks
Now, things get a bit more complicated. Many agencies are great at piecing together their own frameworks to create new solutions in a cost-effective way and ease their way into new projects with new clients.
An agency framework is, in essence, a set of components that the agency is accustomed to working with and has put together to trim hours off the beginning of a project – kind of like a blueprint. It’s a clever way to cut down on hours used. However, when a framework is in play, it can also require a lot of customization of the individual components to match the specific needs of each client. So, frameworks are good for speed of development, especially for agencies, and they can benefit clients.
Many agencies’ frameworks are inspired by established web development frontend or backend frameworks such as React.js, Angular, Vue.js, Express.js, Django, or any of the other many ones to choose from. The agency will typically offer a combined framework for the frontend and the backend and some set requirements for custom code and integrations.
Challenges with agency frameworks
It's crucial to remember, though, that the customization process and the agency's methodologies become integral moving forward. Without this alignment, the framework may cease to perform effectively. So, the client isn't merely adopting a framework; they're also committing to the chosen systems and the selected agency – and they might find themselves in a lock-in where it’s next to impossible to change either framework components or agency.
Of course, that’s okay while the collaboration is good and productive. But for some companies, the honeymoon phase doesn’t last. New agencies may not be familiar with the framework or the chosen "best practice" within the framework, making it extremely expensive and complicated to switch to another partner – some clients will find that they simply can't get out of their contracts with the framework they bought.
When to use agency frameworks
Agency frameworks can be good if you need to solve a problem quickly and inexpensively and have some specific requirements. But be aware that it can be challenging to know whether a framework is really best practice and what the lock-in effect is.
Unfortunately, I have experienced many who, in hindsight, shouldn’t have opted for an agency’s framework, as they now struggle with large, fixed bills and a "rigid" partner. But typically, those who made the decision at the time are now gone, and someone else is dealing with the problems and unhappy management. (And, from personal experience, it’s incredibly difficult to clarify during the hiring process what exactly you are taking on.)
Accelerators
And now to Accelerators. While Frameworks are a working method, an Accelerator is a kind of package with code and solutions that predefine the specific setup between systems.
Many, especially large, agencies have built accelerators where they have pre-combined a set of SaaS solutions so that they can quickly present a large setup with a short time to value.
Many companies spend too much time getting their new solutions to market, so if you’re aiming at a quick move away from your current setup, it makes a lot of sense to consider whether you can fit into an accelerator stack.
Challenges with accelerators
However, accelerators are also closely related to frameworks, and there are some disadvantages. There isn’t one way to create an accelerator, and thus, the lock-in effect on the given agency is high. In addition, an accelerator is typically a combination of especially expensive top-tier SaaS products. This means good tech, good referrals, and a long lock-in. Customers here often end up with a large lock-in to both agencies and product vendors.
Popular accelerators
The accelerator compositions obviously differ following their partnership agreements, price points, tool preferences, and pure old behavior patterns. In Scandinavia, however, I’ve seen quite a few accelerators using e.g. Contentful , commercetool , and Algolia . These are all well-respected solutions, and deservedly so, but even though several accelerators are based on vastly the same solutions, the stack architecture may still vary quite a bit and might include custom code and agency-specific frameworks.
Products
The last category is SaaS products. It can be a bit tricky as some Products are basically Frameworks in disguise. With Products, we’re talking regular IP, where someone has created a scalable setup. The choice of a product-based concept is often founded on past experiences and with a desire to solve a particular problem. When choosing a specific, finished product, you benefit from fast-tracking your development, and you get a lot of best practices "out of the box." At the same time, the supplier is responsible for updating and maintaining the product.
Alokai is obviously a very good product example that allows you to build an easy-to-navigate yet comprehensive setup with its Frontend-as-a-Service approach . Another example is Enterspeed’s own Content Federation Layer – a low-code SaaS developer platform between the backend and frontend architecture.
Challenges with SaaS products
When considering the Product category, it’s essential to discern whether you’re truly looking at a Product or if it’s closer to a supplier-specific framework masquerading as one. For instance, we’ve observed several frontend products created by commerce SaaS suppliers. While they aim to enhance customer value, these “products” often resemble frameworks and operational approaches rather than comprehensive solutions.
Unfortunately, this can lead to increased dependence on a particular company, resulting in the lock-in effect.
Also, be cautious even though a product is associated with a branded supplier name. This doesn’t always guarantee seamless integration with your other systems from the same supplier. Some so-called “complementary” products may require extensive custom code before they can function within the major suite. Discovering this after purchase can be both frustrating and costly.
Before choosing a product, always ask yourself if you can fit your workflows and business logic into the given product – without changing the product. Unfortunately, I have seen too many clients who have bought a really good product but then smashed it into the company's own setup, thus ruining it beyond recognition. And suddenly, it's expensive, cumbersome, and unpleasant. If you choose a product, try to adapt as much as possible to reap the greatest rewards.
But as with other products, your success with these products also depends on how you use it. If you try to impose your own logic or overly customize it, you might not achieve the benefits you were expecting. In that sense, it doesn’t differ much from hardware products.
However, there is also a natural lock-in effect on products, but I will always argue that the lock-in effect is less if you manage to keep your solutions standardized.
But what does that mean for agencies that make a living selling hours and receive very little referral fees from software vendors?
There is a conflict of interest in the market that is important for IT buyers and users to recognize. IT advisers are not always all that different from bank advisers. They are basically salespeople. They also have a business to run, and that might influence their advice quite a bit.
So, what to do?
As you can see, there are pros and cons to all concepts. There is no perfect solution for all IT problems. But having said that, it's essential to keep some clear objectives in mind:
Degree of standardization --> the more standardization, the lower TCO, i.e., lower maintenance.
Time to value --> the faster you can get to market with something, the better – both to test if there is a market but also to start adjusting what actually works in the digital experience.
Security --> Never forget about security. Always remember to build secure digital experiences that are continuously monitored and upgraded. The risk is just too significant if you don’t.
I hope you’ve found inspiration in the above, and if you have questions about what your company should choose or why Enterspeed has made our product choices, feel free to reach out.
