Building Software at Scale in the AI & Cloud Era

← the whole book on one page

Chapter 8: Ecosystems — Business Platforms, Partners, and InnerSource

“The various members also compete vigorously against one another to issue cards and sign merchants.” — U.S. Court of Appeals for the Eleventh Circuit, NaBanco v. Visa (1986)

Until Verified Resale, almost everything Encore built was something Encore itself sold, to fans, organizers and venues, and in each case one party made a promise and the other relied on it. Verified Resale changes the shape of that promise. A fan sells to another fan, through a partner that in other markets is Encore’s competitor, under rules an organizer has set, and Encore’s job is to make the exchange safe for people who have no reason to trust one another. The engineering question changes with it. When a product becomes a place where others do business, what must the system itself enforce, and who pays for the parts that everyone shares?

The question is older than software, and its best answer came from banking. Half a century ago a group of rival banks agreed to run one card network under one set of rules, with a fee they had set together, while they went on competing for every cardholder and every merchant. Dee Hock’s National BankAmericard Inc. is this chapter’s touchstone, and Section 8.1 tells its story, because the shape it found, rivals selling through one system under shared rules with the money divided by a default nobody has to negotiate, is the shape of Verified Resale.

We meet Encore at the point where that shape has been tested. The Products book’s Chapter 2 chose the market and its sides, and its Chapter 10 followed the bet from memo to launch. At month 12 Verified Resale went live with three design-partner organizers, one partner, Rowmate, and one market, France. Tessera was certified around month 15 and went live soon after, and at the month-18 review there are two partners and no kill criterion has fired. This chapter covers the marketplace rules as the system enforces them (Sections 8.1 and 8.2), the partner program (Section 8.3), and two kinds of sharing inside Encore: code that six teams change together (Section 8.4) and the costs of both of Encore’s platforms (Section 8.5).

8.1 From Product to Platform

The banks that agreed to compete

Bank of America launched BankAmericard in California in 1958, and in 1966 it began licensing the card to banks across the United States. The licensing created what the Eleventh Circuit would later describe as a four-party system: the cardholder, the bank that issued the card, the merchant, and the merchant’s bank. Each purchase crossed from one bank to another, and each pair of banks settled the other’s paper on terms negotiated between the two of them. The court’s phrase for it is that the “variable interchange fee system” stopped working well, and the licensees, struggling with fraud, failed credit controls and slow clearing, blamed one another for all three.

Dee Hock was running the card operation of the National Bank of Commerce in Seattle, one of the early licensees, when the arrangement reached its crisis. At a contentious licensee meeting in Columbus, Ohio, in 1968, he argued for restructuring and was put at the head of a committee to address the problems. In 1969 he gathered a hand-picked group of bankers at a hotel in Sausalito, California, to design a new organization, and in 1970 Bank of America gave up control of the program. The issuing banks formed National BankAmericard Inc. (NBI), which the court later described as “a for-profit nonstock-membership corporation”, with Hock as its first president and chief executive. The banks owned the network and made its rules together, and they went on competing for customers as fiercely as before.

Late in 1971 NBI’s board did something that looks small and was not. It adopted a uniform fee, set by the network and paid by the merchant’s bank to the card’s issuer on every transaction that cleared through NBI’s system, to carry part of the issuer’s costs: credit losses, the interest-free period, and the fact that cardholders paid no fee. The fee was a default. Members could bypass the network’s clearing and negotiate other rates privately, but the default spared them from having to negotiate at all. In 1973 Hock pushed through VisaNet, the electronic system for authorization and clearing, and in 1976 the organization took the name Visa. Hock resigned in 1984, later told the story in Birth of the Chaordic Age (1999), reissued with new chapters as One from Many (2005), and died in 2022. Figure 8.1 draws the system the banks built and the road from licensees to Visa.

Figure 8.1 — The four-party system under NBI. The charge cleared through the network, and the fee ran the other way, from the merchant’s bank to the issuer, at a rate the network set and any two banks could still replace by private agreement.

Three things in the story carry straight across to Verified Resale. The first is that rivals can sell through one system when the rules are shared and the network, not each member, enforces them. The court named the prize “universality of acceptance — the key element to a national payment system”, and Verified Resale’s prize is the same in miniature: a reissued ticket must work at every gate, whichever partner sold it. The second is that a network-set default for dividing money removes a whole class of negotiation, which is what Encore’s fixed split of the buyer’s fee does. The third is less comfortable. Shared rules about price attract regulators. NaBanco, a merchant processor, sued in 1979, claiming the fee was horizontal price-fixing; the district court found for Visa in 1984, and in January 1986 the Eleventh Circuit affirmed, calling the fee “an internal control mechanism” of a joint venture. Decades later the European Union (EU) capped consumer interchange at 0.2% for debit cards and 0.3% for credit cards. A rule that sets a price must be defensible in public, because sooner or later someone will ask it to defend itself.

The parallel has a limit, and the limit teaches as much as the parallel. The banks owned NBI. Rowmate and Tessera own nothing of Encore, and Encore is both the network and one of the channels, since fans can also buy resale tickets in Encore’s own app. A network owned by its members can claim neutrality by construction. A network owned by one participant has to earn it with rules it publishes and data it refuses to share, which is much of what Section 8.3 is about.

Three kinds of platform

The word “platform” covers several different businesses, and confusing them leads to building the wrong governance. Cusumano, Gawer and Yoffie, in The Business of Platforms (2019), separate two kinds. A transaction platform is an intermediary that matches parties who want to exchange something, such as buyers and sellers, riders and drivers, or fans and fans. An innovation platform is a foundation on which other companies build complementary products, such as an operating system and its applications. Their chapter on the subject is titled “Innovation, Transaction, or Hybrid”, and its argument is that the most valuable platform firms tend to be hybrids, companies that run both kinds at once.

Each kind makes different demands on design and governance. A transaction platform lives or dies on matching and trust: whether a buyer finds a seller, and whether both believe the exchange will be honest. Its rules govern conduct. An innovation platform lives or dies on the stability of what others build on: whether its interfaces hold still long enough to be worth building on, whether its documentation is good, and whether its owner will compete with the complements. Its rules govern change.

Verified Resale is a transaction platform, and Encore’s partner application programming interface (API) makes it a narrow hybrid. Partners build storefronts on Encore’s interfaces, so the innovation side’s demands apply to them: the 12 months’ notice of breaking changes, the sandbox, the developer experience that the Products book’s Section 9.4 designs. But partners build only storefronts. They cannot build new kinds of exchange, new rules or new ways to move money, and that narrowness is deliberate. It means the governance Encore must invent is mostly transaction governance, and the innovation governance it needs already exists in its public API program (the Architecture book, Section 7.5).

The core interaction, written into the system

