Module overview: moats — the ditch that's still there when someone tries to cross it

Why this module exists here

Module 5 closed with an uncomfortable result, on purpose. You ran competitiveMap on Mercado's complete roster twice: today, and projected three years out. Today, Mercado's quadrant is open —openSpace: true—, no competitor occupies it. Three years out, with the same technology trend already visible today —AI shopping assistants raising JustSearchOnGoogle's curation, the biggest substitute on the whole roster—, that same quadrant stops being open: openSpace: false. Nobody new entered the map. The terrain moved under the player who was already there.

That result leaves open a question module 5, deliberately, didn't answer: if the space closes, is there anything stopping it from closing? A competitive map tells you where you're standing and for how long today's landscape stays valid. It doesn't tell you whether, when someone seriously decides to occupy your quadrant —not by accident, with budget, with a team dedicated to copying you—, there's something structural stopping them, or whether your advantage today falls apart in the first sprint a competitor dedicates to it. That's this module's full question: not whether the space is open, but whether it's defensible.

Connection to module 5. There you built the complete roster —direct competitors, indirect ones, the biggest substitute of all— and the clock that already started running against Mercado's open space. This module takes that exact same roster as the threat and asks, player by player, advantage by advantage: if MegaStoreGenerico decided to copy Mercado's curation next quarter, with its entire budget, what stops it? The correct answer is almost never "nothing" or "everything" — it depends, with surgical precision, on what type of advantage is at stake. That's the model this module delivers: moatScore, run on each candidate advantage of Mercado's, including the two the strategy itself already named back in module 1 — the seller network and the purchase data.

An everyday analogy: the castle's moat, not the decoration on the door

Two castles, side by side, look almost identical from the road: gray stone, tall towers, a crest carved above the entrance gate. The first also has a complete moat around it —deep water, a single bridge that raises from inside— before any army even reaches the door. The second has no moat: instead, it invested that budget in a carved wooden gate, with golden hinges and a hand-painted crest, much prettier than the first's at a glance. The day an army seriously decides to take each castle, the difference stops being aesthetic and becomes the only one that matters: the first one, the army has to cross the moat before touching anything — an obstacle that exists no matter how many soldiers they send. The second one, all it takes is pushing the door harder — the golden crest doesn't withstand a battering ram one minute longer than an unpainted door would.

That's exactly the distinction that names this module. A moat —the word Warren Buffett popularized, borrowing it, literally, from medieval military architecture— is the ditch: a structural obstacle that's still there even when someone seriously decides, with real resources, to try to cross it. A feature, no matter how polished, no matter how praised in the last demo, is the decoration on the door: it makes the castle look better today, and it doesn't withstand a single dedicated attack. The rest of this module is, at bottom, learning to look at any advantage of Mercado's —or of any product you build in your career— and answer, without being fooled by how pretty the door looks, a single question: is this a moat, or is it decoration?

Worked example: two of Mercado's advantages, the same question

Before diving into lesson-by-lesson detail, we run the module's central model —moatScore— on two real Mercado advantages, chosen deliberately for how different they are. The first is sellerNetwork: the local seller network Mercado built, where every new buyer makes the platform a little more attractive to a new seller, and every new seller makes the platform a little more attractive to a new buyer. The second is fasterCheckout: the same backlog item you already know from module 1 of this guide and from product-thinking-for-engineers-guide — a one-click checkout, the kind of improvement any competent engineering team could replicate in a sprint.

moatScore takes one advantage at a time —not a list, not a comparison against competitors like the models from modules 4 and 5— and assigns it a durability from 0 to 10 based on its type: it doesn't evaluate whether the advantage is good today, it evaluates whether it survives someone attacking it seriously.

// Pedagogical model: scores the DURABILITY (0-10) of a competitive advantage,
// not how good it is TODAY but how hard it is for a well-funded competitor
// to erode it in 1-2 years. The 'feature' type has a structural ceiling of 3
// by design -- how long something takes to build is not the same as how
// long it takes to defend.
function moatScore(advantage) {
  const { name, type } = advantage;
  let durability;
  let rationale;

  switch (type) {
    case 'networkEffect': {
      const { sides, localDecay } = advantage;
      durability = sides >= 2 ? 8 : 5;
      if (localDecay) durability -= 3;
      rationale = `network effect ${sides}-sided${localDecay ? ', with local decay' : ', no decay'}`;
      break;
    }
    case 'feature': {
      const { timeToCopyWeekends } = advantage;
      durability = Math.max(0, Math.min(3, timeToCopyWeekends));
      rationale = `feature copyable in ~${timeToCopyWeekends} weekend(s)`;
      break;
    }
    // The other types -- switchingCost, scaleEconomies, dataMoat, brand --
    // get added lesson by lesson; the complete model lives in L2.
    default: {
      durability = 0;
      rationale = 'unknown advantage type';
    }
  }

  durability = Math.max(0, Math.min(10, durability));
  const verdict = durability >= 7 ? 'moat' : durability >= 4 ? 'weak-moat' : 'not-a-moat';
  return { name, type, durability, verdict, rationale };
}

