What ancient collapses, fictional archipelagos, prisoner's dilemmas, and patient microbes can teach you about building something from nothing.
There is a moment in the life of every new product when the founder stares at a blank screen, an empty user list, and a bank account with a countdown timer, and thinks: How does anything ever get built?
The standard advice is familiar. Find product-market fit. Talk to users. Ship fast. Iterate. That advice isn't wrong. But it's incomplete in the way that a recipe is incomplete — it tells you the steps without telling you why those steps work, which means the moment you encounter a situation the recipe doesn't cover, you're lost.
This essay takes a different approach. It raids six domains that have nothing obvious to do with product development — the Bronze Age Collapse, game theory, cultural anthropology, fermentation science, a fictional island civilization called the Kethári, and fundamental economics — and asks what each of them knows about building something durable from raw materials. The connections are not metaphors stretched for cleverness. They are structural parallels: the same dynamics that govern the rise and fall of civilizations, the evolution of microbial ecosystems, and the mathematics of strategic interaction also govern the emergence (or death) of a new product in a competitive market.
The thesis is simple: the best product builders are, whether they know it or not, applied anthropologists, amateur game theorists, and patient fermenters. The worst ones are engineers who think the only system that matters is the one they're coding.
Around 1200 BCE, the entire eastern Mediterranean civilizational order — the Hittites, Mycenaean Greece, the Kassite dynasty of Babylon, and the Egyptian New Kingdom — collapsed within roughly fifty years. An international system of trade, diplomacy, and cultural exchange that had functioned for centuries disintegrated so completely that the subsequent period is literally called the Dark Ages.
What happened? A "perfect storm" of drought, earthquakes, social upheaval, and the mysterious Sea Peoples disrupting maritime trade. But the deeper cause wasn't any single shock. It was the architecture of the system itself. The Late Bronze Age economies were palace economies — centralized systems where the state controlled production and distribution. They were tightly coupled through trade networks for tin and copper, the two metals needed to make bronze. Every civilization depended on every other civilization for critical inputs. When the trade routes broke, the dominoes fell in sequence. The interconnections that made the system wealthy made it fragile.
If you are building a product in 2026, you are probably building it on top of a platform. Your app lives in Apple's App Store or Google Play. Your infrastructure runs on AWS or GCP. Your distribution depends on Google Search, Instagram's algorithm, or TikTok's For You page. Your payments flow through Stripe. Your auth is Firebase.
Each of these platforms is a trade route for tin.
The Bronze Age Collapse teaches a specific, non-obvious lesson about platform risk: the danger is not that any single platform will fail — it's that your dependencies are correlated. The Mycenaean Greeks didn't just lose tin. They lost tin, and the trade partners who supplied copper, and the diplomatic relationships that kept piracy in check, and the grain imports that fed the craftsmen who made the weapons that defended the trade routes. Everything was connected to everything, and when the first thread snapped, the fabric tore along every seam.
A product that depends on AWS for infrastructure, Google for discovery, Stripe for payments, and a single API for its core data feed has the same structural vulnerability. None of these will "fail" in the dramatic sense. But a policy change at Apple, a Stripe fee increase, and a Google algorithm update can arrive in the same quarter. Each is survivable alone. Together, they are a Bronze Age Collapse for your Series A.
The civilizations that survived the Bronze Age Collapse were the ones that had decentralized structures. Egypt contracted but endured — its Nile-based agriculture made it less dependent on trade. The Phoenician city-states, which were distributed and trade-adaptable rather than centralized and trade-dependent, emerged from the collapse stronger than before. The survivors were the ones whose systems could degrade gracefully rather than shatter.
For a product, graceful degradation means: don't build a business where the loss of any single external dependency is fatal. Own your customer relationships. Diversify your distribution channels. Maintain the ability to process payments through more than one provider. Build your core logic in a way that isn't locked to a single cloud vendor. This isn't paranoia. It's the institutional flexibility that let Egypt survive three thousand years while the Hittites vanished in a generation.
In 1980, the political scientist Robert Axelrod invited game theorists to submit strategies for a computer tournament of the iterated Prisoner's Dilemma — the canonical model of the tension between individual self-interest and collective welfare. Fourteen entries competed. The winner was also the simplest: Tit-for-Tat, submitted by Anatol Rapoport. Cooperate on the first move. Then mirror whatever your opponent did last.
Axelrod ran a second tournament in 1981 with sixty-three entries, many specifically designed to exploit Tit-for-Tat. It won again.
The four properties that made it dominant are, I will argue, the exact properties that make a new product earn trust with its first customers:
Nice. Tit-for-Tat never defects first. It extends cooperation before receiving any evidence that cooperation will be reciprocated. This is the product equivalent of a generous free tier, a no-questions-asked refund policy, or a founder who answers support emails at 2 AM. You cooperate first. You give value before you extract it. The customers don't know you yet. They have no reason to trust you. Being "nice" — leading with value — is the rational strategy for a new entrant precisely because you're playing an iterated game and every interaction is a chance to demonstrate that cooperating with you pays off.
Retaliatory. Tit-for-Tat punishes defection immediately. In the product context, this means having clear boundaries. If a customer abuses your terms, you enforce them. If a platform partner changes the deal, you renegotiate or walk. Founders who are nice without being retaliatory get exploited — their generosity signals weakness rather than goodwill. The magic of Tit-for-Tat is that niceness and retaliation coexist. You cooperate by default, but you are not a pushover.
Forgiving. After retaliating, Tit-for-Tat returns to cooperation as soon as the opponent cooperates. It doesn't hold grudges. A customer has a bad experience, complains publicly, and you fix it? Don't blacklist them. Welcome them back. The ability to reset the relationship after a conflict is what makes long-term cooperation sustainable. Companies that hold grudges against churned customers or hostile reviewers are playing a one-shot game in a repeated-game world.
Clear. The strategy is transparent. Opponents can quickly learn what Tit-for-Tat will do and adjust accordingly. For a product, clarity means predictable behavior — consistent pricing, clear documentation, honest communication about what works and what doesn't. Customers can only cooperate with you if they can model your behavior. Opacity breeds distrust. Complexity breeds confusion. The simplest possible relationship is the easiest to sustain.
Here is the deeper insight from game theory that most product advice misses: cooperation doesn't require altruism. It requires repetition. In a one-shot Prisoner's Dilemma, defection is the only rational strategy. But when you expect to interact with the same person repeatedly — when there is a "shadow of the future" — cooperation becomes self-interested. The short-term gain from cheating a customer (shipping a half-baked feature, hiding a price increase, selling their data) is outweighed by the long-term cost of lost trust.
The math is precise. Cooperation via Tit-for-Tat is sustainable when the discount factor (the probability of continued interaction) satisfies: δ ≥ (T − R) / (T − P), where T is the temptation to defect, R is the reward for mutual cooperation, and P is the punishment for mutual defection. In plain English: cooperation works when the players expect to keep playing for a long time and the cost of getting caught cheating is high relative to the benefit.
For an early-stage product, this means your first customers are your most important game-theory partners. They are the ones with whom the shadow of the future is longest. They are the ones whose cooperation — in the form of feedback, referrals, testimonials, patience with bugs — determines whether you survive long enough to reach more customers. Treat them like repeated-game partners, not one-shot transactions. The math says this is not idealism. It is the dominant strategy.
The Kethári — a fictional civilization designed by synthesizing principles from anthropology, game theory, economics, and systems thinking — inhabit a volcanic archipelago where no island is self-sufficient and all must trade. Their origin story is the key to everything they built.
Their ancestors were refugees from a mainland empire called the Deshána, a centralized palace economy where the king controlled all production and distribution. When drought coincided with rebellion and the severing of trade routes, the system shattered within a generation. There was no graceful degradation. The Deshána's efficiency was its fragility.
The survivors fled to an uninhabited archipelago. They fought for two centuries. Nearly destroyed themselves. And then they developed a governing insight that became the foundation of their entire civilization: centralization is a trap.
This insight — born from traumatic experience, not abstract theory — shaped every institution the Kethári built. Their distributed Triad governance with staggered terms. Their three-flow economy that prevents any single mode of exchange from dominating. Their double-descent kinship system that creates crosscutting loyalties, making large-scale factional conflict structurally difficult. Everything traces back to the founding lesson: what made the Deshána powerful was what made the Deshána dead.
The product parallel is direct: your positioning against established competitors is the story of what you rejected about their structure.
You don't beat an incumbent by doing what they do, better. You beat them by doing what their architecture prevents them from doing. The Kethári didn't try to build a better centralized empire. They built a system that was strong because it was decentralized — something the Deshána's structure could never have produced.
Slack didn't beat email by being better email. It beat email by being what email's architecture couldn't become — real-time, channel-based, integrated. Figma didn't beat Adobe by being a better desktop app. It beat Adobe by being browser-native — something Adobe's desktop-first architecture couldn't easily replicate. Every successful challenger is, in some sense, a refugee from the incumbent's limitations.
The Kethári story teaches something subtler, too: your founding trauma is your competitive advantage, if you understand it correctly. The Deshána's collapse gave the Kethári an allergy to centralization that other civilizations didn't share. That allergy drove design decisions that mainland societies couldn't have conceived, because they hadn't experienced the specific failure that made decentralization feel necessary.
For a founder, this means: the problem that infuriated you enough to build a company is not just your motivation. It is your product's structural advantage. The anger is information. It tells you which specific failure mode you are designed to prevent — and that failure mode is the one the incumbents are structurally incapable of addressing, because their architecture is the thing that causes it.
Here is the most counterintuitive fact in fermentation science: yeast deliberately chooses the less efficient metabolic pathway.
Saccharomyces cerevisiae — the organism that makes bread rise, beer bubble, and wine alcoholic — is a facultative anaerobe. It can perform aerobic respiration, extracting up to 38 ATP per glucose molecule. But when glucose is abundant, it preferentially ferments, extracting only 2 ATP per glucose. It throws away 95% of the available energy.
Why? Speed and territorial control. Fermentation is faster than respiration. And the ethanol it produces as a byproduct poisons competing microorganisms. S. cerevisiae sacrifices efficiency for speed, and uses the waste product of its "wasteful" process as a weapon against competitors. When the sugar is gone and the competitors are dead, it switches to aerobic respiration of the accumulated ethanol — the diauxic shift.
This is the biological equivalent of Paul Graham's famous advice to "do things that don't scale." The Crabtree effect — yeast's preference for fast-but-wasteful fermentation over slow-but-efficient respiration — is the metabolic version of spending three hours personally onboarding a single user, or hand-delivering your product, or writing custom code for one customer's edge case. It is inefficient at the unit level. It is dominant at the strategic level.
But fermentation teaches a second, harder lesson: some processes have irreducible timescales, and trying to compress them destroys the product.
The critical bottleneck in fermentation is NAD+ regeneration. Glycolysis — the ten-step enzymatic breakdown of glucose — requires NAD+ as an electron acceptor in step six. Without it, glycolysis stops. Fermentation exists as a pathway precisely to solve this problem: it regenerates NAD+ by using pyruvate as the terminal electron acceptor, keeping the cycle going.
You cannot speed up NAD+ regeneration by adding more yeast. You cannot speed it up by raising the temperature (beyond a narrow optimal range, heat kills the yeast). The enzymatic chemistry proceeds at its own pace, and the system is bottlenecked by a molecular constraint that no amount of external pressure can overcome.
Consider soy sauce. The industrial process takes six to eight months. Aspergillus oryzae spends three days breaking down soybeans and wheat into sugars and amino acids — the koji stage. Then lactic acid bacteria and salt-tolerant yeasts ferment the mixture for half a year or more, producing the deep umami, dark color, and complex aroma. Accelerated soy sauces exist — hydrolyzed in days using acid rather than enzymes — but anyone who has tasted both knows the difference. The time is not a delay. The time is where the complexity lives.
Consider chocolate. Raw cacao beans are inedible — bitter, astringent, with none of the flavor we associate with chocolate. They must ferment for five to seven days: first yeasts, then lactic acid bacteria, then Acetobacter, each microbial succession transforming the substrate and setting up the conditions for the next organism's work. The fermentation generates the flavor precursors — free amino acids and reducing sugars — that only become actual chocolate flavor during subsequent roasting via the Maillard reaction.
The precursors. Not the flavor itself. The precursors.
Product-market fit is a precursor. Community is a precursor. The first hundred users who actually care are a precursor. The real product — the one that scales, that has network effects, that generates word-of-mouth — only emerges when the precursors undergo their own Maillard reaction: the moment when early adoption combusts into organic growth. And you cannot skip the precursor stage any more than you can skip cacao fermentation and expect chocolate.
The founders who understand this are the ones who can endure the long months of apparently nothing happening — the metabolic equivalent of NAD+ cycling in the dark, invisible enzymatic work that looks like stagnation but is actually the foundation for everything that follows. The founders who don't understand it are the ones who try to acid-hydrolyze their way to product-market fit: buying users, faking traction, launching to press before the product is ready. They get something that looks like soy sauce. But nobody comes back for a second taste.
In the Trobriand Islands of Papua New Guinea, shell necklaces circulate clockwise and shell armbands circulate counterclockwise through a vast inter-island exchange network called the Kula Ring. The items have no practical use. They are not "money." They are tokens of social relationship — and the relationships they create enable all the practical trade (food, tools, canoes) that sustains life across the archipelago.
Marcel Mauss, analyzing this and similar systems in The Gift (1925), identified three obligations that structure gift economies: the obligation to give, the obligation to receive, and the obligation to reciprocate. Refusal at any stage is a hostile act. The gift is not charity. It is a social technology for creating durable, enforceable bonds between people who have no institutional authority to compel each other's cooperation.
The Kethári built this insight into the architecture of their economy. Their "Gift Stream" — one of three parallel economic channels — governs knowledge, mentorship, healing, and community service. These things are never priced. Attempting to buy a mentor's teaching with market currency is a serious taboo. The relationship IS the return.
The parallel to product building is precise: the most valuable things your first users can give you — feedback, referrals, patience, ideas — cannot be purchased. They can only be earned through the gift economy.
When a beta user spends thirty minutes writing a detailed bug report with reproduction steps, they are not being paid. They are giving a gift. When they recommend your product to a colleague, they are spending social capital — putting their reputation on the line for something they believe in. When they tolerate a crash, shrug, and file a report instead of churning, they are extending generalized reciprocity — giving without expectation of immediate return because they trust the relationship.
If you treat these interactions as market transactions — if you think of user feedback as something you can "incentivize" with gift cards or loyalty points — you are committing the Kethári's cardinal economic sin: collapsing the gift stream into the market. You are converting a social bond into a transaction, and the moment you do, you lose the thing that made it valuable: the ongoing obligation, the relationship, the trust.
The founders who build cult followings are the ones who operate in the gift economy instinctively. They give away knowledge. They respond personally. They build in public. They share their failures. Each act of generosity creates an obligation — not a contractual one, but a social one. And that web of obligation is exactly the structure that will carry the product through its most vulnerable early months.
Here is the most underrated insight in economics: mechanism design is reverse game theory. Standard game theory takes the rules of a game as given and asks what rational players will do. Mechanism design starts from the desired outcome and asks: what rules will make rational players produce that outcome?
The Kethári understood this intuitively. Their method for selecting the Architect of Production — the economic leader of their civilization — is a Vickrey-like mechanism. Candidates present governance plans. The winning plan is adopted, but the second-place plan's constraints are also binding. This incentivizes honest proposals: if you promise something unrealistically ambitious to win the position, you'll be saddled with the runner-up's more conservative guardrails. Truth-telling becomes the dominant strategy.
Every product is, whether its designers know it or not, a mechanism. It defines players (users, creators, moderators, advertisers), strategies (the actions available to them), and payoffs (what they get from each combination of actions). The question the product designer should ask is not "what features should we build?" but "what game are we designing, and does the Nash equilibrium of that game produce the outcome we want?"
Consider Twitter. The mechanism: anyone can post, anyone can reply, engagement is measured by likes and retweets, the algorithm amplifies high-engagement content. The Nash equilibrium: users maximize engagement, which means maximizing emotional reaction, which means outrage, hot takes, and conflict. The platform's problems are not bugs — they are the Nash equilibrium of the mechanism the designers built.
Consider Craigslist. The mechanism: free listings, no algorithmic ranking, minimal interface. The Nash equilibrium: users post honestly because there is no system to game. The simplicity is the mechanism. It produces a different game with a different equilibrium.
The Kethári's Dispersal Rule — any enterprise controlling more than 15% of a critical resource must either split or convert to commons governance — is mechanism design applied to market structure. They recognized that unrestrained competition produces winner-take-all dynamics (reinforcing feedback loops), so they designed a rule that caps concentration before it becomes destabilizing. The rule is the mechanism. The diverse, resilient economy is the desired outcome.
For product builders, the lesson is: don't just design features. Design incentives. What does your pricing structure encourage users to do? What does your referral program optimize for? What behavior does your notification system reward? If the answers to these questions don't produce the user behavior you want, changing the features won't fix it. You need to change the game.
The Kethári's Cord Script — their writing system made of knotted, dyed cords — includes an extraordinary feature: the dissent strand. Major records are accompanied by a parallel cord, in a different color, that records alternative interpretations, minority positions, and known uncertainties.
This is not error correction. It is something rarer: epistemic humility encoded in the medium itself. The Kethári view of knowledge holds that recording only the majority view is a form of information loss. The dissent may prove correct later. The reasons for disagreement carry information about the limits of current understanding.
Most product roadmaps are consensus documents. The features that ship are the ones the team agreed on. The ideas that lost the argument are forgotten. The concerns that were overruled are not recorded.
The Kethári would call this reckless.
The features you chose not to build — and the reasons why — are as informative as the features you shipped. The dissenting voice in the room who said "our users don't actually want this" is data, even if they lost the vote. The minority of users who use your product in an unexpected way are a signal, even if they don't show up in the aggregate metrics.
A product roadmap with a dissent strand would look like this: next to each prioritized feature, a brief record of what was considered and rejected, and why. Next to each shipped feature, the strongest argument against shipping it. Next to each metric, the things the metric doesn't capture.
This sounds like overhead. It is the opposite. It is the fastest way to avoid repeating mistakes. It is the reason the Kethári's Resonance Libraries survived eight centuries while the Deshána's palace records perished with the palace: the system that encodes disagreement adapts faster than the system that enforces consensus.
The Stag Hunt is a coordination game. Two hunters can pursue a stag (which requires cooperation and yields a large reward) or a hare (which can be caught alone but yields a small reward). The stag hunt has two equilibria: both hunt stag (the best outcome, but risky) or both hunt hare (safe but mediocre).
The tension is between trust and safety. You get the best outcome only if you trust the other player to cooperate — and they trust you.
Your first ten customers are playing a Stag Hunt with you.
Using a new, unproven product from an unknown company is risky. The safe choice — the hare — is sticking with the incumbent, even if it's mediocre. The better choice — the stag — is adopting your product, but only if enough other people adopt it too (for products with network effects) or only if the product delivers what it promises (for products without network effects).
Your job as a founder is to make the stag hunt solvable. You do this by:
Every seven years, the Kethári conduct the Pruning — a systematic audit of every institution, regulation, and bureaucratic function, with one question for each: does this institution's benefit still exceed its maintenance cost? Those that fail the test are dissolved.
Joseph Tainter's theory of civilizational collapse holds that societies invest in complexity to solve problems, but each layer of complexity adds maintenance costs. When marginal returns on complexity become negative, the society becomes vulnerable to collapse. The Kethári designed the Pruning as a structural defense against this dynamic: instead of letting complexity accumulate until the system collapses under its own weight, they build periodic simplification into the governance cycle.
Every product accumulates complexity. Features that made sense in v1 become maintenance burdens in v3. Integrations that served an early use case linger in the codebase long after the use case disappeared. Settings panels grow. Configuration options multiply. Each addition was rational in isolation. In aggregate, they are the product equivalent of institutional bloat.
The product teams that endure are the ones that prune. They kill features. They sunset integrations. They simplify interfaces. They treat complexity as a cost, not a benefit — and they build periodic simplification into their development cycle, not as a crisis response but as a routine.
The Kethári celebrate the Pruning. They do not mourn dissolved institutions. The cultural norm is strong enough that obstructing the Pruning is considered corruption.
Imagine a product team that celebrated killing features the way they celebrate shipping them. Imagine a culture where removing a settings option got the same internal recognition as adding one. That team would build products that last.
The Kethári's archipelago is sinking. Slowly — a few centimeters per year — but inexorably. Three islands are already uninhabitable. A fourth will be lost within a generation. And the institutions that made the Kethári great are proving to be precisely the things that make their crisis response inadequate.
Their distributed governance prevents rapid, unified action. Their demurrage currency — designed to prevent hoarding — prevents the long-term capital accumulation needed for massive infrastructure. Their kinship system, tied to specific land, fragments when the land disappears. Their knowledge system, designed to preserve disagreement, struggles to establish the authoritative consensus needed for coordinated response.
Every institutional virtue has become, in the specific context of existential crisis, a corresponding liability.
This is the deepest lesson for product builders. The thing that makes your product successful at one stage will, if you're not careful, become the thing that prevents you from succeeding at the next stage.
The speed that let you ship fast in the early days becomes technical debt that slows you down at scale. The founder's personal touch that delighted early users becomes a bottleneck when you have ten thousand customers. The flat organizational structure that enabled rapid iteration becomes a coordination nightmare when you have fifty engineers. The free tier that built your user base becomes a revenue problem when investors want to see margins.
The Kethári's three factions — Anchors (adapt in place), Voyagers (colonize new territory), Weavers (reinvent the institutions themselves) — map cleanly onto the strategic choices every scaling product faces. Do you optimize the current architecture? Do you expand to a new market? Or do you fundamentally redesign the underlying system?
The Weaver position — preserve the principles, transform the implementations — is the hardest and the most correct. It requires distinguishing between the essential and the incidental: what about your product is the principle (the value you deliver, the problem you solve, the trust you've earned) and what is the implementation (the specific code, the specific pricing, the specific UX)?
Six domains. One pattern.
The Bronze Age Collapse teaches that tightly coupled systems are fragile. Game theory teaches that trust emerges from repeated interaction, not good intentions. The Kethári teach that your origin story is your strategy, and that the institutions you build to solve one problem may become the next problem. Fermentation teaches that some processes have irreducible timescales, and that choosing the "wasteful" path is sometimes the dominant strategy. Cultural anthropology teaches that social capital precedes financial capital. Economics teaches that every product is a mechanism, and the game it creates matters more than the features it ships.
The thread connecting all of them is this: building a product is not an engineering problem. It is a civilization-building problem. You are not just writing code. You are designing institutions — incentive structures, social norms, exchange systems, knowledge preservation mechanisms, governance processes — that will either sustain a community or fail it.
The founders who understand this build things that last. The ones who don't build things that ship.
There is a Kethári saying: "The root holds the tree, but the tide carries the seed." The root is your technology, your code, your infrastructure. The tide is the human system — the trust, the relationships, the social fabric — that carries your product to places your engineering alone could never reach.
Tend the Weave.