The Products book’s Section 2.3 teaches the core interaction, the single exchange a platform exists to make happen, described by its participants, its unit of value and the filter that matches one to the other. Here we take the result as given and ask what it does to the code. Encore’s design reviews for resale begin from one sentence, which the Resale team wrote at month 4 and has changed only once:

A screened fan buys, through any authorized channel, a listing that is tied to one real ticket bought through the Gate, at no more than the price its seller paid, and receives that ticket reissued in their own name.

Each phrase in the sentence maps to a component and an owner. “A screened fan” is Bot Screening and the per-buyer limits. “Any authorized channel” is the partner program and the listing pool, which shows every listing on Encore’s app and on every partner. “Tied to one real ticket” is the listing’s reference to a ticket identity held by Seat Inventory & Ticketing, which makes a listing for a ticket nobody holds impossible to create. “At no more than the price its seller paid” is the cap, enforced by the Resale service. “Reissued in their own name” is the Inventory team’s reissue, which Section 8.2 examines. A proposal that cannot say which phrase it touches is either outside the product or a sign that the sentence is incomplete, and the one change to the sentence came from exactly such a proposal, when Ireland’s law forced the team to separate “the price its seller paid” from “what the buyer pays”. The same test screens out features that would make the market busier without making the exchange safer, since such features touch no phrase at all.

How far to open, and when

Openness is a set of levers, and Parker, Van Alstyne and Choudary devote a chapter of Platform Revolution (2016) to them. A platform decides who may join, what they may build, and what they may see, and the third lever covers data and access to participants as much as it covers interfaces. The Products book’s Section 2.4 treats openness as a strategic choice. The engineering concern is the sequence in which the levers move and the mechanisms that hold them in place: credential scopes, partner tiers, and contracts.

Encore’s history shows what happens when the levers are set in the wrong combination. From year 6, under “Partner Listings”, partners could post resale offers that appeared as links on sold-out event pages, but the ticket changed hands outside Encore, and Encore checked nothing beyond the partner’s word. Partner Listings was open on exactly the lever that should have been closed, what partners could assert, and closed on the lever that mattered to fans, whether the ticket was real. When Rowmate’s long-lived key leaked, the two fraudulent listings it produced were possible only because of that combination (the Resilience book, Section 7.2). Verified Resale reverses it. Partners may assert almost nothing, since every listing is checked against a real ticket and every sale is settled by Encore, while fans gain many more places to buy.

The sequence matters as much as the setting. Cusumano and his co-authors list mistiming and hubris among the common platform mistakes, and both describe the temptation to open everything on the first day. Encore opened in three steps: a closed pilot with Rowmate, then partners admitted through certification, and never an open resale API that anyone could call. Ticketmaster showed the same instinct under regulatory pressure: on 13 August 2018 it closed its secondary sites, Seatwave and Get Me In!, across Europe, and replaced them with fan-to-fan resale at face value or less inside its primary site.

A festival site is a fair picture of the levers. Wristbands of different colors decide who may enter the arena, the pit or the backstage area, and stewards check them at each boundary. Scopes on a partner’s credentials do the same work at the gateway. The picture breaks at judgment. A steward can recognize that a wristband looks wrong and ask a question; a gateway enforces exactly what the scope says and nothing else. So the scopes must be drawn on the assumption that no person will ever review an individual request.

Fairness as invariants

The Products book’s Chapter 2 made fairness Encore’s strategy for resale, and this book’s Section 1.3 restated it as five invariants that the code must keep. A design invariant is a property the system must keep in every state it can reach, enforced at one named place and proved by a test that runs on every change. Each part prevents a failure: “every state” rules out invariants that break during retries, “one named place” rules out enforcement smeared across services where each team assumes another is checking, and “a test on every change” rules out slow drift. Chapter 3 builds the tests, mostly as property-based tests; Figure 8.2 records where each invariant is enforced in the running system.

Figure 8.2 — The five fairness invariants and the single place each is enforced. Other services may check again, but each invariant has one owner.

Building codes are the right comparison, and they are older than any of our methods. A city does not rely on each builder’s goodwill to keep a stairwell wide enough; it writes the requirement down, names the inspection at which it is checked, and refuses occupancy until it passes. The comparison breaks in our favor. A building inspector visits a few times during construction, and a building can drift out of compliance for years between inspections. An invariant test runs on every change, so the system can never be further than one change away from proof.

The law sits beside the invariants without commanding them. The EU’s Omnibus Directive (2019/2161) added to the list of commercial practices always considered unfair the resale of event tickets to consumers by a trader who acquired them using automated means to get around limits on the number of tickets per person or other purchase rules, and Member States have applied it since 28 May 2022. The prohibition binds the trader who resells. It does not require Encore’s design, and the invariants are Encore’s own commitments. What invariants 2 and 4 do is make it hard for anyone selling through Encore to break the Directive by accident, since a ticket bought by circumventing the Gate’s limits cannot be listed at all.

What Encore keeps

Cusumano and his co-authors frame an incumbent’s choice when platforms arrive as build, buy or belong: build a platform of its own, buy one, or join someone else’s. Encore’s answer is a blend, and the line through it is drawn by what must be true at the gate. Encore builds and keeps the system of record for ticket identity, the reissue that changes it, and the ledger that records the money. It belongs to its partners’ audiences, letting Rowmate and Tessera be storefronts with their own buyers, discovery and marketing. Ticketmaster’s 2018 move followed the same logic, whatever its motives: resale moved inside the system that issues tickets, which is the only system that can guarantee them. The general economics of building and buying belong to the Architecture book’s Chapter 13, and the positioning of each capability on a Wardley map to the Products book’s Section 2.4. The narrower point here is that a transaction platform should own whatever makes the transaction trustworthy, and should be content to let others own whatever makes it convenient.

Recap. National BankAmericard showed that rivals can sell through one system when the network sets and enforces shared rules, with a default division of money that nobody has to negotiate, and that rules about price must be defensible in public. Verified Resale is a transaction platform with a narrow innovation side, so its governance is mostly about conduct. Its core interaction is written as one sentence whose phrases map to owners, its openness is set lever by lever and in sequence, and its fairness is a set of invariants, each enforced in one place and tested on every change.

Exercise 8.1. Write your product’s core interaction in one sentence that names the participants, the unit of value and the filter. Under each phrase, name the component and the team that make it true. Then list the invariants that keep the exchange fair, and for each one name the single place it is enforced. If you cannot name one place, you have found your first piece of work.

8.2 Designing a Marketplace

Measuring liquidity

