So, you’ve reached the hard conclusion that [you need to build some middleware](https://nebulab.com/blog/ecommerce-middleware) for your Shopify store—perhaps you need to integrate with an exotic third-party system that doesn't offer a native app, or you have a complex subscription flow that cannot be accommodated by an off-the-shelf solution.

But once you've mapped out all the business requirements, you're still left with a million decisions to make: where should you host your middleware? What's the best architecture, a monolith or microservices? Should your code run on a fixed cadence or respond to Shopify's webhooks?

In this article, we're publishing some broad technical considerations we've collected over the years while working on middleware implementations for our clients. We suggest treating these as general guidelines: your mileage may vary depending on your requirements, team composition, and growth stage.

Let's dive in!

## Reactive vs. Scheduled Middleware

The first crucial architectural decision you'll make is whether your middleware should be reactive or scheduled.

Reactive middleware responds immediately to events triggered by external actions, such as customer purchases or inventory updates. It's the preferred choice when dealing with time-sensitive business logic, such as sending email notifications or updating order information.

In reactive middleware, incorporating a queue mechanism is imperative to facilitate the asynchronous processing of incoming event payloads. By decoupling the reception of webhooks from the actual processing logic, queues create a buffer that allows your middleware to absorb workload spikes seamlessly. They also mitigate the risk of data loss during processing disruptions, ensuring that all incoming events are reliably processed.

Queues are de facto mandatory when building middleware for Shopify, as your store will deactivate your webhook subscription [in case of multiple failures/timeouts.](https://shopify.dev/docs/apps/webhooks/best-practices#respond-quickly)

Additionally, you should design reactive middleware to be idempotent and resilient against race conditions, e.g., when handling duplicate or out-of-order event notifications. This allows brands to mitigate the risk of data corruption.

Scheduled middleware, on the other hand, operates on a predefined cadence, executing tasks at regular intervals. It's the preferred choice when dealing with bulk data operations, such as subscription processing or (in some cases) integrations with third-party systems.

Because scheduled middleware might process a substantial amount of data during each execution, optimizing performance and resource utilization is essential. This can be achieved by grouping data into manageable chunks and processing it in batches, minimizing resource contention and maximizing throughput. When integrating with third-party systems, it's also essential to be mindful of rate limits, maximum payload sizes, and the opportunity to leverage batch APIs whenever available.

By understanding the distinct functionalities of reactive and scheduled middleware, businesses can leverage these tools strategically to orchestrate complex workflows and optimize their Shopify operations for efficiency and scalability.

## Monoliths vs. Service-Oriented Architectures

Especially in larger projects, it's tempting to implement your middleware logic as a constellation of microservices, making up what's typically called a Service-Oriented Architecture, or SOA for short. Technically, these services may run as traditional long-lived web applications, but we often see them deployed in serverless environments such as AWS Lambda or Cloudflare Workers.

The theory is that this design increases technical freedom and reduces maintenance overhead: for instance, the subscription processing engine may be implemented using a technology different from the WMS integration. Plus, if they're deployed as serverless functions, there's no need to worry about scaling the services to match transaction volume because the infrastructure provider will handle that responsibility for us.

In our experience, however, most SOA setups suffer from premature optimization. The additional freedom and scalability come at the expense of a more complicated development and infrastructure setup, with multiple codebases to maintain and constraints on the deployment process. Code reuse is also more complicated, and rather than going through the hassle of building and maintaining an internal SDK, engineering teams often end up duplicating the shared code. In other words, the additional effort and complexity often outweigh the gains.

Because of this, when faced with complex middleware architectures, we always consider whether there's a chance to simplify things by moving to a [Majestic Monolith](https://signalvnoise.com/svn3/the-majestic-monolith/) deployed as a traditional, long-lived Web application. While they're not as fancy as a serverless SOA, monoliths have several advantages:

* Engineers only need to work in one codebase to make orthogonal changes, which makes it easier to work atomically.
* Code sharing across API endpoints and scheduled jobs is trivial since everything's in the same application.
* We only need to write and maintain a single deployment pipeline, which makes deployments simpler and more robust.
* We eliminate the need to deal with network failures, data model inconsistencies, and data synchronization issues.
* It's still easier and cheaper to find and onboard new engineers on a monolith vs. a SOA.

This is not to say that microservices and serverless architectures are always bad. There are situations where they can help with scalability, e.g., for trivial middleware that only needs to respond to a specific webhook (in which case a serverless infrastructure is acceptable) or when a particular piece of business logic can be optimized by rewriting it in a more suitable technology. However, these pros always need to balance against the additional complexity introduced into the system.


## Keep Your Options Open

As we mentioned at the beginning of this article, your mileage may and will vary, especially as time passes and your middleware starts taking on more responsibilities. Our suggestion is to regularly re-evaluate your design and architectural choices to ensure that your current setup is still the ideal fit for your needs.

Furthermore, remember that the best middleware is no middleware. Whenever you see an opportunity to simplify your architecture by removing custom logic in favor of a third-party solution, you should seriously evaluate it. E-commerce brands are not tech startups, and every dollar you save in development costs is a dollar you'll be able to invest in other areas of the business.

If you are struggling with fine-tuning your custom integrations or business logic, [don’t hesitate to reach out](https://nebulab.com/contact-us): we can help you navigate and streamline the complexity, finding the ideal setup for your brand.

Designing and Scaling High-Throughput Shopify Middleware

On August 28, 2025, [Shopify will sunset the ability to customize your `checkout.liquid` template](https://shopify.dev/docs/themes/architecture/layouts/checkout-liquid).

Newly created stores on the Shopify platform will already notice that they cannot use this template to customize their payment steps, thank you, and order status pages. Shopify is reigning in control over these pages and forcing merchants to migrate to [Checkout Extensibility](https://www.shopify.com/plus/upgrading-to-checkout-extensibility?shpxid=169152ee-9333-4686-13FB-D40F49B3F520). [Recent articles](https://www.shopify.com/plus/customers/monos) published by Shopify promote Checkout Extensibility as the faster and more maintainable way to extend your store’s checkout experience.

Unfortunately, with limited control over the checkout, thank you, and order status pages, merchants have also lost the ability to place tracking pixels on these pages. To remedy this, Shopify has introduced [Web Pixels](https://shopify.dev/docs/apps/marketing/pixels). Web Pixels can be either standalone (Custom Pixels) or part of a Shopify App (App Pixels), and merchants can use them to track both predefined and custom analytics events.

In this article, we’ll examine the inner workings of App Pixel and Custom Pixels and discuss alternatives merchants can deploy when they need additional granularity in their data.


## App Pixels

App Pixels are part of Shopify Apps that you install: for example, the [TikTok app](https://apps.shopify.com/tiktok) provides an App Pixel out of the box–you just need to enable it from the Shopify Admin.

There are several benefits to using App Pixels over adding custom tracking code to your theme: the new structure simplifies the installation and removal of the pixel, allows you to comply with customer privacy regulations out of the box, and streamlines the integration of your tracking logic across different types of checkout (e.g., Shop Pay vs. one-page vs. three-page checkout).

While this new approach to tracking pixels is a significant step forward, not every platform has a Shopify App available; therefore, not every platform exposes an App Pixel. If your tracking platform does not have an App Pixel you can install, you might need to go with Custom Pixels.


## Custom Pixels

Custom Pixels can be used to integrate tracking platforms that do not expose an App Pixel or when you want to track a custom event or datapoint. Your pixel can subscribe to a [fixed set of events that Shopify publishes](https://shopify.dev/docs/api/web-pixels-api/standard-events) or to [custom events](https://shopify.dev/docs/api/web-pixels-api/emitting-data) published by your theme and send the information to an external service.

Similar to App Pixels, Custom Pixels can be enabled and disabled through the Shopify Admin, and they automatically conform to the customer’s privacy preferences, which makes them a powerful tracking solution fully integrated within Shopify.

With that said, Custom Pixels also have their limitations.

First of all, Custom Pixels [are sandboxed in iframes](https://shopify.dev/docs/apps/marketing/pixels#lax-sandbox-custom-web-pixel). Because of that, you might run into limitations with specific tracking scripts. We recommend working with your tracking platform to resolve these issues whenever possible.

Secondly, Custom Pixels only have access to a limited set of data. During a recent migration from custom checkout scripts to Web Pixels, we encountered a limitation on some Custom Pixels, specifically around conversion tracking. By default, Shopify publishes the `checkout_completed` event. As part of this event, Shopify [sends along limited order- and customer information](https://shopify.dev/docs/api/web-pixels-api/standard-events/checkout_completed). However, The tracking tags installed on our store used additional information, like the customer order count and type of purchase, that we originally included in the checkout script.

If you run into such limitations, there are a few alternatives you can try. That being said, each comes with trade-offs, and you should ensure the additional implementation and maintenance effort is worth it.


## Server-Side Tracking

Instead of relying only on Web Pixels, you can use server-side tracking to enrich (or replace) the data sent to your tracking platforms. Because this logic is not running in the browser, you can call the Admin API and access attributes that would otherwise not be available through the Storefront API.

This is a significant advantage, but it comes at a cost: you’ll have to manage custom code that runs on a separate server (or on a platform [such as Gadget](https://nebulab.com/blog/custom-shopify-automations)), and you will not be able to benefit from Shopify’s primitives for Web Pixels, putting the onus on you to deal with aspects such as privacy preference compliance.

An interesting middle ground is to use the [Shopify Flow](https://apps.shopify.com/flow) app. With the ability to [send HTTP requests](https://help.shopify.com/en/manual/shopify-flow/reference/actions/send-http-request) and the [new action to run custom JavaScript code](https://help.shopify.com/en/manual/shopify-flow/reference/actions/run-code), Flow gives you a robust set of tools to send information to an external API with attributes that your Web Pixels or frontend logic cannot easily access. You’ll still need to maintain the logic required for your solution, but Shopify will at least take care of hosting and executing it.


## Checkout Extensions

One of the benefits of the new Checkout Extensions system is that you can inject custom logic and UI into your checkout. Shopify allows extensions [to publish custom analytics events](https://shopify.dev/docs/api/checkout-ui-extensions/2024-01/apis/analytics) with any attributes you want. As Checkout Extensions have fewer restrictions than Custom Pixels, they can be used to pull extra information from the Storefront API and emit a custom analytics event. Your Custom Pixel can then send this event to any third-party tracking platform.

The implementation and maintenance cost here is relatively low: as long as your Checkout Extension adheres to the official APIs, this can be a reasonably robust solution. However, because Checkout Extensions can only access the Storefront API, you will have access to a more limited dataset than with server-side tracking.

You will also need to set up a custom Shopify app on your store and expose the extension to your theme. Luckily, Shopify makes this relatively easy by providing robust tooling and hosting the app directly, which means you don’t need external servers.


## Session Storage

Finally, another approach is to use the browser’s Session Storage to temporarily store attributes as the customer browses your store. You can then retrieve these attributes from your Custom Pixel at checkout. 

For example, you could use Session Storage to store a referrer URL here or the type of order the customer is completing (OTP vs. Subscription) _before_ checkout starts. Custom Pixels have access to Session Storage, which means they can read these attributes when the `checkout_completed` event is fired and forward them to your tracking platform.

Using Session Storage is the simplest way to add additional context to any analytics event: there is no need to set up a custom Shopify app, as all the logic can live in your theme and Custom Pixel. Additionally, in contrast to Checkout Extension, it not only allows you to include additional data that you read from Shopify’s API but also to collect behavioral data while the customer is browsing your store.


## Balancing Data Enrichment with Maintenance Effort

Web Pixels are a robust tracking solution fully integrated within Shopify’s ecosystem.

With more platforms getting on board, App Pixels are quickly becoming a straightforward and reliable solution for installing tracking pixels. In addition, Shopify enforces that the customer has opted into data collection before enabling these pixels, which is a step that is often overlooked when implementing tracking tags on a storefront.

Custom Pixels have some rough edges: their sandbox allows Shopify to enforce similar privacy constraints as for App Pixels but also creates situations where tracking tags don’t work, leaving merchants at the mercy of the tracking platform to build an App Pixel or to update their tracking script.

Finally, when neither App Pixels nor Custom Pixels provide the right data, you can consider alternatives such as Server-Side Tracking, Checkout Extensions, or Session Storage.

We work closely with business stakeholders to determine what events and data we need to track and how the data will be used. We then use that information to build a solution that will satisfy the brand’s needs while also minimizing the technical maintenance burden.

If you are migrating to Checkout Extensibility or need assistance with your existing tracking setup, [don’t hesitate to reach out!](https://nebulab.com/contact-us)

Web Pixels on Steroids: How To Enrich Your Shopify Analytics

In the complex world of e-commerce technology, Shopify stands out as a beacon for businesses eager to establish or expand their online presence. Its user-friendly interface, coupled with a vast ecosystem of apps and integrations, has made it the go-to platform for merchants. Still, the convenience offered in the off-the-shelf package is not enough for everyone.

While Shopify's app store provides many easy-to-install solutions that promise quick wins, the reality is that the more complex your business needs, the less likely you'll find an app that fits the requirements. And, as businesses grow and operations become more complex, the limitations of a simple Shopify build become more and more apparent until they bring businesses to a crossroads: either simplify operations to fit into Shopify’s boundaries, or heavily customize Shopify to play by their rules.

The former path might be acceptable and sometimes even advisable for smaller stores. Building complex Shopify customizations requires significant resources and can be a source of [technical debt](https://nebulab.com/blog/shopify-technical-debt); as such, these projects should always be justified by a clear and compelling ROI.

But for brands in the upper midmarket/enterprise segment, building more complex automations and customizations on top of Shopify often makes perfect sense: these companies have complex internal workflows, custom tooling, and nuanced policies, and their e-commerce platform must learn to adapt and play nice with the existing ecosystem.

Luckily, Shopify’s ecosystem comes with rich tooling designed to create custom apps and integrations. In this post, we'll delve into some of these tools. More specifically, we’ll cover Shopify Flow, Zapier, e-commerce iPaaS Solutions, Gadget, and Greenfield Apps, exploring their pros and cons, ideal use cases, and some examples of the customizations they enable.


## Shopify Flow

[Shopify Flow](https://help.shopify.com/manual/shopify-flow) is a tool built into Shopify that allows creating automations without leaving the platform. It's a basic yet powerful way to respond to events generated within your online store (e.g., a new order being placed) with a set of actions (e.g., sending an email to your staff).

**Pros:**

* **Seamless Integration:** It’s designed specifically for Shopify, ensuring a smooth integration with your store. It’s Included in Shopify for free; no need to pay for extra software.
* **User Friendliness:** Shopify Flow comes with a visual workflow builder that requires no coding, making it accessible to non-technical users.
* **Third-Party App Support:** Shopify apps can extend Shopify Flow by adding their own triggers and actions, which expand the possibilities of the tool. This functionality is only available to Shopify Plus merchants.

**Cons:**

* **Complexity Limitations:** While powerful, Shopify Flow does not always cater to highly intricate integration needs that require custom coding.
* **Partial Support for External API Calls:** You can create an action that performs an API request to an external service (if you’re on the Shopify, Advanced, or Plus plan), but you cannot use the data you receive in any way. Shopify has committed to solving this in 2024.
* **Partial Support for External Emails:** At the moment, it's not possible to send emails using Shopify Flow, except for emails to staff members or as part of email marketing automations. You cannot send transactional emails to your customers or anyone else.

**Ideal Use Case:** Shopify Flow is your go-to for automating operational tasks within Shopify's ecosystem, particularly if you're a Shopify Plus user and can use all of the functionality it offers. It's ideal for businesses looking to streamline processes like tagging high-value customers for exclusive offers or automating restock notifications.

**Example Customization:** Automating the tagging of VIP customers based on their spending history and automatically enrolling them in an exclusive loyalty program.

## Zapier

[Zapier](https://zapier.com/) can be a good alternative to Shopify Flow, if you find its limitations unbearable. Via the Zapier app for Shopify, you can connect Zapier to your Shopify store and pick from an extensive list of triggers and actions to build your automation.

**Pros:**

* **Wide Range of Integrations:** Zapier can connect Shopify with over 3,000 web services, facilitating many different kinds of automations.
* **No Coding Required:** Zapier’s interface is similar to Shopify Flow, but offers even more power by allowing you to build more complex, more robust automations.
* **Rapid Deployment:** You can quickly set up new integrations and automations without the time and cost associated with custom software development.

**Cons:**

* **Pricing:** Zapier’s costs can quickly escalate as you increase your usage of the platform and build more complex workflows.
* **Dependent on Third-Party Connectors:** Even though it boasts more integrations than Shopify Flow, Zapier still relies on the availability and limitations of third-party connectors.

**Ideal Use Case:** Zapier is best suited for businesses that find Shopify Flow too limiting, but still need to build automations or integrate Shopify with other platforms quickly and without custom development.

**Example Customization:** Automatically adding new Shopify orders to a Google Sheets spreadsheet for advanced reporting and analysis.


## E-Commerce iPaaS

Integration Platform as a Service (iPaaS) solutions connect your online store with a variety of other systems, such as ERP, POS, and warehouse management systems (WMS), facilitating the automation of business processes across platforms. There are plenty of iPaaS solutions that integrate with Shopify–our favorite are [Patchworks](https://www.wearepatchworks.com/), [VL OMNI](https://vlomni.com/), [High Cohesion](https://highcohesion.com/), and [Pipe17](https://pipe17.com/).

**Pros:**

* **Connector Ecosystem**: Unlike Zapier, which is a generic automation platform, e-commerce iPaaS platforms specialize in connecting e-commerce platforms like Shopify with CRM, ERP, POS, and WMS systems.
* **Data Integrity:** E-commerce iPaaS platforms were designed to ensure data consistency across platforms, reducing synchronization errors and improving operational efficiency.
* **Bespoke Support:** with most iPaaS platforms, you can typically engage their customer support or professional services team to build connectors that are not already available.

**Cons:**

* **Integration Complexity:** Setting up more sophisticated connectors and automations may require technical expertise to configure and manage.
* **Cost:** The investment required to use an iPaaS reflects its enterprise-level capabilities, making it more suitable for larger businesses with complex needs. Most platforms will charge you per connection or event (e.g., a new product being created).

**Ideal Use Case:** E-commerce iPaaS solutions are ideal for medium-to-large businesses that require robust, real-time integrations between Shopify and other enterprise systems.

**Example Customization:** Integrating Shopify with an ERP system to automate order management, inventory management, and financial reporting, streamlining operations and reducing manual errors.

## Gadget

[Gadget](https://gadget.dev/) is a powerful full-stack serverless platform that allows building and hosting custom Shopify Apps, skipping all the repetitive tasks and accelerating the development cycle of your custom app. Through Gadget, you can accomplish all the automations and integrations that are not possible with off-the-shelf apps and integrators.

**Pros:**

* **Rapid Development:** Gadget offers a rapid development environment for Shopify apps, reducing time to market and human error.
* **Scalability:** Gadget is built to handle high volumes of data and traffic, making it suitable for growing businesses.
* **Developer-Friendly:** Gadget provides advanced tools and resources tailored for developers who need to create sophisticated apps, like Shopify API version management and pre-built React frontends that are compatible with Shopify’s security policies.

**Cons:**

* **Learning Curve:** Developing with Gadget requires a significant amount of technical knowledge, making it hard to access for non-developers.
* **Cost:** Custom apps may involve higher initial development costs compared to simpler integration approaches.
* **Single Environment:** As of today, multi-environment applications (staging+production, for example) are not supported. However, Gadget claims the feature will be released soon.

**Ideal Use Case**: Gadget is a powerful choice for tech-savvy teams looking to build a private Shopify app for their brand as quickly as possible.

**Example Customization:** Creating a custom loyalty program that’s not supported by any off-the-shelf loyalty apps for Shopify.


## Greenfield Apps

When none of the tools above is capable of fulfilling our complex business requirements, we are left with one extra solution, probably the most flexible one: building a custom Shopify app completely from scratch. We call these “Greenfield Apps.”

Greenfield Apps can extend the functionality of your Shopify store in whatever way you want, as long as your desired workflow is supported by Shopify’s APIs.

**Pros:**

* **Malleability:** Greenfield apps can be designed to meet your exact business requirements, offering unparalleled flexibility.
* **Direct Integration:** You can use greenfield apps to interact with all of Shopify's APIs, enriching your online store with custom business logic, Storefront and Admin UI components, and complex automation and integration workflows.
* **Technical Scalability:** Greenfield apps can grow with your business, accommodating new features and processes as needed, without financial or technological lock-ins.

**Cons:**

* **Development Cost**: Custom development is typically more expensive and time-consuming than pre-existing solutions.
* **Maintenance Effort:** Greenfield apps require ongoing maintenance and updates to ensure compatibility with Shopify's evolving ecosystem. \

**Ideal Use Case:** When your business requires unique functionality that cannot be addressed with existing apps or tools, greenfield Shopify apps provide a solution tailored specifically to your needs.

**Example Customization:** A bespoke app that provides a UI for a marketplace’s vendors to update product prices and availability, and instantly propagates those updates across multiple warehouses within your Shopify storefront.

## Complexity Is Not Always a Bad Thing

While Shopify's app ecosystem offers a solid foundation for run-of-the-mill retailers, expanding beyond these boundaries unlocks new levels of operational efficiency, customization, and customer satisfaction.

When considering your options for customizing your e-commerce store, remember that the right choice depends on your needs, budget, and technical capabilities. Make sure that you’re factoring in all of these elements before committing to a specific solution.

Building custom features and integrations may seem daunting, and might require resources and expertise that you don’t have in-house. But at the end of the day, this growing complexity is often a testament to your brand’s growth and the need to evolve your customer experience.

If you need help launching a custom feature or integration for your Shopify store, [feel free to reach out!](https://nebulab.com/contact-us) Our engineering team would love to help you figure out the right solution.


Building Custom Shopify Automations, From Beginner to Pro

There’s nothing more frustrating than trying to complete a puzzle, only to realize you’ve misplaced one of the pieces and there’s no way to finish the thing.

But what if you could _build_ that custom piece, designing it with all the right knobs and holes, allowing you to complete the puzzle? Imagine you could also paint it to perfectly complement the puzzle’s design. How amazing would that be?

Well, for real-world puzzles, you’re probably out of luck. But when it comes to computer systems, that’s pretty much what middleware does: just like your custom-built puzzle piece, middleware is custom software that streamlines the connection between different business applications, systems, or APIs, allowing them to communicate and collaborate effectively.

In e-commerce, middleware is usually found in enterprise applications, where companies often need to connect their proprietary systems to third-party vendors. However, middleware is not just for e-commerce giants: in specific scenarios, smaller brands can also use middleware to enhance the agility and robustness of their e-commerce setup.

In this article, we will explore the typical use cases for middleware software, the pros and cons of building your own, and how to do it correctly.


## When Does an E-Commerce Brand Need Middleware?

When you’re a large enterprise company, you typically have a dedicated IT department that handles system integration, and the responsibility for deciding when to buy or build middleware software lies with this department. In this case, you don’t need to worry about making such decisions.

But if you’re a smaller brand, you might be unsure when to think about middleware. Here are a couple of scenarios:


* You have found the perfect 3PL provider, but they don’t support your e-commerce platform out of the box.
* You want to use your existing ERP integration to generate invoices for your B2B e-commerce customers. However, the way your platform’s connector sends order data to the ERP is incorrect, and the resulting invoices are unusable.

In both cases, you could buy or build middleware software to integrate with the new system or adjust your existing integration. Just as a custom piece connects different sections of a puzzle, the middleware will bridge your different vendors together, ensuring they produce the desired results.

In general, whenever you want to insert yourself between different applications to streamline or adjust their data flow, middleware is the right solution.

With that said, adding middleware to your infrastructure is not free: let’s look at the complexity it can create and how to manage it.

## Middleware Seems Easy Until It Isn’t

Most of the time, your first middleware implementation is easy to build. You start from a well-identified business need, and the project goes almost flawlessly. Once online, you might find some edge cases that were not covered, but it’s usually pretty simple to address them. Everything’s under control, and everyone on your team is happy.

After a few weeks or months, you identify new business needs that are not satisfied by your existing system. Since the first iteration went well, you feel confident adding new functionality to the middleware–perhaps by integrating with a new external system.

As you work to reconcile the different data schemas, you feel like you’re getting pulled in too many directions: data management becomes more complicated, caching and scalability problems start popping up, and not even the people who built your middleware stack are quite sure of the data transfer flows anymore.

Back to the puzzle metaphor, the knobs and holes are the communication channels, while design and color are the data model that needs to be blended. You have already put many different knobs and colors in one giant puzzle piece, and every time you need to connect to a new part of the puzzle, you keep changing it, adding knobs and holes, and trying to blend the colors harmoniously.

What was simple and neat in the beginning has become increasingly complex over time.

It’s also interesting to note that the perception of middleware complexity does not increase linearly. Usually, it has a discontinuity point: everything seems smooth and easy, but once you reach the discontinuity, everything suddenly becomes complex and demanding. In technical literature, this condition is called _complexity creep_.

So, where does this complexity come from, and how can you manage it?

## Managing the Complexity of Middleware

Now that you understand the inevitable complexity of middleware, it’s time to look at a few ways to keep it under control. Drawing from years of experience, we've honed some practical strategies to manage and mitigate these challenges effectively.

Let's take a look!


### #1: First of All, Do You Really Need Middleware?

This might sound counterintuitive since this entire article is about middleware, but the best way to keep complexity under control is not to create it in the first place, and the most cost-effective middleware is the one that doesn’t exist.

This isn’t always possible, and middleware software is sometimes a necessary evil. However, we’ve often seen retailers reach for complex custom solutions when the stock functionality of their e-commerce platform or fulfillment provider would have worked just as well.

Before jumping into a middleware project, evaluate your vendors’ capabilities carefully–ideally, reach out to their support team and see if they can suggest any alternatives that will work out of the box.

Even when there are no alternatives, consider whether reframing your original request might lead to a much simpler solution: sometimes, the cost and effort involved in buying/building and maintaining your middleware doesn’t justify the return on that investment.

As a rule of thumb, if you can’t build a compelling business case around your middleware stack, and the only reason you’re building it is to make your life slightly easier, it’s probably better to hold off on the project until you can identify a pressing need.


### #2: Acquire a Bird’s-Eye View of Your Workflows

When you decide to build middleware, start the project by mapping the existing business processes. Don’t just focus on the process impacted by your middleware; instead, make sure to also cover upstream, downstream, and adjacent dependencies.

Sound too abstract? Let's make it more concrete with our ERP example:

1. First, describe what is happening in your internal and external software applications from when the order is made to when the invoice is sent.
2. Then, expand upstream, asking questions such as: “What are some of the promotions or discounts that could be applied to the order? How do we reflect that in the invoice?”
3. Finally, expand downstream, asking questions such as: “Does the invoice generation process only impact the ERP? How does it affect our CRM, supply chain or legacy systems?”

Back to the jigsaw puzzle metaphor, this process is like acquiring a view of the entire puzzle, and not just of the knobs and holes that surround our custom piece. Building this comprehensive understanding of your business workflows not only aids in your current middleware project but also helps you anticipate and manage future complexity.

The best part is that it doesn’t take ages to create this map: at Nebulab, we usually run a dedicated eight-hour workshop, remotely or in-person, to build the first version; we then spend a couple of hours now and then when we need to update it.

### #3: Adopt an Evolutionary Approach

Having a broad view of your business workflows doesn’t mean you have to build your entire middleware stack in one sitting. Quite the contrary!

The best approach is to build incrementally, one use case at a time, and get feedback from real-world usage. This feedback is essential to guide you in future development, refine your processes, and spark new ideas. It also makes it easier and more sustainable, reducing the chance that a middleware bug will severely impact your customer experience.

See it this way: The broader view tells you which direction to go, while the evolutionary approach tells you to put one foot before the other rather than making giant leaps. You have a complete vision of your puzzle, but you still build your custom piece one knob at a time.

## Your Middleware Is Critical Software

Once created, your middleware will become a central component of your brand’s tech stack: most likely, it handles your customer, order, or shipment data; it’s a critical piece of your customer experience, and it will negatively impact your operations in case of malfunction.

Because of this, middleware development should be considered mission-critical and treated accordingly: involve established vendors and highly skilled developers–ideally, someone with a track record of building high-traffic systems and who knows how to create resilient, high-quality software through best practices and automated testing.

In e-commerce, these competencies are rare. If you don’t have them in-house or in your partner network, [feel free to reach out!](https://nebulab.com/contact-us) We’ve supported tens of brands just like yours in designing, building, and maintaining their middleware solutions, and we know what it takes to make this journey as smooth as possible.


The Nebulab

Designing and Scaling High-Throughput Shopify Middleware

Web Pixels on Steroids: How To Enrich Your Shopify Analytics

Building Custom Shopify Automations, From Beginner to Pro

How To Design and Maintain E-Commerce Middleware