const sellerNetwork = { name: 'sellerNetwork', type: 'networkEffect', sides: 2, localDecay: false };
const fasterCheckout = { name: 'fasterCheckout', type: 'feature', timeToCopyWeekends: 1 };

console.log('=== Moat or feature? Two of Mercado\'s advantages, scored ===\n');
console.log(moatScore(sellerNetwork));
console.log(moatScore(fasterCheckout));

What to expect. Running the file with Node produces exactly this output:

=== Moat or feature? Two of Mercado's advantages, scored ===

{
  name: 'sellerNetwork',
  type: 'networkEffect',
  durability: 8,
  verdict: 'moat',
  rationale: 'network effect 2-sided, no decay'
}
{
  name: 'fasterCheckout',
  type: 'feature',
  durability: 1,
  verdict: 'not-a-moat',
  rationale: 'feature copyable in ~1 weekend(s)'
}

sellerNetwork gets durability: 8 and the 'moat' verdict: it's a two-sided network effect —buyers and sellers attract each other— with no sign of weakening if a user takes a break. fasterCheckout gets durability: 1 and 'not-a-moat': by the model's design, the 'feature' type has a ceiling of 3 no matter how polished it is, and this particular candidate doesn't even reach that ceiling — a well-funded competitor replicates it in a single weekend of work. Notice something important you're going to see over and over in this module: the model doesn't ask anyone on the Mercado team whether these are good features or good initiatives — they are, both, they both improve the product today. The question moatScore answers is different, and more uncomfortable: if MegaStoreGenerico decided to copy each one tomorrow, which one survives?

The module's map

Save this route. The whole module moves from precisely defining what a moat is to going through, type by type, which ones exist and which don't apply to Mercado, ending with the role you, as an engineer, get to play in building them:

Idea                                          Lesson    Key concept
─────────────────────────────────────────────  ────────  ─────────────────────────────────────
What a moat is, precisely                       L2        durability, not quality; the test
                                                           "does it survive a serious attack?"

Network effects                                 L3        the phone that's worth more the more
                                                           people have one; the decay problem

Switching costs                                 L4        what it costs to switch banks;
                                                           contractual vs. habit vs. data+workflow

Data and scale moats                            L5        data is ONLY a moat if it feeds back
                                                           into the product; real economies

A feature is not a moat                         L6        the weekend test; why "we have
                                                           feature X" defends nothing

The engineer's role in building moats           L7        the same feature, two architecture
                                                           decisions, two different scores
─────────────────────────────────────────────  ────────  ─────────────────────────────────────
Project: Mercado's moat audit                   L8        moatScore over every candidate,
                                                           what to defend and what not to
                                                           mistake for a moat

The boundary: what's NOT in this module

This module answers a specific question: what makes a Mercado advantage hard to erode, even if someone seriously tries? It does not answer several neighboring questions, which belong to other modules of this guide or to other guides in the ecosystem:

• "Who does Mercado compete against, and how open is its ground today?" — you already saw that in module 5. Here the landscape isn't mapped again; that same roster is used as the threat each moat is tested against.
• "What makes us different and better for the segment?" — that's module 4's differentiation. Differentiation and moat aren't the same thing, and that exact distinction is the whole topic of lesson 6: a real differentiation today may not be a moat, if anyone can copy it next quarter.
• "How does all of this translate into what to build first?" — the strategic filter over the backlog, module 7. This module identifies which advantages to defend; module 7 decides, with that inventory already done, which roadmap bets serve to deepen them.
• Modeling a moat's dollar size, or the exact cost of building it — that's detailed financial business strategy, outside this guide's scope. Here the focus is recognizing the type of advantage and reasoning about its durability with a running model, not putting a valuation on it in an investor's spreadsheet.
• Detailed technical architecture or implementation — the Fullstack and Architecture ecosystems. Lesson 7 does get into the engineer's role in designing a moat (a data pipeline decision, the depth of an integration), but it doesn't teach you to build the full system.

Resources

• Hamilton Helmer, 7 Powers: The Foundations of Business Strategy — 7powers.com. The book that gives this entire module its technical vocabulary: seven types of "power" —including network economies, switching costs, and economies of scale— that you're going to recognize, under other names, in every type moatScore models. In English.
• Ben Thompson, "The Moat Map" (Stratechery, 2018) — stratechery.com/2018/the-moat-map. The article that revisits, for the internet era, the same question that closed module 5: what combination of supplier differentiation and network effects produces a moat that actually holds up. In English.
• Jeff Jordan (a16z), "So You Want to Compete Against Amazon?" — a16z.com/so-you-want-to-compete-against-amazon. The same article that closed module 5, now read from the other side: not just how to position against a giant, but what makes that position still stand a year later. In English.