The Products book’s Section 2.3 explains why most matchmakers fail, in Evans and Schmalensee’s phrase from Matchmakers (2016), because they “ignite or fizzle”: they never reach enough participants on both sides at once. It also chose Encore’s ignition plan, which piggybacks on fans Encore already has and on buyers Rowmate already has. What that section leaves to engineering is measurement, because a marketplace that cannot see its own liquidity cannot tell ignition from a slow fizzle until it is too late.

For Encore, liquidity is the likelihood that a listing finds a buyer before it can no longer be used. The general idea is common to every marketplace, but the measures are Encore’s own choice, and two of them do most of the work. The first is the share of listings sold before the resale window closes, two hours before doors. The second is the median time from listing to sale. The first tells Encore whether sellers are being rescued; the second tells it whether buyers are finding listings while they still care. Both are computed per event class, since a stadium show and a 400-capacity club behave as different markets: the stadium has thousands of listings and thousands of buyers, while the club may have three listings and no buyers at all.

An unsold listing is a broken promise: the fan is out of pocket and cannot attend. The Resale team’s first live-quarter key result was that at least 55% of listings sell before the window closes, and Encore watches that number for events above 5,000 capacity, setting no target for small venues, where the market may simply be too thin. It also built one seeding mechanism that the Products book’s Section 2.3 did not need to describe. When a fan asks Support for a refund that the policy does not allow, the reply offers to list the ticket on Verified Resale, which turns a refusal into a listing and adds supply exactly where demand for refunds signals that some fans can no longer go.

The listing lifecycle

Evans and Schmalensee call the design of a marketplace’s rules its “interior design”, and their point is that the rules are part of the product, as much as any screen. In software the rules attach most naturally to transitions. A listing is a small state machine, shown in Figure 8.3, and each transition is the moment at which some rule is checked and some team’s code runs. Modeling a lifecycle as a state machine with guarded transitions is long industry practice; its value here is that it forces the organizer’s rules (Section 7.3) and the platform’s rules to be checked at named moments, where they can be tested, and nowhere else.

Figure 8.3 — The listing state machine. Every rule is checked on a transition; partners are told of every transition by webhook and reconcile their copies hourly.

Two details of the figure deserve a closer look. The first is the window’s close. Encore ends resale two hours before doors, by default, so that reissue, delivery to the buyer’s phone and the update of every gate’s revocation list can finish while there is still time to fix anything that goes wrong; organizers may shorten the window but cannot lengthen it. The second is the “withdrawn” transition, which is where rule changes bite. When an organizer lowers a cap below the price of an existing listing, the listing is withdrawn and the seller is invited to list again at the new price. The alternative, letting old listings keep their old terms, would quietly turn a tightening rule into a loosening one for everyone who listed early, which is precisely the kind of exception that invariant 3 exists to forbid. Partners hold copies of listings, and copies drift, so every transition is published to them and they reconcile on a schedule, as the Products book’s Section 9.5 designs.

Reissue as the trust mechanism

Reissue is the step that, on every resale, voids the seller’s ticket identity and issues a new one to the buyer, as one atomic operation inside Seat Inventory & Ticketing. The Inventory team owns issuance and revocation, and the Resale service calls it; Section 9.5 tells how a request for comments (RFC) and an architecture decision record settled that ownership. Two mechanisms make the old identity worthless. Every mobile ticket at Encore already carries a rotating barcode, generated on the phone from a per-ticket secret, so a screenshot stops working within seconds; reissue goes further by changing the ticket identity behind the barcode. And the old identity joins the revocation lists that every venue scanner holds for offline validation, so even a device that has not heard the news refuses the seller’s old ticket. Wallet passes are updated too, but wallet updates are best effort, and Apple Wallet passes at Encore do not rotate, so the guarantee is the revocation list at the gate (the Products book’s Section 8.3 covers the phone).

The design has a well-documented precedent. In May 2019 Ticketmaster announced SafeTix, a ticket whose encrypted barcode refreshes every few seconds and is tied to the holder’s account and phone, and on transfer the recipient receives a new ticket. It went into production at scale that year, starting with National Football League stadiums for the 2019 season and selected tours. The precedent also shows the cost. At a Black Keys show at the Wiltern in Los Angeles in September 2019, fans who did not have the rotating ticket on their phones were refused entry, and the episode became a public lesson in what phone-only entry demands of fans and of gate staff. Rotating credentials are proven, but the gate and its staff have to be ready for them.

Reissue also closes a door that regulators have had to close by force elsewhere. A listing in Verified Resale references a ticket identity that exists and belongs to the seller, so a speculative listing, an offer to sell a ticket the seller does not yet hold, cannot be created. In the United Kingdom, the Competition and Markets Authority (CMA) secured a court order against viagogo in November 2018 that required it, among other things, to prevent the sale of tickets a seller does not own and may not be able to supply. In July 2019 the CMA said it would seek contempt proceedings for non-compliance, and it suspended them in September 2019 after viagogo addressed the outstanding issues. Encore sells only in the EU, so the case is context, but its lesson is general: a rule that a platform must police listing by listing is far weaker than a structure in which the forbidden listing cannot exist. Partner Listings, the year-6 predecessor, had sold the same barcode to several buyers, and that was the first line of the bet memo’s diagnosis.

The box office returns desk is the oldest version of the mechanism. A theater that accepts returned tickets takes the old ticket back across the counter, tears it, and sells a new one for the same seat, and the house guarantees the new ticket because it issued it. Reissue is that desk at the scale of a continent, with partners in place of the counter. The comparison breaks on the torn ticket. At the returns desk the old ticket is physically destroyed in front of the clerk; in software the old identity survives on the seller’s phone and in every screenshot, and only the revocation list at every gate makes it worthless. That is why revocation, more than issuance, is the part of reissue the Inventory team tests hardest.

Money flows and fee sharing

The money in a resale moves among more parties than in a primary sale, and law governs its flow as much as convenience does. The resale price is capped at what the seller originally paid, including primary fees, which these books call face value. The buyer pays a 10% service fee on top, shown in the all-in price from the first screen. Of that fee, 4 points go to the partner through which the buyer purchased, 3 to the organizer and 3 to Encore; when the buyer purchases in Encore’s own app, Encore keeps the partner’s 4 points as well. Encore’s points carry the payment fees, fraud losses and support costs. The seller receives the resale price in full, five days after the event, when the ticket is no longer at risk of a dispute.

Who holds the buyer’s money during those days is the question that shapes the system. The revised Payment Services Directive (PSD2, Directive 2015/2366) excludes from its scope payments made through a commercial agent authorized to negotiate or conclude a sale on behalf of only the payer or only the payee (Article 3(b)). Its recital 11 explains that an agent acting for both sides is excluded only if it never, at any time, enters into possession or control of the client’s funds, and the European Banking Authority’s answer to question 2020_5355, final in December 2021, adds that national authorities decide each case from the business model. In fan-to-fan resale Encore serves the selling fan and the buying fan alike, so the one-sided route very probably does not apply, and the both-sides route applies only if Encore never holds the money. The details are for counsel, but the consequence is plain: if Encore held sellers’ proceeds in its own account, it would need to be a licensed payment institution.

