5 questions for ecom tech diligence when you don't have a tech background
I spend my days inside e-commerce back ends (mostly auditing stores for buyers in diligence, and untangling the surprises after the close). Most of the pain I get called in to fix would have surfaced with a handful of questions asked before anyone signed anything.
I just got out of a zoom call about this, and I realized that, because it always comes back to the same core elements, anyone can run the framework. So I’m sharing it with you.
The most important thing before you start: you can ABSOLUTELY run technical diligence on an e-commerce store WITHOUT a technical background.
The best starting point is asking these questions & paying attention to how the seller answers.
------------
QUESTION 1: "Can you export all customer and order data, and can you show me?"
→ Good answer: "Of course! Let me share my screen and show you how to export the CSV"
→ Red flags: "I’m sure the tech guys can handle it" or “The platform can probably do that for you”
Gah! No! This should be EASY. If the data can’t leave the platform hassle-free and within 5 minutes, part of the asset you are buying can be trapped. I’ve had clients where the platform genuinely did not allow full exports, or chargedredactedfigures to “do it for them”.
------------
QUESTION 2: "Who built the store, and who maintains it today?"
→ Good answer: the name of a person or agency, with clear documentation, details of how the collaboration works, and a handover plan.
→ Red flag: "A freelance developer built it a few years ago, and we haven't needed anything since."
Let me translate this for you: NOBODY knows how to change anything safely.
This is especially dangerous if you are *not* in a big platform like Shopify; but even within Shopify, I had a case about 6 years ago where the theme was built (built! coded! not purchased!) by teenagers who then disappeared, and everything had to be rebuilt from scratch.
------------
QUESTION 3: "Which apps / integrations does the business depend on, and what do they cost monthly?"
→ Good: a list explaining *why* each tool is needed, with costs.
→ Red flag: the seller has to go look at what is even active or why it is needed.
Having a large tech stack is normal, but not knowing your own Dependency Map is not.
Many store owners keep inactive apps installed - they don’t even know what is active or dead, and this fools scraping tools, so the list you are seeing on Wappalyzer or Koala Inspector is not dependable. (These platforms show you what is installed, not what is ACTIVELY doing a job).
I had a case of a new owner who paid close to $4k/month for the first 5 months after acquisition, in expensive apps and a Shopify Plus account that were not actually needed. You need to get clear information from the owner about why each subscription exists, so you never need to make assumptions on your own.
------------
QUESTION 4: "Which accounts (analytics, ads, email marketing, domain) are owned by the business vs. you personally?"
→ Good: “Everything is in business-owned, transferable accounts.”
→ Red flag: "It's all under my Gmail, but I’ll give you access to everything with the acquisition."
It happens more often than you’d think, and it is the only cause I’ve had for REAL emergencies after the close. Ask this before buying.
------------
QUESTION 5: "Is there custom code, where does it live, and who can modify it?"
→ Good: documented, organized by versions, with a named developer.
→ Red flag: "There's some custom stuff, but no worries, it just works - and if you want to change anything, writing code with Claude is pretty easy these days."
No. Undocumented business logic is the single most expensive thing to inherit.
You’re looking at least at a 5 figure fix (depending on the complexity of the build).
AVOID.
This is especially important in Shopify, because themes need updates, and every time you update a theme, pieces of custom code get lost (Shopify warns you of this and asks if you’re sure you want to update).
If you don’t have proper documentation, you will not even know something broke until customer support starts ganging up on you… Or you have to accept being stuck with an outdated theme, unable to ever update it, and where other things start breaking anyway.
You can even be a developer or a pro at vibe coding - good for you, but useless in this scenario, because you can’t code anything if you don’t know WHERE and WHY things are breaking.
------------
That’s it. You don’t need to read code to be able to evaluate the tech side of your acquisition.
Did you already use these questions in your evaluations? Which did I miss?