You may have heard the pitch – get your new multi-carrier shipping software solution in just days. For startups or small businesses, this may be just what they need, but for mid-market and enterprise brands, if it sounds too good to be true, it probably is.

On top of an impossibly fast implementation, these Install in Days solutions promise no on-premise install, self-configuration of carriers (and at no additional cost), “easy” self-integration into your Enterprise Software Stack (ESS), and no upgrades. What they don’t want you to know: most “premise” based software solutions offer the same capabilities but have additional options that many “install in days” companies cannot extend.

To weigh the options, we will take a closer look at web-only and premisable (a solution with the ability to be installed on-premise).

No On-Premise Installation

A web-only solution can control ease of configuration. A good premisable solution should also provide APIs and UIs that allow for easy configuration of simple tasks, such as the setup of standard carrier services. Premisable solutions can also provide the ability to configure contract-only services that are often not available in the carrier APIs (and not available in web-only solutions, as a result).

The Response Speed of the Solution

However, web-only solutions cannot claim to force a carrier API to go any faster. They cannot reduce the round-trip time from each piece within your Enterprise Software Stack (ESS) to their API. It is not uncommon for a full rate shop to take over 1,300 milliseconds (1.3 seconds) not including the time required to execute your business rules!

Not only can a premisable solution perform the above, but it can also be installed in the same data center as the key pieces of your ESS, helping to control network latency. These solutions can also perform carrier rate, ship, and labeling computations directly inside that data center – removing the external dependency and dramatically increasing the speed of response times. It is not uncommon to get response times, even with business rules, of 300 milliseconds (.3 seconds) or less from a premisable solution.

Availability of the Solution

All good Multi-Carrier Shipping Software (MCSS) should incorporate a stateless solution, meaning each API transaction lives independently of any prior or subsequent API call. This is the key to allowing a distributed solution to provide high availability of shipping services.

It might be comforting when a web-only solution says they are hosted on one of the major PaaS (Platform as a Service) providers, but we have all seen problems every year with the major PaaS solutions (Amazon Web Services outage and Azure outages) on the market. A premisable solution can still leverage the same PaaS providers, but it can also be installed in your data center. This hybrid-style solution provides for tiered degradation of services, rather than a complete stop.

Self-Configuration of Carriers & Costs

Customers with few carriers and normal contracts should have a means of adding origins, accounts, and other configurable items. But when this reaches a level of complexity that can cost tens of thousands per day in mis-shipped packages if misconfigured, the ability to reach out to professional services, who know your implementation and unique business, makes the difference between a “good enough” solution that meets most of your needs and an excellent solution that meets all of your needs.

As far as costs for adding a carrier, MCSSs that don’t charge by the carrier are either charging by the transaction or they are reselling rates. This means they are making a margin off every shipment processed. That might be a flat fee across the board, or it could be a percentage of each transaction. This can really add up the more you ship. For early startups, this may be a better deal if you don’t have the leverage to get the rates you need but once a company has grown past the startup stage, it is difficult to know if you are still getting a “good deal” using these “reseller rates.”

The MCSSs that charge by the carrier are being upfront with customers. They understand the amount of effort required to create and maintain premisable carriers and APIs, and they are charging their customer based on the effort for the engine (a one-time cost), rather than how much the engine is used. Without the incentive to push you towards the carrier that provides them the largest cut, all carriers within the right premisable MCSS are on a level playing field, benefiting you with a carrier-agnostic platform.

“Easy” Self-Integration into Your Enterprise Software Stack (ESS)

The latest technology makes it possible for a company to quickly add basic shipping functionality to any single application in your ESS. As with self-configuration, complications arise with complexity, such as when you need a business rule. The IT person that is connecting the company’s software to the shipping API adds a few more lines of code. Later, when another business rule is needed, they add to that code. This continues in that one system, and at the time, seems rather manageable.

But many companies need to quote pricing on their website, and in their sourcing system, and in their WMS. Modern retailers need their OMS to contact the shipping system to include shipping costs as part of the sourcing logic. E-commerce suites might be able to get the results from the OMS, if one exists, or they must connect to the shipping system to set proper expectations for the customer. Though the WMS is the “normal” place to connect shipping software, many companies have more than one WMS. Yet another “easy” place that needs to be connected.

The next logical conclusion is to just connect each system in the ESS to the shipping system API. This would entail someone spending time in each piece of software to connect them to the same API, recode all the business rules, and test to ensure that all the systems act the same. Don’t forget, every time a change is needed, code needs to be rewritten within each system.

Why? Because few web-only systems have a place to put the business rules on the shipping system side of the API, leaving a shipper to add them into the appropriate place. Most premisable shipping solutions have a dedicated area for business rules, meaning business rules are written once and are usable in all the systems. When a change is made, it thereby affects all systems. When created inside the shipping system, premisable solutions can have the shipping software vendor’s professional services team build the business rules.

No Upgrades

Many have had ESS vendors charge enormous amounts for upgrades, which stings. But software companies solved this years ago by moving to a “continuous integration, continuous deployment” (CI/CD) strategy for their solution, popularized by the Agile software development approach. These CI/CD solutions are often referred to as “version-less.”

The real key to a version-less solution is a strong API contract between the product and the rest of your ESS. If the API contract is not going to change for years, the supporting modules and containers can be switched out multiple times per day if needed, or once or twice per quarter, with no change to the API.

However, carriers will come out with new services that the API contract might not have had the fields to support. Although, rare, a well-designed contract change will have minimal to no impact on the rest of your ESS.

Deciding for Your Business

Your company might be a fit for the “install in days” small parcel multi-carrier API-based solutions on the market. After reviewing the above information, it should be easier to see if the limitations of most web-only API aggregators will meet your logistics needs.

If you’re having second thoughts about web-only solutions, or are in the process of implementing one, you are now armed with the industry knowledge and questions to ask your vendors. Choosing the right MCSS for your unique business is no easy task. It requires extensive research on the operational end, as well as the IT side, and sometimes it’s hard to get through all the fluff and discover exactly how well a solution will fit and perform.

Justin Cramer is Co-Founder of ProShip, where he has deployed, designed, or consulted on over 300 customer solutions within 4 continents and has designed shipping solutions executing more than 3 million labels a day. Listed as one of Supply & Demand Chain Executive’s 200 “Pros to Know” in 2019, Justin has been on the IT side of shipping since 2001.