There are two proven ways out, and both have public examples. A marketplace can use a licensed PSP’s marketplace product, in which the PSP verifies the sellers, holds the funds in accounts in their names, delays payouts and splits each payment. Or it can become licensed itself, as eBay did after announcing in February 2018 that it would move its marketplace payments off PayPal to a system it managed, which in Europe runs through an eBay entity authorized as a payment institution in Luxembourg. Encore took the first route. Resale payments and payouts run through its primary PSP’s split-payment product; the seller’s proceeds sit at the PSP and are released on the payout date, and the 10% fee goes to Encore. The organizer’s 3 points and the partner’s 4 are then Encore’s own commercial obligations, paid out of its fee revenue, the organizer’s with the regular organizer payouts by Billing & Payouts and the partner’s on a monthly statement. Paying a commission from one’s own revenue is not a payment service. The law is still moving: the EU’s Payment Services Regulation and a third directive were provisionally agreed on 27 November 2025 and are close to adoption, and the exclusion for commercial agents is expected to narrow further, which is one more reason to keep Encore out of the flow of funds.

The choice has a price, and Encore wrote it into the decision record rather than discovering it later. Encore has two PSPs behind its anti-corruption layer, and its primary sales fail over from one to the other. Only the primary PSP carries resale, because the split-payment integration exists only there. When the primary PSP is degraded, primary sales move to the secondary and resale checkout pauses; listings stay listed, and buyers are told to try again shortly. It is a documented limitation with an owner and a review date, debt of the recorded kind Chapter 2 describes.

Touring has an old ritual for this. After each show the promoter and the tour manager sit down for the settlement, count the box office, deduct the agreed costs and split the rest, and nobody is paid until the numbers are known. Encore’s five-day payout is a settlement of that kind. The analogy breaks at the cash box. In a tour settlement the promoter holds the money and pays it out; in Verified Resale the law requires that Encore never hold it, so Encore keeps the count while the PSP keeps the cash.

Keeping the count is still hard work. Every resale writes entries in the finance ledger (the Architecture book, Section 9.1), and a reconciliation each day compares three records that must agree: the PSP’s settlement report, the ledger and the partners’ statements. One resale of a €60 ticket bought through Rowmate leaves this trace:

resale_sale   ticket T-48213 reissued as T-91770   channel: rowmate
  buyer_paid             66.00  held by primary PSP, split at capture
  seller_proceeds        60.00  seller's PSP account; release five days after the event
  service_fee             6.00  Encore's PSP account
    partner_commission    2.40  accrued; payable on monthly statement
    organizer_share       1.80  accrued; paid with organizer payout
    encore_retained       1.80  carries PSP fees, fraud and support
  release_trigger        five days after the event, if no dispute is open
  reversal_rule          chargeback before release: reverse all lines

Where the law caps the buyer’s total, as Ireland’s Sale of Tickets Act 2021 does for designated events, the buyer pays €60, the 10% fee is taken from the seller’s proceeds, and the split is unchanged. The ledger shows that case as a different seller_proceeds line and nothing else, which is a small sign that the model is right.

Fakesters and fraudsters

Every marketplace attracts people who want to cheat it, and Evans and Schmalensee devote a chapter (Chapter 9 of Matchmakers) to the “fakesters” and “fraudsters” that every matchmaker must keep out. Encore’s resale fraud falls into four kinds. Stolen cards buy resale tickets, and the real cardholder later reverses the charge. An attacker takes over a fan’s account, lists the fan’s ticket and changes the payout account to their own. A seller and buyer agree on a side payment off the platform to get around the cap. And a trader poses as a fan, listing far more tickets than any fan buys.

The controls are standard ones, applied at the transitions of Figure 8.3. The payout five days after the event is a hold that lets most card disputes surface before any money leaves. Velocity rules, written by Trust & Safety, watch how many listings an account creates and how fast. Step-up authentication is required before listing and before any change to a payout account. Encore’s first real fraud pattern after launch was a listing created within minutes of a password reset, followed by a change of payout account, and the rule written for it now requires step-up sign-in and a review by Trust & Safety whenever a listing follows a credential change within 24 hours. For traders, the law adds a duty as well as a motive. The Digital Services Act (Regulation 2022/2065) requires online marketplaces to collect and check identifying information from traders before letting them sell to consumers (Article 30), and since the Omnibus Directive marketplaces must tell consumers whether a seller is a trader. Encore admits no professional resellers at all, so its rule detects accounts that behave like traders, more than 20 tickets listed across more than four events in 12 months, and stops them listing until a person has reviewed the account.

Chargebacks need their own procedure. A buyer can attend a show and then tell the card issuer the ticket never arrived. A card-scheme dispute has deadlines, and a marketplace that cannot answer in time loses by default. Encore’s strongest evidence is the scan at the gate, which shows that the reissued ticket was used, at which door and when. Trust & Safety assembles the evidence automatically from the ledger and the scan records, and the policy on who bears the loss is written down: a chargeback that arrives before the seller is paid reverses the sale from the held proceeds, and one that arrives after is Encore’s loss unless the seller’s own fraud is shown.

Reputation is the classic marketplace defense, and the best evidence for its value comes from eBay. Paul Resnick, Richard Zeckhauser, John Swanson and Kate Lockwood ran what they described as the first randomized controlled field experiment of an internet reputation system, published in 2006. An established seller with a strong reputation sold matched lots of vintage postcards under his own identity and under new ones, and buyers paid 8.1% more to the established identity; one or two negative ratings on the new identities had no measurable effect. The experiment shows that buyers pay for a seller’s history when they bear the risk of the seller. Verified Resale removes most of that risk, since the buyer’s ticket is reissued and guaranteed whatever the seller’s history, and so Encore deliberately builds no seller ratings. The reputation that matters in its market is the partners’, and Encore tracks it as dispute rates per partner that feed the enforcement described in Section 8.3. Bot Screening’s operation belongs to the Resilience book’s Section 1.3.

Recap. Liquidity needs measures of its own, chosen per event class, because an unsold listing breaks a promise to the seller. Rules belong on the transitions of an explicit listing lifecycle, where each is checked once and tested. Reissue, with revocation at every gate, is the mechanism that makes a resold ticket trustworthy and speculative listings impossible. Under PSD2 a marketplace that serves both sides must never hold the buyer’s money, so the funds flow through a PSP’s marketplace product while Encore keeps the ledger, and the fraud controls sit at the same transitions as the rules.

