Click, Ship, Repeat: Building Software That Powers Action in the Real World

Early in my career, I built an interface to power a warehouse’s receiving station. I was proud of what I thought was a well-designed, sleek end product. However, it turns out that it wasn’t functional or intuitive for the warehouse operator, who said in no uncertain terms, “This is the stupidest thing I’ve ever seen.”

Ouch.

It was an early lesson in building software products that can be applied in a physical setting—in this case, a warehouse. If the software powers an interface that looks nice but isn’t built for the real world, it’s useless. 

While what I had built looked nice (to me, at least), it didn’t include the functionality that made it truly useful for the receiver—which was the whole point.

Today, my company, Flowspace, records over 200,000 physical events daily across our e-commerce fulfillment network. I’ve become intimately familiar with the unique requirements of building technology that depends on the real world.

Knowing these events occur is only one challenge in building software for the physical realm. The other is orchestrating the events optimally to enable efficient, reliable fulfillment, and interoperability with other critical technology systems.

This article details the ways in which developers should approach the unique challenges that emerge when building digital software that powers action in the physical realm.

SaaS in a Material World

Software-as-a-service (SaaS) products typically power a lot of invisible work. One example pertinent to the e-commerce space is Shopify. 

Brands can use Shopify to launch a store in just half an hour without the need for a physical storefront. Merchants control their shop's look, feel, and function. They can incorporate over 6,000 apps and integrations to enable additional features and connect to third-party platforms. However, to the end shopper, what appears is a simple, seamless storefront that enables e-commerce purchases.

Looking at the other side of the e-commerce coin—the fulfillment piece—SaaS is far different. Here, logistics must action a physical command. Unlike those technologies that only exist in the cloud and on screens, there is a 0/1 status with fulfillment. To a merchant’s end consumer, the question is: “Did my package arrive or not?” 

In the real world, software must consider hundreds of levels of physical granularity that impact algorithmic conclusions. The code can be perfect, but real-world actions outside of the software’s control add a layer of complexity for physical SaaS.

Was the order received by the facility on time? Did the operator pick the right product from the shelf? Does the software direct them to the right-sized box to select the optimal, most cost-effective carrier? Was the product delivered on time and as expected, or did the package get lost, damaged, or delayed in transit?  

In all of these scenarios, the software powering that fulfillment process must execute an action occurring on the ground to produce the best result.

The Unique Challenge of Fulfillment Software

Software systems that power both digital and physical products have errors that occur. But in a physical system, the bug can lead to real-world problems, such as mispicked items, late trucks, or workers with nothing to do. 

That is why logistics software requires three critical components: accuracy, interoperability, and efficiency. If not, inventory levels will be incorrect, platforms won’t talk to each other, orders will be delayed, and everyone will be upset.

The entire ecosystem depends on data accuracy and integrity. Failure to provide that data or a failure in computing may not lead to the desired outcome, which is efficient, reliable fulfillment. 

This all hinges upon systems talking to one another—especially vital for e-commerce with its various touchpoints and marketplaces. When data lives in silos and other retail tech systems can’t communicate effectively, merchants don't understand what’s happening. Thus, best-in-class e-commerce execution cannot be achieved without best-in-class software.

Beyond data accuracy and platform interoperability, the system has to be optimized. For example, if a merchant routes an order to a non-optimal facility, it has to ship further and faster to reach the customer, adding cost. The margins are slim for the merchant and warehouse operator, so every optimization matters. For the end consumer, every effort to seamlessly deliver a product to them post-purchase is vital.  

Building Software That Powers Physical Operations

The first critical piece of building fulfillment software for the physical world is a deep understanding of the customer. What is their business? What are their product requirements? The data they collect, the analysis they perform, and the actions the software must take depend on understanding and solving their end-consumers' needs. 

To effectively build software for the real world, experience is necessary. At Flowspace, we gain knowledge by involving engineers with our customers – directly on the warehouse floor – to watch how operators perform an action manually, propose an idea, and iterate from there.

The second aspect of building fulfillment software for the physical world is data. Collect as much real-time data as granularly as possible. Even if it’s not used immediately, this rich source of information could be useful weeks, months, or years later to fuel the analysis or optimization of a new algorithm or process. Data storage is cheap, and you may be unable to backfill the missing data moving forward.

Finally, experiment and iterate. Often, an idea that seems plausible in theory simply doesn’t track in the real world. My early experience with the warehouse operator’s response to my software interface proves this.

The Future Of SaaS In Operations

The reality of the real world is that it exists. A lot of tech founders have a desire for disruption and argue for a more beautiful solution, ecosystem, or way of working. That's the great thing about technology – there is always something bigger, better, and more powerful being built.  

But another aspect of the real world is that some things are slow to change, so try to strike a balance between building solutions that action against what exists and what’s ultimately possible.

There is an opportunity to orchestrate and optimize physical systems through software. Pure software applications can model optimal scenarios before the real-world work happens. Collecting as much rich and real-time data as possible makes systems more intelligent and capable. Ensuring all platforms are interoperable drives best-in-class execution.

And because this all powers action in the real world, there’s added joy in knowing that the work will ultimately make someone’s life easier, better, or more enjoyable. 

What lessons have you learned from building software products for the real world? Share in the comments below, and join The CTO Club newsletter for more industry news and discussions.