You are reading this article because you'd like guidance on integrating your client's business processes and backend systems with their eCommerce platform. For specialized eCommerce integration consulting, you can get the details on my homepage.

Level: Beginner

Proven strategies for preventing an eCommerce integration project from going over budget and off schedule

4 key lessons to take from software engineers about modular development and upgradability

Author: Dima Volo

Any marketing agency that has been around long enough has had projects that were supposed to take weeks end up taking months, and going deep into the red before they were handed-off.

You've learned and grown, and you're wondering how much to budget for an eCommerce integration and implementation and how long it'll take to get up and running.

The right answer is: no one knows.

Sure, pulling the technical pieces together for a quick and dirty test run isn't too complicated.

But getting a maintainable system in place for real-world usage by your clients and their customers for the long term isn't simple.

That's why PROCESS is important.

Before wasting resources, you can learn from well-tested principles in the software engineering world, to ensure your eCommerce integration comes in within budget.

Plan your eCommerce integration with (1) MODULAR architecture, in a (2) PHASED roll-out and (3) visciously ELIMINATE COMPLEXITY while (4) SHIPPING EARLY/OFTEN

A lot of Silicon Valley buzzwords in that solution. Let's break this down to understand it.

Infamous example of monolithic software

In the mid 1990's, Microsoft had arguably one of the best software engineering teams in the world. Windows 95 had been a smashing success, and Bill Gates was on stage to demonstrate the brand new, more stable and better engineered Windows 98 release.

Then this happened:

How does the world's premiere software company (at the time) experience a public failure on a system they tested for months before? Crashing and burning during a presentation they went over again and again?

Boxer Mike Tyson came up with the most concise answer:

mike tyson quote everybody has a plan until they get punched in the mouth

Put another way, huge software projects come with a huge statistical likelihood of elements breaking when they experience real world conditions.

That's why software engineers have learned how to mitigate the damage. Let's apply the same principles to your eCommerce integration.

  1. Modular architecture

    Modular architecture means your eCommerce integration project isn't one big thing: it's several small things, all of which talk to one another.

    A more concrete example:

    • You have a module which gets data from the orders API in your eCommerce platform. It stands on its own.← Let's call this the "Orders module"
    • You have another module which accepts data from the Orders API and exports that into a second system, like your ERP system. That module also stands on its own. ← Let's call this the "Export module"
    • Finally you have a third module. We can call this the "connector module". Its job is to grab data from the first module (Orders module) and give it to the second module (Export module).
    • Now we're thinking like modular architects. The more we can break down the pieces into smaller and smaller modules, the better off we'll be.

    If you're a marketing agency owner, modularization probably seems obvious to you. But in practice, for software projects, you have to ruthlessly insist on it to your programmers from the get-go (and remind them that this is a priority).

    Because the benefit of modular architecture is 1) when integration logic needs to be upgraded, it's confined to one place and 2) when something breaks, it's confined to one place.

    That makes your eCommerce integration less "brittle". When you go back 6 months later to fix some business logic somewhere, the whole system doesn't come crashing down in a cascade failure, because everything was hanging off of everything else.

    But that's not enough on its own. Let's look at another key approach:

  2. Phased roll-out

    Any agency owner this lesson well, but don't forget to apply it to your software team, no matter how little time you have before deliverables are due.

    Phased roll-out means you don't let your programmers go off to code in a cave for 3 months, then come back to you to unveil their masterpiece.

    Instead, every time they complete a little piece of the puzzle, you roll out to real users in your company (and friendly customers), who help you test and find bugs, and request features.

    Phased roll-out means that before the first line of code is written, you've already written on paper the following project phases:

    • The 'MVP' (Minimum Viable Product)
      An MVP version of software does the absolute minimum to be considered "working" or "effective". It's meant to prove you know what you're doing and there's no technological factor stopping you.
    • Version 0.1 (The Placeholder)
      More than an MVP, this version includes a rough draft or placeholders for most of the key features you'd expect in an eCommerce import/export solution. It's meant for a limited test by the project managers and a tiny group.
    • Version 0.5 (Debugging)
      This is a real-world testing version that you want your regular users to try. Your programmers will be watching carefully and fixing bugs on the fly. There'll be tons and tons of bugs.
    • Version 0.9 (Pre-production)
      The release. This is a production version that you know will have problems, but it's ready for prime-time. Keep your programmers on stand-by to fix errors and make upgrades as they come in.
    • Version 1.0 (Production)
      The "pretty solid" production version that you expect to work without catching on fire. Although it still might. But hopefully the majority of showstopper bugs were captured by this stage.
    • Version 1.1 - Version 10.0 (Production)
      The "upgrade cycle" versions. Continuously get real user feedback and incorporate it into your eCommerce integration to better match the way your people work, and save on human error during data entry.

    You'll notice that there's a leap there from version 0.1/0.5 to incremental updates in 0.9/1.0/1.1.

    This is because your programmers will accomplish 90% of the project during the first 10% of your schedule. That's would be great news, but...

    Finishing that final 10% to get your eCommerce integration to a usable state, and making it stable is what takes 90% of the time and 90% of the effort. Be aware of that going in.


    Counterintuitively, in software projects adding "just one more thing" creates knock-on effects throughout any system.

    It's a truism that any good software engineer keeps the number of moving pieces down to a minimum. Fine, you know this.

    Some programming architecture history

    The 'waterfall model' of software development was the go-to in the 1970s/80's. But large companies like IBM and Oracle learned that building big software solutions opens you up to "complexity creep".

    That's the phenomenon that adding or changing any one element puts an (unexpected) strain on the entire system, since every single element depends on every other one.

    Jason Fried, the creator of Basecamp, famously has this to say about planning software and adding features:

    Every additional thing now interacts with all the other things…. Let’s say you have ten things, now you add an eleventh. It’s not “one more thing.” It’s one thing that interacts with ten other things.

    This tells you something important: you must ruthlessly keep the feature set down to a minimum. Don't believe your software team when they say, "that'll be easy to add" or "we can get that added in one afternoon".

    No human being on Earth is good at estimating how long complex software takes to build. Especially not programmers.

    Ensure you only plan to build the features you fundamentally require to serve your customers. Only these and not a single one more.


    This is a mantra of Silicon Valley. Plan to release versions of your software for real world testing as often as humanly possible.

    Listen to Reid Hoffman, the founder of LinkedIn:

    LinkedIn founder Reid Hoffman quote if you are not embarrassed by your first version you have shipped too late

    In other words, get your version 0.1 out the door as quickly as possible. Get feedback. Fix bugs, make upgrades and get the next version out the door as quickly as possible. Ship early, ship often.

Putting it all together: MODULAR architecture + PHASED roll-outs + REDUCED complexity + shipping OFTEN

If you're a marketing agency owner getting ready for a large eCommerce integration software project, stop and ask some important questions:

  • How long will it take to make an MVP (minimum viable product)?
  • Will it be modular?
  • Will it be upgradable, without falling apart?
  • Will passing all our data the first time send the system into a tailspin?
  • How can I break out the project into as many phases as possible?
  • What are the absolute core features vs. what can I forget about and ignore?
  • Who will be testing this and using it day-to-day? What do they need from the software to be "happy enough"?
  • What will our Version 2.0 look like?

In summary, any software integration project is a challenge even for experts, and if you're coming from an agency where the core comptency is about people and communication, not technology, then doubly so.

The better armed you are with lessons that software engineers have learned from countless projects, the better chance that yours will remain on budget and on schedule.

To reduce some of that risk, I offer expert guidance and implementation for eCommerce integrations.