Exercise 8.2. Draw your marketplace’s listing state machine as Figure 8.3 draws Encore’s. Mark the transition at which each rule and each fraud control applies, and name its owner. Then trace one payment from buyer to seller and write down, for every day the money is in flight, whose account it sits in. If any of those accounts is yours, take the question to counsel before you build further.

8.3 Partner Programs

A program around an API

An API lets a partner call a system; a program lets a partner build a business on it. A partner program is the agreement, tiers, enablement, review, support and change management that a company wraps around an API product so that other businesses can depend on it safely. Medjaoui, Wilde, Mitra and Amundsen, in Continuous API Management (second edition, 2021), describe the pillars of an API product and its lifecycle; the Products book’s Section 9.4 applies the lifecycle to Encore’s partner API, and the Architecture book’s Section 7.5 measures the developer’s first call. At Encore the program is jointly owned: the Partner APIs team runs the technical side, from sandbox to certification to credentials, and a partner manager who works with the Resale team’s product trio owns the agreements and the relationships.

The “Verified Resale Partner” program has one tier at launch, because two partners do not justify a hierarchy, and every partner signs the same terms. What a well-run program adds beyond the agreement is operational communication. Partners receive the on-sale calendar, since they are rate-limited per partner during major sales and should know when; they receive incident notices from the same status page fans see; and they receive a change calendar that shows every planned change to the partner API months ahead.

Airlines offer a fair analogy. A codeshare lets one airline sell seats on a flight another airline operates, under the operating carrier’s rules for safety, baggage and boarding, with the revenue divided by agreement. The selling airline owns the customer relationship; the operating airline owns everything that must be true for the flight to happen. The analogy fails on scale: codeshare partners are usually peers with flights of their own, while Rowmate and Tessera depend on Encore entirely for this product, which obliges Encore to change its rules slowly and in public.

Vetting and onboarding partners

Admitting a partner is a workflow with four parts: verifying the business (know-your-business checks), meeting any registration a market requires, completing a security questionnaire, and signing the contract. Encore runs it on the same durable-workflow rails that onboard tenants (Section 7.1), with each step idempotent, owned and visible, and with the human steps carrying owners and deadlines. Two credentials come out of it at different times. Sandbox credentials are issued the day the workflow starts, so the partner’s engineers can begin; production credentials are issued only after certification. Both are the 15-minute, certificate-bound tokens that every partner has used since the Rowmate leak (the Resilience book, Section 7.5), so there is no long-lived key for a contractor to commit to a public repository.

The two partners’ timelines show what a program is for. Rowmate, the pilot, spent about three months between entering the sandbox and going live, from month 9 to month 12, and much of that time was spent writing the certification suite with Encore, since nobody yet knew what a resale partner had to prove. Tessera arrived with the program already built. It failed its first certification run, for a reason the next subsection describes, fixed the fault and passed, and its first live listing came 11 days after it was certified. The difference is the program’s return, because what Encore and Rowmate learned during the pilot did not have to be learned again.

Certification as a program

The Products book’s Section 9.4 lists what a resale partner must demonstrate in the sandbox before receiving production credentials. The program decides who runs the suite, when it is rerun, what failure means and what it costs. The partner runs the suite itself against the sandbox, as often as it likes, and Partner APIs reviews the results along with a recorded walk-through of the partner’s own screens. A partner recertifies on every major version of the partner API, after any change to how it handles listings or payments, and after any serious incident in which it was involved. A failure blocks production credentials and returns a written list of findings. Certification is free, since Encore wants partners more than it wants the fee. Precedents exist at much larger scale: Salesforce’s AppExchange requires a security review before an app is listed, and Shopify reviews apps before they appear in its App Store.

Tessera’s failed first run shows what certification is really testing. Tessera’s storefront cached listing prices to keep its pages fast, and when the suite lowered an organizer’s cap in the middle of the run, Tessera went on showing the old, higher price for longer than the suite allowed. The fix was easy, consuming the rule-change webhook and invalidating the cache, but in production fans would have seen prices the organizer had forbidden. Most of what can go wrong between partners and a platform happens when rules change, and a suite that tests only steady state certifies very little.

What partners may and may not do

The contract states the policy, and the gateway enforces whatever part of it can be enforced by machine. The principle at Encore is that every “may not” has an enforcement next to it, either automatic at the gateway or detectable in audit. Figure 8.4 is the list as it stands at the month-18 review.

Figure 8.4 — Encore’s “may and may not” list for resale partners. Breaches of policy move up a ladder of warning, throttle, suspension and termination.

Breaches move up an enforcement ladder: a written warning, then throttling, then suspension, and termination last. The ladder is published in the agreement, and the partner manager decides each step with Partner APIs. Encore has used the second rung once. In the third month after launch a partner’s listing traffic for one event exceeded its event-scoped limit during a major on-sale, and it was throttled to its quota until the sale ended; the cause was a retry loop in its synchronization job. Credential hygiene belongs to the Resilience book’s Section 7.2, and the partner terms, including the 12 months’ notice, to the Products book’s Section 9.4.

Revenue share and partner statements

The partner’s 4 points are earned when a sale happens and kept only when the sale holds. Encore accrues the commission at the sale, releases it at the same moment it releases the seller’s money, five days after the event if no dispute is open, and reverses it if the sale is reversed by a chargeback or a cancelled event. Each month Billing & Payouts generates a statement for each partner from the ledger, showing what was accrued, released and reversed, line by line and ticket by ticket. A partner may dispute any line within 60 days, and the Finance platform team answers from the ledger events behind it. The statement is reproducible from those events, which is the same discipline the Products book’s Section 5.4 asks of invoices.

Revenue share is a strategic lever, and partners remember every movement of it. Shopify’s public history makes the point well. At its Unite conference in June 2021 it announced that, from August that year, developers would pay no revenue share on their first US$1 million of annual app revenue and 15% above it, down from 20%. In April 2025 it announced that, from 16 June 2025, the exemption would apply to the first US$1 million of lifetime revenue instead of resetting each year, with only revenue earned since 1 January 2025 counting toward it, and developers who had planned their businesses around the annual reset said so publicly. Encore therefore treats a change to the partner commission like a breaking change to the API, with 12 months’ notice, since it disrupts a partner’s business as much as any change to an interface.

Partners who compete

Rowmate also runs resale for other ticketing companies, where tickets are not reissued and caps are not enforced. That makes it a partner in Encore’s market and a competitor in the wider one, and the Products book’s Section 2.4 maps what that means strategically. The engineering consequence is information walls. Each partner sees only its own listings, sales, statements and reports, never another partner’s. The walls do two jobs. They protect each partner’s commercial position, and they keep Encore from becoming a channel through which competitors learn about each other, a recognized risk under EU competition law on information exchange between competitors; that second job is a matter for counsel, and Encore’s partner policy says so.

