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

NDAs make verification tough. Use an MVD to vet your eCommerce programmer, even without a public portfolio

An MVD is a Minimum Viable Demo: a tiny working live demo, specifically matched to your client's requirements.

Author: Dima Volo

It's the challenge every agency, consultant, and independent professional faces: to win new work, how much can you go into specifics about past projects when you've signed a tight non-disclosure agreement (NDA)?

Letting new clients review your portfolio is the typical approach to getting their business, but for safety's sake, you can't always tell them:

  • Exactly who you worked for previously
  • What you did for them
  • What it looked like in the end
  • ... or how it accelerated their business

You end up speaking in abstractions about the technology involved:

"I did a large scale project for a traditional company in the United States that processes millions of dollars in transactions, who needed a proprietary ERP integrated with WooCommerce".

That's not saying much.

Software integration projects in competitive industries are particularly difficult to share for this reason, especially when it comes to the cut-throat world of eCommerce, where companies guard their edge fiercly.

The fact is that new clients ask for a portfolio of past projects because it mitigates RISK: financial and personal.

An alternative way to mitigate risk is an "MVD": a working "minimum viable demo".

What is a minimum viable demo?

For new clients who are on the fence about whether a programmer can do what they promise, it's a working demonstration: something you can see and interact with as proof the programmer has understood your problem and encapsulated an appropriate solution.

An MVD is effectively the ideal portfolio piece, because it is a 1:1 match for the client's target technologies, problems, and solution options.

A "Minimum Viable Demo" comes after the initial discovery call, when your programmer has a handle on what needs to be built and why.

It demonstrates:

  1. The developer understands what the client is after
  2. The developer has thought through the pitfalls, challenges, and viable workarounds
  3. The minimum demo actually WORKS: it takes the right data from the right sources and integrates it with the target systems safely
  4. It's live and you can play with it on your own time, even when the programmer is not live with you on a screenshare
  5. It's small-scope, contained, and gets done fast. Usually in about 1 - 2 weeks, at most.

What a minimum viable demo IS NOT

It's not a finished "Version 0.9" or an "MVP" (minimum viable product).

Instead, expect that an MVD:

  1. Doesn't accomodate "corner cases" or unusual situations that invariably come up with day-to-day use. It only handles the most common scenario for a demo.
  2. Doesn't necessarily include automatic rollbacks to prevent data corruption, like a polished piece of software should
  3. Isn't necessarily "clean code" or modular. (Although looking at the way your programmer structures his "quick and dirty" code is also instructive about how he'll structure a production-ready project.)
  4. Costs some amount of money to build, but only a nominal amount, and should come with a money-back ejection guarantee for peace of mind.

How to evaluate a programmer based on an MVD

Keep the above points in mind about what to expect (and NOT to expect) from an MVD.

That way, when evaluating whether your programmer can get your larger project done well, you can ask yourself these questions:

  1. Has the programmer demonstrated while making the MVD that he understands what a "win" would look like for my client and me?
  2. Does the demo really work, live, in my own hands, or only when he shares his screen?
  3. Did the programmer over-promise and under-deliver, or under-promise and over-deliver?
  4. Did it take longer than expected?
  5. What was communication like with the programmer before and during the MVD, and while reviewing it?
    • Was he difficult to talk with, defensive, cagey, or quick to make assumptions?
    • Was it hard to schedule meetings and follow-ups?
    • Were his messages long and often off-topic?
    • Can I imagine working with him closely over days/weeks/months to get the main project to a production-ready state?

Concluding thoughts

An MVD is not an MVP: it's just a demo, meant to instill confidence that your programmer can get the job done, or conversely to invalidate that assumption and let you both move quickly to other opportunities.

If done well, an MVD can substitute for a similar-looking portfolio piece, because the MVD is even more closely matched to what you and your client need, and therefore it's a solid way to mitigate much of the risk that comes from working with unfamiliar developers.

Have you been looking for a technical partner who gets your client's projects into production in a reliable, verifiable way?

If you require expert assistance, click here for a 1-on-1 consultation.