It's not Build or Buy. It's Build it Together.

Like every other SaaS vendor, we have our Build or Buy slides, pages, and other marketing material honed and ready for any situation. But in reality, our offering is not either / or. Instead, we advocate a Build it Together approach.

The question we want you to ask is: “What can I use Enterspeed for, and what should I build myself?”

Does more code create more value?

As software engineers we like to write code. And luckily, a lot of us have more or less free hands to to so because software creates a lot of businesses value. But building, maintaining, and operating software comes with a big responsibility and requires a lot of resources – and the more software you write, the higher the cost in the years coming.

However, we argue that writing some custom code is pretty much unavoidable.

Looking at our own world, Enterspeed’s in the business of selling high-performing APIs. But in the realm of web development, an "API" is a difficult component to define.

APIs come in all different kinds and flavours. Maybe the one thing APIs have in common is that they always work a little differently than expected – and perhaps even a little differently than they’re required to...? So, as software engineers we work around this by writing code to "iron out" the gaps.

Working within the composable paradigm this is especially true, as a composable website is made up of multiple discrete data components and third-party services. Writing custom code is the way to stitch the composable components together. But writing code is a double-edged sword. On the one hand it creates value by delivering business features, and on the other hand it costs resources to write, operate, and maintain. Custom code is at the same time a value creator, and a value depleter.

With the notion of code as a double-edged sword in mind, the goal is not to completely avoid writing code, nor is it to write as much as possible. Instead, you should write the appropriate amount of code… And “The appropriate amount of code” is, of course, very contextual and sometimes subjective.

So, "just choose the right amount" is not very concrete advice, we realise. It's like telling an athlete to "just go win". And in this post, we want to leave you with something more concrete to use when you build with Enterspeed.

Performance First

One of the main features of Enterspeed is performance. And the secret of performance is pre-processing. When you ingest data into Enterspeed, Enterspeed stores a copy of your data. Before the data is made available to the frontend of the website, the data is transformed and stored in a high performant storage. The reason for this pattern is performance. In short, we move the resource heavy computations out of the user's way. Enterspeed does almost zero computation when the users request a Delivery API request.

👉 Read more about what Enterspeed is all about.

The flipside of the coin is that there is no computation on the request time of the Delivery API. In very concrete terms this mean that you don’t get to use e.g. a query string parameter for dynamic requests to Enterspeed.

Enterspeed is the component that delivers the content for the frontpage, the list of translations, or the product details page very fast and efficiently. Adding business logic on request time leads you down the Build it Together path.

An example: Dynamic data + performance

A simple example on dynamic data is currency conversion. Imagine that you have a price for a service or a product, and that you want to show the price in various currencies. A simple request could perhaps look like this:

/products/t-shirt-v-neck?currency=DKK

This type of request will not work directly with Enterspeed's Delivery API. Using the Enterspeed pre-processing pattern, we see two possible solutions. Both solutions might be appropriate to use, and the difference between them illustrates how diversely you can “Build It Together” using Enterspeed.

We’ve chosen the example of currency conversion because it’s easy to understand and at the same time it involves some amount of business logic.

The scenario is as follows:

• Number of products: 1000
• Number of currencies: 10
• Currency conversion rates are manually validated and updated at least once every week
• Products are stored in an ERP system and currency rates are managed and stored in a Google sheet

In both solutions, the ERP system or an integration component is responsible for ingesting the products and a custom upload script is responsible for ingesting the currency rates into Enterspeed. (In the real world, most ERP systems handle currency rates, but please humour us for the sake of this example). In both solutions, every product is ingested into Enterspeed when it’s updated in the ERP system and the custom script is triggered to run the ingestion into Enterspeed when the currency rates have been validated.

Solution 1: Pre-processing per product

In this solution, the schema definition for the product in Enterspeed includes the business logic to query the ingested currency conversion rates from Enterspeed and convert the price to a nice, rounded number. Each product creates a list of prices with the currencies. Fetching the product from the Delivery API simply returns all prices.

There’re two methods to build a UI that only displays the selected currency option. The first method is to use a backend-for-frontend layer that can accept a query string parameter and then utilise that to filter out the other currencies. The other method is to use the logic in the frontend layer (either server side or client side rendered).

Solution 2: Request time conversion

Another solution is to create two different views in Enterspeed: 1) product view and 2) currency rate view. Both views can be requested by one Delivery API request, but the actual logic that calculates the price (with rounded numbers) is deferred to either a backend-for-frontend layer or the frontend itself.

Bonus solution: The non-Enterspeed solution

Imagine a world without Enterspeed... yeah, we know, it’s nutty thought 😉

A third way to solve the above scenario is to build a custom Product-service with its own data store and runtime – such as a SQL server and an Azure Function. The service would be responsible for both the product data and the currency conversion.

Choosing your own way

Of the three solutions, one example is a pure custom build, and two examples are “build it together”. As mentioned, every context and organisation are different, so it would be irrational of us to give a clear-cut recommendation on build vs. buy. What we do want to say is that when choosing technology, you need to think about what kind of problems you want to solve.

Some of the problems you’ll need to address with a pure build strategy are the non-functional requirements:

• Scaling/performance
• Backup/restore
• Maintenance
• Observability/monitoring

The question you then need to answer is whether the value that the customer code creates is sufficient to fund the expenses for solving the above problems.

With a build it together strategy, you’ll be able to focus on creating business value with writing just the appropriate amount of code. But of course, adopting new tools in your tool belt comes with a learning curve.

Some of the concrete learnings that we see developers go through in Enterspeed is:

• no dynamic code evaluation on request time
• debugging with asynchronously pre-processing
• too aggressive/in-efficient pre-preprocessing.

Summing up

The “not invented here syndrome” is a real thing, and writing just a bit more code is rarely considered a negative thing. As we’ve tried to show you, writing your own code comes with more responsibility, more chores, and more cost.

The need for "control" is an often-cited reason for building software yourself, but in our opinion, control can be more of a subjective feeling than an objective measurement stick. We don't want to remove the human element in decision making but merely encourage you to reflect on the reasons for deciding what to do in the build vs. buy question – and suggest bridging the gap with build-it-together.