Parity clauses are the other trap. A wide parity clause, one that requires a seller not to offer better terms on any other platform, is excluded from the EU’s block exemption for vertical agreements (Regulation 2022/720, Article 5(1)(d)), so it needs an individual assessment; narrow parity, covering only the provider’s own direct channel, remains exempted. The Digital Markets Act bans parity clauses outright only for designated gatekeepers, which Encore is not. Encore asks for no parity at all, and it hardly needs to, since the price is capped, the pool is the same on every channel and the fee is the same everywhere. Its own app is a channel too, and it keeps 7 points when it sells there, so the rule that matters is the one Encore imposes on itself: every channel receives the same listings in the same order, and partners can verify that from the feed.

Recap. A partner program is the business wrapper around an API product: agreements, tiers, enablement, review, support and change communication. Onboarding is a workflow on shared rails, with sandbox credentials at once and production credentials after certification, and certification should test behavior when rules change. Every “may not” needs an enforcement beside it and a published ladder above it, commission should be earned only when the sale holds, and partners who compete need walls between them, with no parity clauses that would need defending.

Exercise 8.3. Write your partner program’s “may and may not” list as a table like Figure 8.4. For each “may not”, name the enforcement: a scope, a limit, a test, an audit or a contract clause. Mark every “may not” whose only enforcement is a contract clause, and decide whether you can move it to the gateway.

8.4 InnerSource

Shared code without a ticket queue

Inside a company of 40 teams, code is shared in two ways, and both go wrong. A team that needs a change in another team’s component can ask for it, and wait in that team’s backlog behind work the owner considers more important. Or it can copy the component and change the copy, and leave the company with two versions that drift apart for years. InnerSource is a third way: the use of open-source development practices inside one organization, in which code is visible to every team, any team may contribute changes by pull request, and the owning team keeps responsibility for what is merged. The name is usually traced to a column Tim O’Reilly wrote in December 2000, in which he described helping large companies use open-source development techniques internally and called the work “inner sourcing”. Its vocabulary is borrowed from open source: the owning team is the host, and contributing teams are guests.

The research supports the practice and is candid about its conditions. Danese Cooper and Klaas-Jan Stol’s Adopting InnerSource (2018) collects case studies from companies including PayPal, Bosch and Ericsson. Stol and his co-authors, in a 2014 study of the key factors for adopting it, found that most of those factors were organizational: who may contribute, how contributions are recognized, and whether managers make room for them. InnerSource complements the X-as-a-Service mode that Chapter 6 describes and does not replace it. A platform that serves many teams through a stable interface should usually stay a service. InnerSource suits the component that many teams need to change, where the changes come from the guests’ own domain knowledge.

Scholarly publishing is a fair picture of the arrangement. A journal’s editor does not write the articles; contributors submit them, referees review them, and the editor keeps the standard and decides what is published. The host team is the editor, and its trusted committers are the referees. The picture breaks on motive. Authors submit to journals because publication advances their careers. Guests contribute to InnerSource projects because they are blocked, and once unblocked they have little reason to stay. That difference explains why recognition, which a journal gets for free, has to be designed into InnerSource deliberately.

Trusted committers and contribution rules

A trusted committer is a member of the host team whose job is to help guests contribute well: answering questions, reviewing pull requests, mentoring, and guarding the component’s quality. The role is a named pattern in the InnerSource Commons catalogue, and Cooper and Stol’s chapter on PayPal describes it in practice, together with a written contribution guide and response times that the host publishes and keeps. The role is an investment of the host’s time, and it has to be counted as one. I have spent a decade maintaining a widely used open-source library, and the lesson that experience taught most firmly is that the contributors a project keeps are the ones who heard back quickly the first time.

Encore’s resale rules engine has two trusted committers at any time, and Encore rotates them each quarter, so the knowledge spreads and nobody becomes the engine’s only gate. The rotation is Encore’s own choice and is not prescribed by the sources. Discoverability matters at 40 teams as well; the catalogue’s InnerSource Portal pattern exists so that guests can find projects open to contribution, and Encore lists the engine in its developer portal with its contribution guide. The guide is short enough to read in a minute:

# Contributing to resale-rules
Host: Resale team. Trusted committers this quarter: see OWNERS.
1. Open an issue first for any new rule type; describe the organizer need.
2. New rule types need a short RFC; reviewers: both trusted committers.
3. Every rule must be expressible in the typed schema; no free-form rules.
4. The fairness invariant suite must pass; never edit it in the same PR.
5. Add property tests for your rule's boundaries (see tests/rules/README).
6. First response within one working day; merge decision within five.
7. Your team fixes defects in your rule for 30 days after release.
8. Ask in #resale-rules; office hours Tuesday 14:00 CET.

Patterns that work

The InnerSource Commons maintains a catalogue of patterns, each a documented solution to a recurring problem, with known instances at named companies. Three of them shaped Encore’s guide. The 30 Day Warranty, drafted at the Spring 2017 InnerSource Summit, has the contributing team fix defects in its contribution for 30 days after it reaches production; it answers the host’s natural fear that guests will merge and leave, and some companies use longer periods, GitHub six weeks. Issue Tracker Use Cases and Transparent Cross-Team Decision Making using RFCs together describe discussing a change before writing it, which saves guests from building a pull request the host will refuse. And Contracted Contributor answers the question of time: a formal agreement among the contributor, their line manager and a central office that caps the time spent on InnerSource, reimburses the contributor’s business unit, and gives the community leader a voice in the reviews of anyone contracted above 20%. The catalogue also includes Praise Participants, a reminder to thank contributors visibly.

The cases Cooper and Stol collected point to one conclusion, which is their synthesis and worth stating as theirs: management support decides the outcome more than tooling does. Stol’s earlier study points the same way, since its key factors concern people and incentives far more than software.

Encore’s resale rules engine

The resale rules engine is the typed library that evaluates every organizer and platform rule at the transitions of Figure 8.3. The Resale team hosts it, and five guest teams contribute rule types from their own domains: Orders & Payments, Inventory, Trust & Safety, Pricing & Presales and Festivals. Festivals is writing a cap kind for multi-day passes split into day tickets, where face value must be computed from the pass price, so that festival passes, deferred at launch, can join; Pricing & Presales contributed the rules for tickets bought in presales; Trust & Safety contributes the listing-velocity rules. Each team knows its own domain far better than the Resale team could, and each would otherwise have waited a quarter in Resale’s backlog for a change it could write in a week.

The fairness invariant tests are the gate every contribution must pass, and the guide forbids changing them in the same pull request as a rule. Guests are trusted to change the rules because no rule they write can break an invariant without a test failing, and the invariant tests change only through the host’s own review. The typed schema has a second benefit: the organizer rule assistant, the one AI feature in Verified Resale, can express only rules the schema allows, so whatever it drafts is bounded by the same tests.

When InnerSource fails, and how to tell

InnerSource fails when guests have no time allocated for contributing, so contributions are squeezed between deadlines and abandoned. It fails when contributing earns no recognition, so the people who do it once never do it again. And it fails when the host is overwhelmed, so pull requests wait for weeks and guests conclude that copying would have been faster. The patterns above exist because each failure is common: Contracted Contributor answers the first, Praise Participants the second, and the 30 Day Warranty, by reducing the host’s risk, the third.

Encore learned this before the rules engine. In year 8 the Seat Map team opened its renderer, seatmap-renderer-v2, to contributions from Event Setup and Box Office, which both needed changes for their own screens. Nobody’s quarterly plan contained time for it, the Seat Map team had no trusted committer and was preparing for the Vesper Hale on-sale, pull requests waited weeks for review, and within two quarters the guests had gone back to filing requests in the Seat Map backlog. When the rules engine opened, the lesson was written into planning: each guest team’s quarterly plan carries explicit time for its rule types (Section 10.2), the host names its trusted committers, and contributions appear in the engineers’ reviews.

To tell success from slow failure, Encore measures what the CHAOSS project (Community Health Analytics in Open Source Software) defines for open source, applied to one repository: time to first response, change requests accepted, and the number of active contributors, combined much as the catalogue’s Repository Activity Score pattern suggests. By month 18 the engine had merged 37 changes from guest teams, with a median first response under one working day and contributors from all five guest teams. A first-response time creeping from one day to four is the earliest sign of an overwhelmed host.

Recap. InnerSource lets teams change shared code by pull request while the host keeps ownership, and it suits components whose changes come from the guests’ domains. Trusted committers, a short contribution guide and published response times make contributing practical, and the catalogue’s patterns answer the common failures of time, recognition and host overload. Its success depends on management making contribution part of the job, and its health is visible in response times and contributor counts long before it fails.

Exercise 8.4. Pick one shared component your team depends on and does not own. Write its contribution guide in ten lines: who the host is, how to propose a change, what must pass, how fast the host responds, and what the contributor promises after merge. Then ask the host whether they could keep the response time you wrote.

8.5 Platform Economics

Funding shared capabilities

Encore now runs two platforms, and they are funded in different ways for good reasons. The internal platform, the platform group’s nine teams, serves Encore’s own engineers. The business platform, Verified Resale, serves fans, organizers and partners. For a shared internal capability there are three common ways to pay. Central funding pays for it from the company’s overall engineering budget. A platform tax takes a fixed share of each product team’s budget to pay for it. Chargeback bills each team for its measured use at an internal price.

Mik Kersten’s Project to Product (2018) argues for funding long-lived products over temporary projects, and the argument applies to platforms with particular force, since a platform funded project by project is rebuilt every year by whoever has budget left. Gregor Hohpe’s chapter “Platform, Inc.” in Platform Strategy treats an internal platform as an internal business with customers and a strategy of its own, and Camille Fournier and Ian Nowland’s Platform Engineering (2024) shows how to keep it aligned with the teams it serves. Encore funds its platform group centrally, as a long-lived product with its own roadmap and its own measures, and it does not use chargeback. How the central budget enters the company’s allocation of capacity, including whether it appears as a platform tax in each value stream’s plan, is the subject of Section 10.4.

The business platform is funded the other way. Verified Resale was funded in tranches against milestones (Section 10.4), and it is expected to pay its own way from Encore’s 3 points per resale. A business platform has revenue and should be judged by its margin; an internal platform has none and should be judged by what it saves and enables.

Showback before chargeback

Showback shows each team the cost of what it uses, without billing it; chargeback bills it. The FinOps Foundation’s framework treats showback as necessary in every cost practice, and leaves chargeback to the company’s accounting policy, stating that neither should be considered more mature than the other. Chargeback can be worth its overhead where spending lands in many independent budgets, and it is often not worth it where, as at Encore, engineering spending lands in a few cost centers.

Encore’s choice is showback only. The Resilience book’s Section 2.5 already allocates more than 90% of the cloud bill to services and tenants, and the showback report builds on that allocation, showing each team its cost per service and its contribution to cost per ticket, a blended €0.16 of which about €0.12 is variable. There is also an argument against chargeback that Encore finds persuasive, though no study proves it. An internal price invites teams to save money by leaving the paved road, running their own cheaper database or their own deploy scripts, and the savings appear on the team’s bill while the costs appear later, in incidents and migrations nobody budgeted.

Unit economics of the business platform

Contribution margin per resold ticket is the revenue Encore keeps from one resale minus the costs that resale itself causes. The Products book’s Chapter 5 sets the price; this subsection asks what the price leaves. Figure 8.5 works the example on a €60 ticket, sold once through a partner and once in Encore’s own app. The PSP fee, fraud loss and support cost are Encore’s averages at the month-18 review.

Figure 8.5 — Contribution margin per resold ticket. The partner channel runs on a margin of 38 cents, and each additional point of dispute rate costs 15 of them.

On the partner channel, which carries most resales, the margin is 38 cents, and it is far more sensitive to disputes than to the fee. Each additional percentage point of resales that end in a dispute costs €0.15, so a dispute rate of about 4.5% would wipe the margin out entirely, while raising Encore’s share of the fee by half a point would add only €0.30. Encore learned from this that the cost of handling one dispute, about €15 of an agent’s time, decides its margin more than the fee level does, and it has spent its effort there: automatic assembly of gate-scan evidence, a self-service dispute flow, and the tracking of dispute rates per partner described in Section 8.3.

The other column carries a temptation, and the margin of €2.78 in Encore’s own app makes it plain. Encore earns seven times as much when a buyer purchases in its app, and a business optimizing its margin would steer buyers there. The rule from Section 8.3, every channel receiving the same listings in the same order, is what stops it, and the figure is the reason the rule had to be written down before anyone was tempted.

When to stop building

Every capability a company builds moves, over time, toward commodity, and the Architecture book’s Section 13.2 maps that movement using Simon Wardley’s evolution axis. The practical tool is a stop-doing list: a short, maintained list of capabilities Encore intends to hand to a vendor or retire, each with the criteria that put it there. Encore’s criteria are three: a mature product meets Encore’s requirements, Encore holds no knowledge in the capability that its competitors lack, and running it costs more than buying it.

The first entry on the list was Encore’s own feature-flag service. The Resilience book describes the rules Encore enforces on flags, each with an owner, a kind and an expiry date, no reused names, every change recorded as a production change, and expired release flags blocking deploys, and those rules are Encore’s own knowledge. The service that stores and evaluates flags is not; mature products do it well. So Encore decided to keep the rules as a thin policy layer over a bought flag product and to retire its own service through a deprecation campaign of the kind Section 6.4 describes, with a dated end and brownouts to find forgotten callers. The list also records what will never appear on it. Reissue and the ledger hold the knowledge that makes Verified Resale trustworthy, and Section 8.1 drew that line before any capability was weighed.

Reporting the value of both platforms

Encore puts both platforms on one page each quarter, because the same leadership funds both. David Anderson’s The Value Flywheel Effect (2022) argues for organizing technology work around time to value, and the page follows that idea: each platform reports how quickly the people it serves get what they came for. For the internal platform, the measures come from Section 6.5: the adoption funnel for each paved path, the quarterly developer-experience survey, and time to first production deploy for a new service. For the business platform, the measures come from the Products book’s Section 5.2: liquidity, take rate, dispute rate and organizer adoption.

A platform’s take rate is the share of the value of each transaction that the platform keeps as revenue. Verified Resale’s gross take rate is the 10% fee, but Encore’s own take is 3 points on partner sales and 7 points in its app, and the page reports the blended figure, since it shows the channel mix moving. The page shows trends and distributions, never rankings of teams or partners, under the rule Encore applies to every scorecard. When the internal platform’s time to first deploy falls and Verified Resale’s dispute rate rises in the same quarter, leadership can see that the next quarter’s best investment may be a support tool, not a faster pipeline.

Recap. Encore funds its internal platform centrally as a long-lived product and funds its business platform in tranches against a margin, and it judges each by the test that fits it. It shows teams their costs without billing them, because chargeback’s overhead and its pull away from the paved road outweigh its benefits at Encore’s scale. Contribution margin per resold ticket shows that disputes, more than the fee, decide whether resale pays its way. A stop-doing list retires what has become commodity, and one quarterly page reports both platforms by time to value.

Exercise 8.5. Compute the contribution margin per transaction for one marketplace or platform feature you know, line by line as in Figure 8.5. Name the cost you are least sure of, and work out how much it would have to move to make the margin zero. If that movement is small, find out who owns the cost.

Kata: Gear Between Rivals

Your brief: “Kitebridge.” Kitebridge is a software-as-a-service company of 120 engineers whose tenants are film-equipment rental houses: 260 houses in seven EU countries, renting cameras, lenses, lighting and grip to productions. When a house is short of a lens for a shoot, it borrows one from a rival, today by phone and by spreadsheet, about 11,000 times a year. Kitebridge wants a marketplace for those sub-rentals, in which houses list spare gear, other houses book it, and three production-management apps that crews already use book on their behalf, through Kitebridge’s API, as certified partners. A typical sub-rental is worth €1,400 for four days; the owning house expects a deposit of 30% and a share of the fee; and about 3% of rentals end in a damage claim, averaging €2,200, which today takes months to settle. Last year a pilot let houses hold deposits in their own accounts, and a dispute over a damaged lens lasted four months before anyone agreed whose money it was. The two largest houses will join only if their competitors can never see how busy their inventory is.

Deliverables:

1. Core interaction and invariants — Write the core interaction in one sentence, naming participants, unit of value and filter, and map each phrase to a component and owner. Then write the invariants that keep the market fair to small houses and large ones, and name the single place each is enforced.
2. The rental state machine — Draw the lifecycle of a sub-rental, from listing through booking, handover, return and inspection to settlement, as a diagram like Figure 8.3. Mark the transition at which each rule, each fraud control and each damage claim applies.
3. Money and deposits — Trace the buyer’s payment, the deposit and the fee from the booking house to the owning house. Decide who holds the deposit while the gear is out, and justify the decision against the possession-or-control rule of Section 8.2. Say what happens to the deposit when a damage claim is disputed.
4. The partner program — Write the “may and may not” list for the three partner apps, with an enforcement for every “may not”, and the certification tests that prove a partner handles a rule change and a cancelled booking correctly.
5. Contribution margin — Compute the contribution margin per sub-rental, line by line, including payment fees and the cost of handling a damage claim. Name the cost you are least sure of and the movement in it that would make the margin zero.

Rubric:

Where you now stand

You can now treat a product that others trade through as a system with rules of its own. You can write its core interaction as one sentence that maps to owners, turn its fairness into invariants enforced in one place each, put its rules on the transitions of an explicit lifecycle, and route its money so that the platform keeps the ledger while a licensed provider keeps the funds. You can build a partner program that admits partners through certification and governs them with enforcement they can see coming, open shared code to the teams who need to change it, and judge both of a company’s platforms by tests that fit them. Throughout, though, the teams have appeared as if they were fixed, and they are not: the Resale team was formed at month 4 out of two other teams, and it is about to grow and split. How an organization of 400 engineers grows, designs its teams and leads them is the subject of Chapter 9.

References

• David S. Evans, Richard Schmalensee — Matchmakers: The New Economics of Multisided Platforms. Harvard Business Review Press, 2016.
• Geoffrey G. Parker, Marshall W. Van Alstyne, Sangeet Paul Choudary — Platform Revolution. W. W. Norton, 2016.
• Michael A. Cusumano, Annabelle Gawer, David B. Yoffie — The Business of Platforms: Strategy in the Age of Digital Competition, Innovation, and Power. HarperBusiness, 2019.
• U.S. Court of Appeals for the Eleventh Circuit — National Bancard Corp. (NaBanco) v. VISA U.S.A., Inc., 779 F.2d 592. 1986 — free online.
• Visa — Dee Hock in memoriam. Visa, 2022 — free online.
• European Parliament and Council — Directive (EU) 2015/2366 on payment services (PSD2), Article 3(b) and recital 11. 2015 — free online.
• European Banking Authority — Single Rulebook Q&A 2020_5355. EBA, 2021 — free online.
• Danese Cooper, Klaas-Jan Stol — Adopting InnerSource: Principles and Case Studies. O’Reilly, 2018.
• InnerSource Commons — InnerSource Patterns. InnerSource Commons — free online.
• Mehdi Medjaoui, Erik Wilde, Ronnie Mitra, Mike Amundsen — Continuous API Management, 2nd ed.. O’Reilly, 2021.
• Paul Resnick, Richard Zeckhauser, John Swanson, Kate Lockwood — The Value of Reputation on eBay: A Controlled Experiment. Experimental Economics 9(2), 2006 — free online.
• European Parliament and Council — Directive (EU) 2019/2161 (Omnibus Directive). 2019 — free online.
• Competition and Markets Authority — Summary of the court order secured by the CMA against viagogo. GOV.UK, 2018 — free online.
• European Commission — Regulation (EU) 2022/720 (Vertical Block Exemption Regulation). 2022 — free online.
• FinOps Foundation — Invoicing & Chargeback. FinOps Framework — free online.