Chapter 1 — Definition, Landscape and Stakes

A small business whose product lives inside other companies' systems is a complementor, so this chapter defines a platform, an ecosystem and a complementor in this book's own words, treats integrating with a dominant offer as a decision rather than a feature, reads the research at the level of its abstracts, draws the lines between this book and its neighbors, names dependence as the price of access, calls the rules that touch platforms to the books that own them, and opens the case of Hydrosentinelle inc. on day 1.

What You'll Be Able to Do

• Define a platform, an ecosystem, a complementor, a dominant offer and dependence in this book's working words, and say what each one is not.
• Tell the difference between a business that buys a tool and a business that builds on a platform, and read the two-sided market at the level of the model that describes it.
• Treat an integration with a dominant offer as a decision with five questions rather than as a feature, and name the chapter of this book that answers each question.
• Read the research on platforms and complementors for what its abstracts report, with the sample and the period, and never as a cause or as a promise for a reader's business.
• Place a question about a platform in the book that owns it, and keep for this book what concerns the complementor: where to plug in, on what terms, how far to open its own interface and how to keep control.
• Call the rules that touch platforms and the businesses on them to the books that hold them, and open the case of Hydrosentinelle inc. on day 1 with its posed figures and its printed ones.

Why It Matters

A business that does not know whose systems its customers run plugs into the wrong one. The owner hears that a competitor is listed on a platform and builds a connector to a system that a handful of customers use, while the system that holds most of the base is never opened. The remedy is a map of the systems the customers already run, drawn before anything is built, and a decision written down.

A business that signs terms it has not read has accepted a change it cannot refuse. Platform terms are drawn by the platform owner and accepted by the complementor, and the owner may change them with the notice the terms give. A fee that moves, a review that rejects, a listing that is removed or a program that closes to new applicants is each a term of the day it was read, and each can change the economics of a service that a small business has already sold. Reading the terms on the day of signing is the difference between a decision and an accident.

A business that lets its promise rest on a system it does not control has given away that promise. The promise of a monitoring service is that the alert arrives, and if that promise rests on a system whose owner sets the terms, it rests on those terms. This book's answer is not to refuse platforms; it is to plug in where the customers are, to keep every critical path outside any platform, and to measure the dependence against a ceiling set in advance. The chapters that follow work that answer out.

In This Chapter

Section 1.1 defines a platform and sets out what a platform is not. Section 1.2 covers ecosystems, complementors and the firms between a platform and its end customer, with the figure that places a business between the offers it can plug into and the ecosystem it may open. Section 1.3 treats integrating with a dominant offer as a decision with five questions. Section 1.4 reads the research at the level of its abstracts. Section 1.5 draws the lines between this book and its neighbors. Section 1.6 names dependence as the price of access. Section 1.7 describes the landscape without a typical figure. Section 1.8 calls the rules that touch platforms to the books that hold them. Section 1.9 opens the case of Hydrosentinelle inc. on day 1 and walks the plan of the book.

1.1 What a Platform Is, and What It Is Not

A platform, in this book's working words, is a system that other businesses build on or trade through, and whose owner sets the terms of access. The definition is this book's own, and it is deliberately narrow, because the word is used loosely in ordinary speech. A business that buys a tool from a vendor and uses it inside its own walls is not on a platform. A business that writes an application that runs inside someone else's store, that connects its service to a system its customers already run, or that sells through a marketplace whose owner sets the commission and the rules, is on one. The difference is not the size of the vendor or the sophistication of the software. The difference is who sets the terms of access, and whether another business's decisions can change the terms on which the first business serves its own customers.

The economics behind the word is older than the word. The abstract of the paper read for this book reports that many markets with network externalities are two-sided, that platforms must get both sides on board and court each side while making money overall, and that the paper models platform competition and the determinants of the price allocation between the two sides (Rochet & Tirole, 2003, abstract only). That is a model, and it shows what follows from its assumptions; it is never the evidence of a measurement, and no price of any real platform is drawn from it here. What the model gives a reader is a way of seeing that the terms a complementor is offered are a design choice of the platform owner rather than a fact of nature.

A second reading sharpens the definition. The abstract of the paper read for this book reports that a two-sided market is one in which two sets of agents interact through a platform and the decisions of each affect the other, typically through an externality, positive or negative, and that the paper explains the strategies firms consider and the implications for antitrust and regulation (Rysman, 2009, abstract only). The abstract is the author's own summary, and no rule follows from it here. What it supports is a caution: a platform is not simply a place where two groups meet, because the decisions of each group affect the other.

The word also covers two different things. The abstract of the paper read for this book reports two predominant types of platforms, internal platforms, which are company or product platforms from which a company derives a stream of products, and external platforms, on which an ecosystem of outside innovators builds complements, with general propositions on design, economics and management (Gawer & Cusumano, 2014, abstract only). The abstract reports propositions and never a measured effect. This book is about the external kind, seen from the side of the company that builds on it.

A fourth reading sets the tone for the chapter. The abstract of the editorial read for this book reports that research from information systems, strategy and economics has separately informed the understanding of platforms and infrastructures (Constantinides et al., 2018, abstract only). An editorial is not a finding, and nothing measured is drawn from it here; it is one reason this book reads each study at the level of its abstract and prints each figure with its sample.

The multi-sided model itself, its launch and its disintermediation are held by Book A1 (From Idea to Business Model, chapter 6), which promised that this book develops the model from the complementor's side; Chapter 2 takes that work up and this section does not redefine it. What this section adds is the complementor's reading of the same words, and the table below sets the five words this book uses beside what each means here and what each means for the company of the case. The company's readings are posed by this book and are illustrative; read the table as a vocabulary rather than as a description of any real business.

Table 1.1 — Platform, ecosystem, complementor, dominant offer and the price of access, with the company's reading

DEFINITION The words this book uses for a platform, an ecosystem, a complementor, a dominant offer and dependence

These are this book's working words, and no source read defines them in this sense. A platform is a system that other businesses build on or trade through and whose owner sets the terms of access. An ecosystem is the platform and the businesses that build on it or trade through it. A complementor is a business whose product works inside someone else's platform and gains from its reach. A dominant offer is the offer that a business's own customers already run. Dependence is the degree to which the business's service, revenue or customers rest on terms that someone else sets. A business that only buys a tool from a vendor and uses it inside its own walls is not on a platform, and a business that runs its own store for its own products is not automatically a platform business either. The multi-sided model, its launch and its disintermediation are Book A1's (From Idea to Business Model, chapter 6) and are not redefined here; this book develops that model from the complementor's side in Chapter 2.

1.2 Ecosystems, Complementors and the Firms in Between

An ecosystem is a structure, not a mood. The abstract of the paper read for this book reports that platforms are conceptualized as meta-organizations, less formal and hierarchical than firms but more closely coupled than markets, bound by design rules and an overarching value proposition, and that they need coordination among participants whose interests are not all aligned, through sources of authority, incentives and governance (Kretschmer et al., 2022, abstract only). The abstract reports a conceptualization and no measured effect. What it gives a small business is a warning about the word: an ecosystem is not a friendly community, it is a set of participants whose interests partly align and partly do not, held together by rules that one participant writes.

A second reading gives the structure a grammar. The abstract of the paper read for this book reports a structuralist definition of the ecosystem, a grammar for its structure and the distinctive aspects of ecosystem strategy, set against business models, platforms, coopetition, multi-sided markets, networks and supply chains (Adner, 2017, abstract only). The abstract is the author's own summary and reports no measurement. The value of the grammar for a complementor is that it separates the ecosystem from the platform: the platform is one participant, and the ecosystem is the whole set of participants whose work has to fit together for the customer to get a result.

A third reading explains why the set holds together at all. The abstract of the paper read for this book reports that modularity enables ecosystems, sets of interdependent organizations that coordinate without full hierarchical fiat through roles that face similar rules, bound by the non-redeployability of their collective investment, and that complementarities may be unique or supermodular, generic or specific, one- or two-directional (Jacobides et al., 2018, abstract only). The abstract reports a theory and no measured effect. In this book's reading, the phrase worth keeping is the non-redeployability of the collective investment: a complementor that has built an integration, learned a platform's review process and trained its support team has invested in something it cannot move to another platform without paying again.

One study in this section is empirical, and it is one industry. The abstract of the paper read for this book reports that in the semiconductor lithography equipment industry from 1962 to 2005, across nine technology generations, challenges in upstream components enhanced the benefits of technology leaders while challenges in downstream complements eroded them, and that vertical integration became more effective over the technology life cycle (Adner & Kapoor, 2010, abstract only). No software firm and no small business was measured, and the abstract reports a pattern in one industry over one period, never a law. It is printed here only to show that a study of an ecosystem can measure how the parts a firm does not control shape what that firm gains, in that one industry.

The external platform of the first section returns here (Gawer & Cusumano, 2014, abstract only), and it is the structure this book treats. Between the platform and the end customer sit several kinds of firm, and a small business can occupy more than one place at once. The complementors build on the platform, the integrators connect it to other systems, the resellers and advisers carry it to customers who will not buy it directly, and the customers run it and pay for it. Hydrosentinelle inc., posed by this book, sits in two of these places: a complementor of the first property-management system, and the owner of a mobile application listed on two stores. The end customer's side of a marketplace, the listing, the ranking and the marketplace economics, is Book F5's (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces, chapters 2, 4, 5 and 7), and this section never describes it. The running of a platform business lies outside this book (Book L8).

Figure 1.1 places a business between the dominant offers it can plug into and the ecosystem it may open itself, with the price of access and the neighboring books at the edges.

Figure 1.1 — Plugging in and opening up. A complementor gains access and reach and pays with dependence on terms, fees, review and removal set by someone else; six neighboring books hold what this book only names.

Read the figure band by band. The top band holds the three kinds of dominant offer a small business can plug into, the middle band holds the business as a complementor with the price of access, the bottom band holds the ecosystem the business may open itself, and the edges hold the six neighboring books that this book only names. The figure is this book's own drawing and illustrates its reasoning; it is not a finding of any source.

KEY CONCEPT A complementor gains access and reach and pays for them with dependence on terms that someone else sets

This is the idea of the section, and it is this book's own reading, never a finding of a source. Access and reach come with terms, fees, review and removal set by the platform owner. The reach is real: a listing inside a system that a customer already runs puts a product in front of that customer without a sales call, and an integration that opens a work order in the customer's own system saves the customer work. The price is also real, and it is paid in control rather than in money alone. The practical consequence is a habit rather than a rule: before joining a platform, write down what the business gains and what it gives up, and keep the answer where the next decision can read it.

1.3 Integrating With a Dominant Offer: A Decision, Not a Feature

An integration looks like a feature and behaves like a decision. On a screen it is a button, a connector or a listing; in the business it is a tie between the company's service and terms, fees, review and removal that someone else controls. A feature can be built, tested and shipped by the people who own the product. A decision has to be taken by the people who own the business, because it changes what the business depends on. This section rests on this book's own reasoning, and no source of this pass supports it; it is a method, not a finding.

The decision has five questions, and each of them is answered in a chapter of this book. The first is which systems the customers already run, answered in Chapter 3, which maps the dominant offers of a market and scores the candidates on one grid. The second is on what terms a platform admits a complementor, answered in Chapter 4, which reads a partner program, a partner agreement, a security review, a certification, a listing, a revenue share and a listing fee. The third is how far the company should open its own interface, answered in Chapter 5. The fourth is how much dependence is acceptable and how it is measured, answered in Chapter 6, which builds a dependence register with a ceiling set in advance. The fifth is how the data and the identity of a person cross the integration, answered in Chapter 7, which treats delegated access, scoped permissions, single sign-on, provisioning, signed and retried events, schemas and versions, and personal information that travels with an integration.

Three further chapters carry the decision into practice. Chapter 8 sets the cadence: the weekly watch of terms, fees and policies, the monthly reading of integration health, the quarterly review with each platform partner, and the yearly reset of the integration roadmap. Chapter 9 names the roles behind platform work and says when to get help. Chapter 10 gives the functions a tool must offer, without recommending any tool. Chapter 11 gives the ninety-day plan that puts the decision into days.

The decision is easy to mistake for a feature because it arrives as a customer request. A customer asks whether the product can open a work order in the system the customer already runs, and the answer looks like a build. What the request does not say is that the system belongs to another company, that its terms govern the connection and may change, and that the company's own service will from then on depend on a decision it does not make. The five questions above answer the request without pretending it is only a build.

Hydrosentinelle inc., posed by this book, takes the decision on day 28 of its plan, after the map of the platforms around its customers is drawn and the three candidate integrations are scored on one grid. The decision itself is told in Chapter 3. What matters here is the shape of it: a written decision, with the candidate chosen, the terms read by the outside lawyer, the cost posed, and the dependence register drafted with its ceiling. The company does not decide to integrate in general; it decides to integrate with one system, on terms it has read, with a way out written down.

WHO DOES THIS The owner decides where to plug in, and the leads read the terms and assess the build as the business grows

The work of this section is carried differently at three sizes. A solo owner decides alone and keeps the terms read in writing, because there is no second reader and the written copy is the only memory the business has. In a small team the owner decides and a developer assesses the technical side, so that the decision rests on an estimate of the build rather than on enthusiasm. In an established business a partnerships manager keeps the relationship with each platform and a product lead owns the interface; Chapter 9 names the roles in full. In the case, posed by this book, Karim Haddad, the head of sales and operations, reads the terms and draws the map of the platforms around the customers, and Laurence Bergeron, the president, product and engineering, makes the technical assessment. No hire is made for this work, and the two founders carry it beside the rest of their work.

1.4 What the Research on Platforms and Complementors Supports

The research on platforms and complementors is useful to a small business only if it is read at the level at which it was written. Five readings follow, each at abstract only, each with its sample or its setting, and each printed for what it reports and no more. The rule this book applies is simple and it is stated once here: an association is printed as an association, a model is printed as a model, and a study of one platform, one industry or one period is printed as exactly that.

The first reading is the closest to a complementor's own question. The abstract of the paper read for this book reports that among 1,210 small independent software vendors from 1996 to 2004, joining a major platform owner's ecosystem was associated with higher sales and a greater likelihood of an initial public offering, more so for vendors with stronger intellectual property rights or downstream capabilities (Ceccagnoli et al., 2012, abstract only). The abstract reports an association in one sample over one period, and it is never a cause; nothing after 2004 is measured, and no gain follows for a reader's business.

The second reading concerns interfaces a business opens rather than platforms it joins. The abstract of the paper read for this book reports that public firms that adopted public application programming interfaces grew an additional 38.7 percent over 16 years relative to similar non-adopters, with no significant effect from interfaces used only internally, that adopters which attracted more third-party complementors grew faster, that public interfaces raised the risk of a data breach, and that the work was partly supported by two interface-management vendors (Benzell et al., 2024, abstract only). The firms measured are public firms, the period is 16 years, and the funding is stated in the abstract; the figure is never an expectation for a small private firm.

The third reading is the one-industry study recalled from section 1.2: the abstract reports a pattern in the semiconductor lithography equipment industry from 1962 to 2005 (Adner & Kapoor, 2010, abstract only), in one industry and one period, with no software firm and no small business.

The fourth reading is a review. The abstract reports a systematic review of 333 articles published from 1985 to 2019 on platform competition, with four themes: winner-takes-all dynamics from network effects, corporate decisions such as vertical integration, heterogeneity of platforms and users, and how the platform hub orchestrates value creation and capture (Rietveld & Schilling, 2021, abstract only). The abstract reports themes and no rule for a complementor.

The fifth reading is a second review, from a different literature. The abstract of the paper read for this book reports a review of industrial organization, technology management and strategy views of platform-mediated networks in which users and complementors seek compatibility on a common platform, with a research agenda on network effects against platform quality and on complementor dynamics (McIntyre & Srinivasan, 2017, abstract only). The abstract reports a research agenda and no measured effect. The editorial recalled from section 1.1 makes a related point: several fields have informed the understanding of platforms separately (Constantinides et al., 2018, abstract only).

The table below sets the five readings beside the level at which each was read, who or what was measured, what the abstract reports and what it does not support. Read it as a reading list with its limits attached, and retain the last column above all: the limits are what keep a study from becoming a promise.

Table 1.2 — Five readings on platforms and complementors, at the level read

THE RULE An association is printed as an association, with its sample (Ceccagnoli et al., 2012)

The rule of this book is that a correlation is never written as a cause. The abstract of the paper read for this book reports that among 1,210 small independent software vendors from 1996 to 2004, joining a major platform owner's ecosystem was associated with higher sales and a greater likelihood of an initial public offering (Ceccagnoli et al., 2012, abstract only). The callout prints the association with its sample and its period, and it says three things plainly. An association is not a cause, because the study did not establish one and the abstract does not claim one. The sample ends in 2004, so nothing is known from it about any later period. And no gain follows for a reader's business, because a study of 1,210 vendors is not a forecast for one. The same discipline applies to every figure in this book: it is printed with its source, its year and who or what was measured, or it is not printed at all.

1.5 Where the Lines Fall: Channels, Marketplaces, Partners and Alliances

This book has neighbors, and a reader who does not know where the lines fall will read the same question in three books and act on none of them. A route to market is not a platform, a marketplace is not a partner program, an original equipment manufacturer arrangement is not an integration, and an alliance is not adhesion to terms. Each of those belongs to a book that owns it, and this book takes the complementor: where to plug in, on what terms, how far to open its own interface and how to keep control of its customers, its data and its service.

The ecosystem as a structure and the roles that face similar rules are recalled here from section 1.2 (Adner, 2017, abstract only; Jacobides et al., 2018, abstract only). Both abstracts report conceptual work and no measured effect. What they give this section is the reason the lines can be drawn at all: an ecosystem is a set of roles bound by rules, and a book can own one role without owning the others.

The table below sets eight neighbors beside what each holds and what this book holds. Read it as a boundary rather than as a hierarchy: no row is more important than another, and the last column is the part of each question that stays here. One of the rows names a book by its code alone, and the other cells of that row say only that the matter lies outside this book.

Table 1.3 — Where this book stops and its neighbors begin

The rows that matter most in practice are the first two. A customer who asks whether the company can be found in an app store is asking about a listing, which is Book F5's. A customer who asks whether the company's product can open a work order in the system the customer already runs is asking about plugging in, which is this book's. The two questions arrive in the same conversation and they are not the same question.

The partner program row deserves a note of its own. The company's own program of plumbers and installers is unchanged by this book: ten partners are active, seven referral and three certified installers, and no hire was made, as Book F9 (Building and Running a Partner Program) prints. What this book adds is the other direction: the program of a platform seen from the complementor who joins it, with its tiers, its review, its certification and its fees.

METHOD Placing a question about a platform in the right book in five steps

First, write the question in one sentence, because a question that takes three sentences may be two questions. Second, ask whether it concerns a route to market, a marketplace, a partner program, an original equipment manufacturer arrangement, a connection between tools, an alliance or a plug-in to a dominant offer. Third, send it to the book that owns that part, and read that book first. Fourth, keep for this book what concerns the complementor: where to plug in, on what terms, how far to open its own interface and how to keep control. Fifth, read the neighbor first when a rule is written there, because a rule read in the wrong book is a rule read at the wrong level. The sequence is this book's own, and no source tests it. The example is a customer asking whether the company can be found in an app store: the listing and its fees are Book F5's, and whether to plug into the customer's own system is this book's.

1.6 Dependence: The Price of Access

Access has a price, and the price is paid in control. A platform admits a complementor on terms the platform owner writes, and those terms cover what the complementor may build, what it may charge, how it is reviewed, when it may be removed and what notice it gets. The terms may change, with the notice they themselves provide. The platform owner may one day enter the complement's market. None of this is a defect of platforms; it is what a platform is, and a business that joins one is buying reach with a share of its own freedom to decide.

The research on this point is conceptual, and it is printed as such. The abstract of the paper read for this book reports that, drawing on power-dependence theory, the power asymmetry between a platform and its ecosystem members is intrinsic to the economics and architecture of digital platforms, that it creates novel risks, and that entrepreneurs who depend on platforms develop strategies to mitigate their dependence (Cutolo & Kenney, 2021, abstract only). The abstract reports a conceptual analysis and no measured effect, and no frequency or size of any risk is printed here. What it supports is the framing of this section: the asymmetry is not an accident of a badly run platform, it is a property of the arrangement, and the strategies that answer it are the subject of Chapter 6.

Dependence builds one convenience at a time. A connector is added because one customer asks for it, a listing because someone expects inquiries from it, a certification because a customer's procurement asks for it. Each step is reasonable on the day it is taken, and no single step is a decision to depend. By the end, a feature works only because a platform works, and nobody in the business can say when that became true. Chapter 6 calls this the way dependence builds, and it gives the register that makes it visible.

The way to keep access without losing control is not to refuse platforms. It is to decide where to depend, to measure the dependence against a ceiling set in advance, and to keep every critical path outside any platform. A ceiling is a number the business chooses before it needs one: no single platform brings more than a stated share of the new customers of a quarter, and no alert path runs through any platform. In the case, posed by this book, the ceiling is 40 percent of the new buildings of any quarter, and the rule that no alert path runs through a platform is absolute; both are told in Chapter 6 and in Chapter 11.

WATCH OUT A convenience becomes a condition when no one has decided to depend on a platform

The trap of this section is the convenience that becomes a condition. A connector is added for one customer, then for another, and no one has decided to depend; by the time the dependence matters, it is a fact rather than a choice. Two signs mark it. The first is a platform that nobody can name as the reason a feature works: the feature is described as working, and the system it depends on is not in the sentence. The second is a promise that waits on a vendor's system: the promise of the service is that the alert arrives, and the alert arrives only when another company's system is up. The remedy is small and it is written down. Each dependence goes into a register with its way out, and every critical path stays outside any platform. The reasoning is this book's own and no source measures the trap. The case's ceiling and its alert rule are posed by this book and told in Chapter 6.

1.7 The Landscape in 2026 and What Is at Stake

The landscape is told here in words, and it is told without a typical figure, because no source read for this book measures one. A small business finds its customers inside a few systems, a few stores and a few standards, and the owners of those systems, stores and standards set the terms. What the landscape does not have is a neutral ground: every one of those places has an owner, and the owner's terms are the terms.

Two pages read for this book give the landscape two anchors. The release of the national statistics agency, read on October 15, 2026, reports that as of 2023, 48 percent of Canadian businesses used cloud computing, up 3 points from 2021, that 32 percent received e-commerce orders, and that 7 percent of businesses with five or more employees used artificial intelligence (Statistics Canada, 2024). The page says that it is archived and that a more recent version exists, and no later release of this survey was found on the day it was read. The release gives no share of businesses selling through a third-party platform or an app store, and no figure after 2023, and this book prints none.

A second page gives a count, and it is a count of another jurisdiction's designations. The page of the European Commission read on October 15, 2026 reports that seven undertakings are designated gatekeepers for 23 core platform services, among them two mobile operating systems and two application stores, a retail marketplace and an online intermediation service for accommodation (European Commission, n.d.), and the callout below dates the designations one by one. The page shows no date of its own, so the facts are dated as of October 15, 2026. The undertakings are counted and never named here, and the count belongs to another jurisdiction's regime rather than being a rule for a business in Québec.

What is at stake is three sentences of reasoning, and they are this book's own. A business that does not know whose systems its customers run plugs into the wrong one, and the work it does reaches few of them. A business that signs terms it has not read has accepted a change it cannot refuse, because the terms it accepted are the terms the owner may amend. And a business that lets its promise rest on a system it does not control has given away that promise, because the promise of a monitoring service is that the alert arrives.

One sentence must be said plainly, and it is said once here. No source read for this book measures the typical share of revenue that a business earns through a platform, the typical cost of building or keeping an integration, or the typical commission a platform charges. This book prints no such figure, and a reader who finds one elsewhere should ask what was measured, in what sample, over what period, and by whom.

WHAT CHANGED The Commission counts seven designated gatekeepers for 23 core platform services as of October 15, 2026 (European Commission, n.d.)

The dated change comes from the page read on October 15, 2026, and it is dated by its source. The page reports seven undertakings designated gatekeepers for 23 core platform services, among them two mobile operating systems and two application stores, a retail marketplace and an online intermediation service for accommodation, with six first designated on September 6, 2023, one operating system added on April 29, 2024, one intermediation service added on May 13, 2024, and one marketplace service undesignated on April 23, 2025 (European Commission, n.d.). The count is the Commission's, it is for the European Union, and it is a rule of another jurisdiction rather than a right or a duty of a business in Québec or Canada. The undertakings are counted and never named. The count will change, because designations are made and withdrawn, and a reader who needs the current state should read the page rather than this book.

TOOLS OF THE TRADE What a business needs to see its platforms: a list, stored terms, a calendar of dates and one register

Four functions carry the work of this chapter, and a business should look for them rather than for a product. The first is a list of the platforms around the business that a person can correct, because a list nobody can correct is a list nobody trusts. The second is a stored copy of each platform's terms with the day it was read, because a term is a contract of the day read and a copy without a date is a copy that cannot be compared with the next one. The third is a calendar of the dates when a term, a fee or a review is due, so that a change is read in the week it arrives rather than in the month it hurts. The fourth is one register of integrations where each dependence is written with its way out. Chapter 10 gives the functions in full, without recommending any tool.

1.8 The Rules That Apply to Platforms and the Businesses on Them

None of the texts read for this book makes a small business integrate with a platform, and none of them forbids it to. That is the first thing to say, because a chapter about rules can give the opposite impression. The rules that touch platforms and the businesses on them are real, they are read here at the level at which they were read, and each of them is called to the book that holds it. This book does not say that no other rule exists, and it does not decide whether any agreement, clause or conduct complies with a rule.

In Canada, the competition statute is the Competition Act, R.S.C. 1985, c. C-34, read on the Justice Laws Website on October 15, 2026, current to September 21, 2026 and last amended on March 26, 2026. Section 75(1) lets the Tribunal order a supplier to accept a person as a customer in the conditions the text sets, section 77(1) defines exclusive dealing, market restriction and tied selling, and section 78(1) defines an anti-competitive act and lists acts. Section 79(1) provides that where persons substantially or completely control a class or species of business, the Tribunal may make an order on either of two alternative paths, a practice of anti-competitive acts, or conduct that prevents or lessens competition substantially and is not the result of superior competitive performance. Section 79(3.1) provides an administrative monetary penalty, named here and never computed, and section 103.1(1) lets any person apply to the Tribunal for leave to bring an application on refusal to deal, exclusive dealing or abuse of dominance, among others. All of these are called to Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements, chapter 5), which holds the abuse of dominance in Canadian law.

The competition regulator's guidelines are dated March 7, 2019; the page was modified June 27, 2024 and read on October 15, 2026, and a notice at the top says that after recent amendments to the Act the Bureau is reviewing its guidelines (Competition Bureau, 2019). Their three cumulative elements predate the amendments and are never printed here as the current test of section 79(1), which now has two alternative paths. For a multi-sided platform the Bureau may define a market on one side but accounts for interdependent demand and feedback effects across sides, and the guidelines are called to Book H4.

In Québec, a contract that a platform offers a complementor on terms the complementor cannot negotiate is of the kind that the Civil Code of Québec, CQLR c CCQ-1991, read in LégisQuébec on October 15, 2026, up to date to August 12, 2026, calls a contract of adhesion, and whether a given contract is one is a question for a lawyer. Article 1379 defines a contract of adhesion as one whose essential stipulations were imposed or drawn up by one party and were not negotiable. Article 1435 provides that an external clause binds, but in a consumer contract or a contract of adhesion it is null if it was not expressly brought to the attention of the adhering party at formation, unless the other party proves that the adhering party otherwise knew of it. Article 1436 makes an illegible or incomprehensible clause in such a contract null if the adhering party suffers injury, unless the other party proves that an adequate explanation was given, and article 1437 makes an abusive clause null or allows the obligation to be reduced. These articles are read at their text, are never applied here to a real platform's clause, and are called to Book H1 (Contracts and Commercial Agreements) and to a lawyer.

The European Union's two regulations are rules of another jurisdiction, printed as what the Union requires of the services it covers and as a yardstick for reading a platform's terms, never as a right or a duty of a business in Québec or Canada. Regulation (EU) 2019/1150, read as published in the Official Journal through the Publications Office on October 15, 2026, applies to online intermediation services offered to business users established in the Union that offer goods or services to consumers in the Union; it requires terms in plain language, at least 15 days' notice of proposed changes, a statement of reasons for a restriction or a suspension, and at least 30 days' notice with reasons before a termination of the whole service, with stated exceptions. Regulation (EU) 2022/1925, read the same day, provides for designated gatekeepers, with an article 3(2)(a) threshold met in each of the last three financial years with the same core platform service provided in at least three Member States, and an article 5(3) that names third-party online intermediation services and the business user's own direct online sales channel. The first is called to Book H1 and a lawyer and the second to Book H4, each as a yardstick only.

The table below sets six provisions beside their jurisdiction and date, what each says in this book's words, and the book that holds it. Read it as a set of pointers rather than as a summary of the law: the provision is the text, and the text is where the rule lives.

Table 1.4 — The rules called to the books that hold them, with their provision and date

Whether a given agreement, a given clause or a given conduct complies with a rule, or is abusive, is a question for a lawyer or for the Tribunal, and this book never decides it. A question about personal information goes to Book H2 (Privacy and Personal Information), about intellectual property to Book H5 (Intellectual Property), and about security to Book K3 (Cybersecurity, Backups and Business Continuity).

QUÉBEC & CANADA NOTE Competition and contracts of adhesion are held by other books, and this book explains the law as published and is not legal advice

This book explains the law as published and is not legal advice. The Canadian point is competition: the Competition Act, ss. 75(1), 77(1), 78(1), 79(1), 79(3.1) and 103.1(1), current to September 21, 2026, read on October 15, 2026, with Book H4 called and with the two alternative paths of section 79(1) noted. The Québec point is the contract of adhesion: the Civil Code of Québec, arts. 1379 and 1435 to 1437, up to date to August 12, 2026, read on October 15, 2026, with Book H1 and a lawyer called. The two European regulations are another jurisdiction's rules and are printed as a yardstick only. This book recommends no vendor, no platform, no marketplace, no store, no integrator, no agency, no adviser, no product and no tool, and it refers a reader with a question about their own agreement to Books H4 and H1 and to a lawyer.

1.9 The Case and the Plan of This Book

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. The company designs and sells connected water-leak detectors for commercial and rental buildings, and it is the running case of this book. The case is counted in days and never in calendar years or months. This book opens on day 1, which is day 366 of Book G8 (Business Insurance and Risk Financing), the day after Book G8's one year later, day 731 of Book G7's count and day 1,096 of Book I8's count; day 365 of this book is entirely posed by this book and is told in Chapter 11.

Eight published books have already printed facts about the company, and this book cites them and never recounts them. Book A5 (Financing a Business) prints the company and its two founders, Laurence Bergeron, the president, product and engineering, and Karim Haddad, the head of sales and operations. Book A7 (Pricing Strategy and Revenue Models) prints the kit at $4,800 for a cost of $2,100 and the leak reported within minutes. Book L5 (Subscription and Recurring Revenue Models) prints a last base of 495 buildings and monthly prices of $89, $129 and $179. Book F9 (Building and Running a Partner Program) prints ten active partners and no hire, Book H5 (Intellectual Property) the firmware and the mobile application as assets, Book I8 (Freelancers, Agencies and Outsourcing) the testing rented under control, and Book G8 (Business Insurance and Risk Financing) the cellular gateway that can fail as a hazard and the largest customer with fourteen buildings. Books G8, I8 and L5 print that the company does not use La Machine.

Posed by this book, and said to be posed, are the figures this chapter uses. On day 1 the company monitors 820 buildings under subscription, split by the system in which the customer runs each building: 312 in the first property-management system, 148 in the second, and 360 in other systems or none. The table below sets six items of the case beside what each is and where it comes from, so that a reader can see at a glance which figures are printed by a published book and which are posed here.

Table 1.5 — The case on day 1: what eight books printed and what this book poses

The plan of this book runs ninety days in three slices, with gates on days 30, 60 and 90 and a gate that is not met read again 7 days later, with nothing new started until it passes; it takes 99 hours and engages $22,140, the ceiling of 40 percent on the share of new buildings that any single platform brings and the rule that no alert path runs through a platform are told in Chapter 6, and Chapter 11 tells the plan in full. The chapters that follow take the decision apart: Chapter 2 explains how platforms work, Chapter 3 chooses a dominant offer, Chapter 4 becomes a complementor, Chapter 5 opens the company's own interface, Chapter 6 measures and caps dependence, Chapter 7 designs the data and identity architecture of an integration, Chapter 8 sets the cadence, Chapter 9 names the roles, Chapter 10 gives the functions of the tools, and Chapter 11 gives the ninety-day plan and the pitfalls.

La Machine is introduced here once, and it is described rather than sold. In La Machine, as of the application copy of September 7, 2026, the page that touches this chapter is Control center → Tools (inventory) (/outils), an inventory of tools with a measured version and a date. It offers no documented public interface, no user-managed interface key, no webhook a user can configure, no single sign-on, no connector marketplace and no listing on another company's marketplace, and its partner pages serve the publisher's own programs; check it in your installation. The case does not use La Machine, and this book is valid with any tool.

The plan of the book closes on one sentence, and it is this book's own reasoning rather than a finding of any source. A business gains from a platform when it plugs into the systems its customers already run, reads the terms on the day it signs, opens its own interface small, signed and governed, keeps every critical path outside any platform, and measures its dependence against a ceiling it set in advance. Chapter 11 repeats the sentence at its close, and every chapter between works out one part of it.

CASE IN POINT Hydrosentinelle inc. opens its platform plan on day 1 with two founders and 820 buildings spread over three kinds of systems

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. The company opens this book on day 1, which is day 366 of Book G8. Laurence Bergeron, the president, product and engineering, and Karim Haddad, the head of sales and operations, are the two founders, and no hire is made in this book. The largest customer, a property management company with fourteen buildings, runs them in the first property-management system, posed by this book, and on day 1 the company monitors 820 buildings, posed by this book. No result of the business is credited to the plan, the integration, the listing or the interface, and every figure of the case is illustrative.

DO THE MATH From 820 buildings to a plan of $22,140: the case in numbers

Illustrative figures; the case is fictional. Step 1 — 312 plus 148 plus 360 buildings are 820 buildings on day 1, posed by this book. Step 2 — 312 of the 820 buildings is 38.0 percent, rounded to one decimal. Step 3 — the plan takes 42 hours of Karim Haddad, 52 hours of Laurence Bergeron and 5 hours of the outside lawyer, which are 99 hours. Step 4 — the hours are $2,520 and $3,120 at $60 an hour and $1,500 at $300 an hour, which are $7,140 at the illustrative rates Book F9 prints. Step 5 — with the developer's fixed fee of $12,000 and the first annual fee of $3,000, the plan engages $22,140; every count and every fee in these steps is posed by this book and illustrative, never a market price.

IN LA MACHINE La Machine lists tools with a measured version and offers no public interface, no connector marketplace and no listing on another company's marketplace

In the application copy read on October 15, 2026, La Machine offers no documented public interface, no interface key a user manages, no webhook a user configures, no single sign-on, no connector marketplace and no listing on another company's marketplace, and it holds no register of dependence on platforms and no watch of a platform's terms. What it does hold is Control center → Tools (inventory) (/outils), which lists tools with a version that is measured, a location and a date. That page can serve as a model for an inventory of the dominant offers a business depends on, and it measures no exposure, no revenue and no share of customers. A business should check it in its own installation. The case does not use La Machine, and La Machine is described and never sold.

Costly Mistakes

• Building for the loudest platform instead of the customers' systems. A connector built to the platform that is most discussed reaches the fewest customers, and the work is real while the reach is small.
• Treating an integration as a feature. A feature is built, tested and shipped by the people who own the product; an integration ties the service to terms, fees, review and removal that someone else controls, and it needs a decision by the people who own the business.
• Signing terms that nobody has read on the day of signing. Platform terms are drawn by the platform owner and may be amended by the owner, and a business that has not read them has accepted a change it cannot refuse.
• Reading an association as a cause. The abstract of a study reports what it found in its own sample over its own period, and a business that reads it as a promise has turned a correlation into a forecast.
• Letting a promise wait on a system the business does not control. The promise of a monitoring service is that the alert arrives, and a promise that waits on another company's system is a promise given away.
• Setting the dependence ceiling after the dependence exists. A ceiling chosen after the fact is a description rather than a limit.
• Asking one book a question that belongs to another. A listing and its fees are Book F5's, a partner program seen from the vendor is Book F9's, and a plug-in to a dominant offer is this book's.

Key Takeaways

• A platform is a system that other businesses build on or trade through and whose owner sets the terms of access, and a business that only buys a tool and uses it inside its own walls is not on a platform.
• An ecosystem is the platform and the businesses that build on it or trade through it, and a complementor is a business whose product works inside someone else's platform and gains from its reach.
• Integrating with a dominant offer is a decision with five questions, and each question is answered in a chapter of this book.
• The research on platforms and complementors is read at the level of its abstracts, with its sample and its period: an association is printed as an association, a model as a model, and no gain is promised to a reader.
• Dependence is the price of access, so the way to keep access without losing control is to decide where to depend, to measure it against a ceiling set in advance and to keep every critical path outside any platform.
• The rules that touch platforms are read at their text and called to the books that hold them, and this book explains the law as published and is not legal advice.

Your Action Plan

1. Draw the map of the systems your customers already run. List the systems, stores and standards in which your customers run their own work, and put beside each one the number of customers or buildings that use it. Deliverable: a written map of the dominant offers around your customers, with a count for each. Verification: every customer in your base appears in exactly one row, and the counts add to the base.
2. Write the five questions of the decision and answer each in one sentence. Which systems do the customers already run; on what terms does the platform admit a complementor; how far will you open your own interface; how much dependence is acceptable; and how will data and identity cross the integration. Deliverable: a one-page decision with five answers. Verification: each answer names the chapter of this book that will carry it, and no answer is left blank.
3. Store each platform's terms with the day you read them. Keep a copy of the terms, the fee page and the program page of each platform you depend on, with the date of the reading beside each copy. Deliverable: a folder of dated terms, one per platform. Verification: every platform on your map has a dated copy, and the oldest copy is less than a year old.
4. Write the dependence register and set the ceiling before you need it. For each platform, write what revenue, customers, data and operations are exposed, the notice its terms give and the way out; then set a ceiling on the share of new customers any single platform may bring. Deliverable: a register with a ceiling written at the top. Verification: every platform on your map has a row, every row has a way out, and the ceiling is a number rather than a phrase.
5. Keep every critical path outside any platform. List the paths your promise depends on — above all the alert — and confirm that each of them runs without a platform. Deliverable: a written list of critical paths with the route each one takes. Verification: no critical path names a platform, and the alert arrives by a route you control.

In La Machine

In the application copy read on October 15, 2026, the page that touches this chapter is Control center → Tools (inventory) (/outils), which lists tools with a version that is measured, a location and a date (La Machine, 2026). That page can serve as a model for an inventory of the dominant offers a business depends on, because it shows what is installed and when it was measured. It measures no exposure, no revenue and no share of customers. A business should check it in its own installation, and the case does not use La Machine.

What a business needs elsewhere is the rest of the work of this chapter. La Machine offers no documented public interface, no interface key a user manages, no webhook a user configures, no single sign-on, no connector marketplace and no listing on another company's marketplace, and it holds no register of dependence on platforms and no watch of a platform's terms. The map of the platforms around the customers, the stored terms with the day they were read, the calendar of dates and the dependence register live in a spreadsheet, a document store or a tool the business chooses by function, and this book is valid with any tool. La Machine is described and never sold, and the case does not use it.

Self-Check

1. What is a platform in this book's working words, and what is the difference between a business that buys a tool and a business that builds on a platform?
2. What is an ecosystem, and who sits between a platform and its end customer?
3. Why is integrating with a dominant offer a decision rather than a feature, and what are its five questions?
4. What does the research on platforms and complementors support, and how is an association printed?
5. What is dependence, and how does a business keep access without losing control?

Answers. 1. A platform is a system that other businesses build on or trade through and whose owner sets the terms of access; a business that buys a tool and uses it inside its own walls is not on a platform, and the difference is who sets the terms. 2. An ecosystem is the platform and the businesses that build on it or trade through it; between the platform and the end customer sit the complementors, the integrators, the resellers and advisers, and the customers who run it. 3. An integration looks like a feature on a screen and behaves like a decision in the business, because it ties the company's service to terms, fees, review and removal that someone else controls; its five questions are answered in Chapters 3, 4, 5, 6 and 7. 4. The research is read at the level of its abstracts, with its sample and its period: the abstract of the study of 1,210 small independent software vendors from 1996 to 2004 reports an association between joining a major platform owner's ecosystem and higher sales, never a cause (Ceccagnoli et al., 2012, abstract only), and a model is printed as a model, never as evidence. 5. Dependence is the degree to which the business's service, revenue or customers rest on terms that someone else sets, and a conceptual analysis read at its abstract reports that the power asymmetry between a platform and its ecosystem members is intrinsic to digital platforms (Cutolo & Kenney, 2021, abstract only); the way to keep access without losing control is to decide where to depend, to measure the dependence against a ceiling set in advance, and to keep every critical path outside any platform.

Chapter References

Adner, R. (2017). Ecosystem as structure: An actionable construct for strategy. Journal of Management, 43(1), 39–58. https://doi.org/10.1177/0149206316678451

Adner, R., & Kapoor, R. (2010). Value creation in innovation ecosystems: How the structure of technological interdependence affects firm performance in new technology generations. Strategic Management Journal, 31(3), 306–333. https://doi.org/10.1002/smj.821

Benzell, S. G., Hersh, J., & Van Alstyne, M. (2024). How APIs create growth by inverting the firm. Management Science, 70(10), 7120–7141. https://doi.org/10.1287/mnsc.2023.4968

Ceccagnoli, M., Forman, C., Huang, P., & Wu, D. J. (2012). Cocreation of value in a platform ecosystem: The case of enterprise software. MIS Quarterly, 36(1), 263–290. https://doi.org/10.2307/41410417

Civil Code of Québec, CQLR c CCQ-1991, arts. 1379, 1435, 1436 and 1437 (Québec). LégisQuébec, up to date to August 12, 2026 — read October 15, 2026. https://www.legisquebec.gouv.qc.ca/en/document/cs/CCQ-1991

Competition Act, R.S.C. 1985, c. C-34, ss. 75(1), 77(1), 78(1), 79(1) to (3.1) and 103.1(1) (Canada). Justice Laws Website, current to September 21, 2026 (last amended March 26, 2026) — read October 15, 2026. https://laws-lois.justice.gc.ca/eng/acts/C-34/

Competition Bureau. (2019). Abuse of dominance enforcement guidelines. Government of Canada. (Enforcement guidelines dated March 7, 2019; page modified June 27, 2024.) Retrieved October 15, 2026, from https://competition-bureau.canada.ca/en/how-we-foster-competition/education-and-outreach/abuse-dominance-enforcement-guidelines

Constantinides, P., Henfridsson, O., & Parker, G. G. (2018). Introduction—Platforms and infrastructures in the digital age. Information Systems Research, 29(2), 381–400. https://doi.org/10.1287/isre.2018.0794

Cutolo, D., & Kenney, M. (2021). Platform-dependent entrepreneurs: Power asymmetries, risks, and strategies in the platform economy. Academy of Management Perspectives, 35(4), 584–605. https://doi.org/10.5465/amp.2019.0103

European Commission. (n.d.). Gatekeepers Portal [Digital Markets Act]. Retrieved October 15, 2026, from https://digital-markets-act.ec.europa.eu/gatekeepers-portal_en

Gawer, A., & Cusumano, M. A. (2014). Industry platforms and ecosystem innovation. Journal of Product Innovation Management, 31(3), 417–433. https://doi.org/10.1111/jpim.12105

Jacobides, M. G., Cennamo, C., & Gawer, A. (2018). Towards a theory of ecosystems. Strategic Management Journal, 39(8), 2255–2276. https://doi.org/10.1002/smj.2904

Kretschmer, T., Leiponen, A., Schilling, M., & Vasudeva, G. (2022). Platform ecosystems as meta-organizations: Implications for platform strategies. Strategic Management Journal, 43(3), 405–424. https://doi.org/10.1002/smj.3250

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /outils.

McIntyre, D. P., & Srinivasan, A. (2017). Networks, platforms, and strategy: Emerging views and next steps. Strategic Management Journal, 38(1), 141–160. https://doi.org/10.1002/smj.2596

Regulation (EU) 2019/1150 of the European Parliament and of the Council of 20 June 2019 on promoting fairness and transparency for business users of online intermediation services, OJ L 186, 11.7.2019, p. 57, arts. 1, 3, 4, 8, 9 and 11 (European Union). Read October 15, 2026 through the Publications Office of the European Union (EUR-Lex answered 202 with an empty body). https://eur-lex.europa.eu/eli/reg/2019/1150/oj

Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act), OJ L 265, 12.10.2022, p. 1, arts. 3, 5 and 6 (European Union). Read October 15, 2026 through the Publications Office of the European Union. https://eur-lex.europa.eu/eli/reg/2022/1925/oj

Rietveld, J., & Schilling, M. A. (2021). Platform competition: A systematic and interdisciplinary review of the literature. Journal of Management, 47(6), 1528–1563. https://doi.org/10.1177/0149206320969791

Rochet, J.-C., & Tirole, J. (2003). Platform competition in two-sided markets. Journal of the European Economic Association, 1(4), 990–1029. https://doi.org/10.1162/154247603322493212

Rysman, M. (2009). The economics of two-sided markets. Journal of Economic Perspectives, 23(3), 125–143. https://doi.org/10.1257/jep.23.3.125

Statistics Canada. (2024, September 17). Survey of Digital Technology and Internet Use, 2023. The Daily. Retrieved October 15, 2026, from https://www150.statcan.gc.ca/n1/daily-quotidien/240917/dq240917c-eng.htm

Chapter 2 — How Platforms Work

A complementor that plugs into a platform rents an installed base whose rules someone else writes, so this chapter says how platforms work from the complementor's side — the two kinds of platform, the network effects that give a platform its value, the pricing across sides that decides who pays, openness as access against control, interfaces, kits and documents as the resources at the border, governance, tipping and multihoming, the entry of the platform owner into a complement's market, and the incentives to read before joining — reading each study at the level of its abstract and each model as a model, and drawing the map of the platforms around the customers of Hydrosentinelle inc. on day 1, posed by this book.

What You'll Be Able to Do

• Distinguish a platform one builds on from a platform one trades through, and say which kind a given customer relationship depends on.
• Explain direct and indirect network effects, and say what a complementor actually rents when it joins a platform.
• Read a model of pricing across sides for what it assumes, and refuse to deduce a real platform's fee from it.
• Tell access from control when a platform calls itself open, and find what the platform reserves in its own documents.
• Name the boundary resources a platform offers — its interfaces, kits and documents — and say who reads each one in a business of a given size.
• Ask the five questions that read a platform's incentives before joining it, and write the answer to each.

Why It Matters

A platform is not a channel and it is not a tool. It is a place where two or more groups meet, and the rules of that meeting are written by the platform owner, changed with notice and enforced by a review. A complementor that plugs into a platform receives something real: access to customers it did not have to gather, and a place inside a system those customers already run. What it gives up is control over the terms of that access, and the terms decide what the complementor may build, what it may charge, what it may keep and what happens when the owner changes its mind. Reading the terms is not a legal exercise; it is the ordinary work of knowing what one has bought.

The reason this chapter comes before the choice of a platform is that the choice cannot be made without the vocabulary. A business that cannot tell a platform it builds on from a platform it trades through will compare an app store with a property-management system as if they were the same kind of thing, and it will price its own work against the wrong risk. A business that cannot tell a direct network effect from an indirect one will read a platform's user count as a promise and miss the terms that decide whether the promise is worth anything. A business that cannot tell access from control will read the word "open" as a description of the whole platform and be surprised by a review that rejects its work.

The cost of not reading is paid later and in a currency that is hard to recover. A listing that is removed, a partner program that raises its fee, a platform owner that builds the complementor's feature into its own product: each of these is a decision taken by someone else, and the complementor's only preparation is to have read the incentives before joining and to have kept its critical paths outside the platform. This chapter gives the vocabulary and the questions; Chapter 3 chooses a dominant offer, Chapter 4 becomes a listed complementor, Chapter 5 opens the company's own interface, Chapter 6 measures dependence, and Chapter 7 designs the data and identity architecture of an integration.

In This Chapter

Section 2.1 draws the two kinds of platforms a complementor meets, building on and trading through, and sets this chapter beside its neighbors in a table of frontier. Section 2.2 reads direct and indirect network effects and says what a complementor rents. Section 2.3 reads four models of pricing across sides and refuses to deduce a real fee from any of them. Section 2.4 separates access from control in the word "open". Section 2.5 reads the interface, the kit and the document as boundary resources. Section 2.6 reads governance as rules, review and enforcement. Section 2.7 reads tipping, multihoming and why one platform rarely takes all. Section 2.8 reads five studies of the platform owner's entry into a complement's market. Section 2.9 gives the five questions that read a platform's incentives before joining it. Section 2.10 draws the map of the platforms around the customers of Hydrosentinelle inc. on day 1, posed by this book.

2.1 Two Kinds of Platforms: Building On and Trading Through

A platform is a place where two or more groups meet, and a complementor meets it in one of two postures: it builds on the platform, or it trades through it.

The distinction is worth drawing before anything else, because the two postures carry different costs, different terms and different ways of losing the customer. A platform one builds on is a system the complementor's product runs inside or exchanges data with: the core software a customer already runs, a device standard, an operating system. The complementor's product does not replace the platform; it extends it, and the customer keeps using the platform while the complementor's work happens inside it. A platform one trades through is a place that carries the complementor's offer to buyers: an app store, a marketplace, a business software marketplace. The complementor's product does not run inside the platform; the platform carries the offer, the listing, the transaction and often the payment. The two kinds overlap, and a single platform can be both at once: a business software ecosystem both carries a listing and offers an interface the complementor's product calls.

The literature read for this book draws a related line. The abstract of the paper by Gawer and Cusumano reports two predominant types of platforms, internal (company or product) platforms from which a company derives a stream of products, and external (industry) platforms on which an ecosystem of outside innovators builds complements, with general propositions on design, economics and management and practices of platform leadership (Gawer & Cusumano, 2014, abstract only). That is the authors' own summary of their paper, read here at its abstract only, and no measured effect is drawn from it. The distinction the abstract draws is between a platform a company keeps to itself and a platform on which outsiders build, and the complementor meets the second kind.

The other line the literature draws is the two-sided market. The abstract of the paper by Rysman reports that a two-sided market is one in which two sets of agents interact through a platform and the decisions of each affect the other, typically through an externality, positive or negative, and that the paper explains the strategies firms consider and the implications for antitrust and regulation (Rysman, 2009, abstract only). That is the author's own summary, read at its abstract only, and it is a description of a market structure and not a rule for a business.

This book's own words for the two kinds a complementor meets are these. A platform one builds on is a platform whose system the complementor's product runs inside or exchanges data with. A platform one trades through is a platform that carries the complementor's offer to buyers. The two kinds are not exclusive, and a business can meet both on the same day. Hydrosentinelle inc., the fictional company of this book, meets both on day 1, posed by this book: the first property-management system is a platform the company builds on, because the integration of Chapter 3 would have the alert event and the work order travel between the company's system and the customer's system, and the two dominant mobile app stores are platforms the company trades through, because they carry the mobile application to the buildings' managers. The company's customers are spread over more than one property-management system, and the map of that spread is drawn in section 2.10.

The multi-sided model itself — how a platform is launched, how it prices across sides and how a complementor can be disintermediated — is Book A1's (From Idea to Business Model, chapter 6), cited here and never redefined. This chapter develops the same model from the complementor's side, as Book A1 promised, and it holds the platform that a complementor builds on or trades through. Selling on a marketplace and in an app store, with their listings, ranking, fees and marketplace economics, is Book F5's (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces, chapters 2, 4, 5 and 7), and building a marketplace of one's own is chapter 8 of Book F5. Interfaces, webhooks, authentication and rate limits as integration concepts are Book K8's (No-Code, Low-Code and Integrations, chapter 2). Routes to market are Book F1's (Go-to-Market and Channel Strategy, chapter 3). The running of a platform business lies outside this book.

The table below sets this chapter beside its neighbors: for each book, what that book holds and what this chapter holds. Read it as a frontier and not as a ranking, and retain that this chapter never rewrites a definition a neighbor already printed.

Table 2.1 — Where this chapter stops and its neighbors begin

DEFINITION The words this book uses for a side, a network effect, multihoming, tipping and a boundary resource

These are this book's working words, and no source read defines them in this sense. A side is one of the groups of users that a platform brings together. A network effect is the rise or fall of a product's value to a user as other users join, direct when users value each other and indirect when one group values the size of another. Multihoming is the use of several platforms at once by a user or a complementor. Tipping is the movement of a market toward one platform. A boundary resource is an interface, a kit or a document through which a platform owner and a complementor meet. The multi-sided model itself is Book A1's (From Idea to Business Model, chapter 6) and is not redefined here.

2.2 Network Effects, Direct and Indirect

A network effect is the rise or fall of a product's value to a user as other users join, and the two forms of it explain why a platform is worth joining at all.

A direct effect is the one a user feels from other users of the same group. The abstract of the paper by Katz and Shapiro reports that in systems markets, where consumers use compatible components together, popular products are inherently more valuable, that these network effects drive strategies, and that the paper discusses consumer adoption with network effects, competition between incompatible systems, and how suppliers choose which components are compatible (Katz & Shapiro, 1994, abstract only). That is the authors' own summary of their paper, read at its abstract only, and it reports no measurement.

An indirect effect is the one a user feels from the size of a different group. The abstract of the paper by Caillaud and Jullien reports a model of imperfect price competition between intermediaries with indirect network externalities, the possibility of using several intermediaries at once and price discrimination, and that intermediaries have incentives to offer non-exclusive services, which moderates competition (Caillaud & Jullien, 2003, abstract only). That is a model, read at its abstract only, and it reports no empirical result; a model shows what follows from its assumptions.

The externality that each side exerts on the other is the definition recalled from section 2.1: a two-sided market is one in which two sets of agents interact through a platform and the decisions of each affect the other, typically through an externality, positive or negative (Rysman, 2009, abstract only).

The review read for this book places the two effects in a wider literature. The abstract of the paper by McIntyre and Srinivasan reports a review of industrial organization, technology management and strategy views of platform-mediated networks in which users and complementors seek compatibility on a common platform, with a research agenda on network effects against platform quality and on complementor dynamics (McIntyre & Srinivasan, 2017, abstract only). That is the authors' own summary of a review, read at its abstract only, and it reports no measured effect.

What a complementor takes from all of this is narrow and practical. The installed base of a platform — the users and the businesses already on it — is what the complementor comes for, and the indirect effect is the mechanism by which that base is worth something to a product the base has never seen. A complementor does not create the base; it rents access to it. And the rent is not free: the platform owner sets the terms of access, and those terms are the price of the rent. A complementor that sees the installed base and not the terms has read half the offer.

The case, posed by this book, is a small illustration of the same mechanism. Hydrosentinelle inc. sells connected water-leak detectors to commercial and rental buildings, and its customers already run a property-management system for the buildings they manage. On this book's reasoning, the company's alert event is more useful to a customer when it opens a work order in the system the customer already uses than when it arrives as an email the customer must copy by hand. The installed base the company rents is not the platform's users in general; it is the buildings whose managers already run the system. Book L5 (Subscription and Recurring Revenue Models) prints the last base of the company at 495 buildings, cited here and never recounted, and this book poses 820 buildings on day 1, a figure that appears in section 2.10.

KEY CONCEPT What a complementor rents from a platform is its installed base, and the rent is the platform's terms

This is this book's own reading of the section and never a finding of a source. The indirect effect is what draws the complementor: a product is worth more to a customer when it reaches the customers already gathered on a platform, and the gathering is the platform owner's work. What the complementor receives is access to that gathering, and access is granted on terms the owner writes. The terms decide what the complementor may do, what it may charge, what it may keep and what happens when the owner changes its mind. A complementor that reads the installed base and stops there has read half the offer, and the half it has not read is the half that decides whether the rent is worth paying. No figure of a source is printed here, and no gain is promised from joining any platform.

2.3 Pricing Across Sides: Who Pays and Who Is Subsidized

A platform with two sides must get both on board, and the price it charges each side is one of the levers it uses. Four models read for this book describe how that price can be allocated, and each of them is a model.

The abstract of the paper by Rochet and Tirole reports that many markets with network externalities are two-sided, that platforms must get both sides on board and court each side while making money overall, and that the paper models platform competition and the determinants of the price allocation between sides (Rochet & Tirole, 2003, abstract only). That is the authors' own summary of a model, read at its abstract only, and it gives no price for a real platform.

The abstract of the paper by Parker and Van Alstyne reports a formal model of two-sided network externalities showing that a firm can rationally invest in a product it gives away, that either content providers or end consumers can be the side that gets a free good, and that coupling products across markets can raise consumer welfare as it raises profits (Parker & Van Alstyne, 2005, abstract only). That is a model, read at its abstract only, and it does not say which side to subsidize in a given business.

The abstract of the paper by Armstrong reports three models — a monopoly platform, competing platforms where agents join one, and competitive bottlenecks where one group joins all platforms — and that prices depend on the size of the cross-group externalities, on lump-sum or per-transaction fees, and on whether agents join one or several platforms (Armstrong, 2006, abstract only). That is a model, read at its abstract only, and it reports no measurement.

The model of intermediaries recalled from section 2.2 is the fourth: imperfect price competition between intermediaries with indirect network externalities, the possibility of using several intermediaries at once and price discrimination, and the incentive to offer non-exclusive services, which moderates competition (Caillaud & Jullien, 2003, abstract only).

What the complementor takes from the four models is a question and not an answer. A platform may charge one side little or nothing and the other side more, and the complementor is sometimes the paying side and sometimes the subsidized one. Which side it is on is a fact about a given platform on a given day, and the fact is read on the platform's own page on the day it is read, never deduced from a model. Chapters 3, 4 and 6 read the terms of the platforms the case meets; this chapter reads no platform's terms.

The case, posed by this book, sits on two sides of two different platforms. On the property-management side, the company charges the building owner a subscription, and Book L5 (Subscription and Recurring Revenue Models) prints the monthly prices of $89, $129 or $179 on Essential, Plus or Portfolio, cited here and never recomputed. On the mobile side, the company's application is free on two dominant mobile app stores and nothing is sold inside it, so the stores' commissions on digital purchases do not apply to it as the pages read on October 15, 2026 describe those commissions, and a store's review decides. Chapter 3 reads the rules and the limits of the rules, and this chapter draws no conclusion about what the stores charge.

The table below sets the four models beside what each assumes, what its abstract reports and what it does not support. Read it as a statement of the limits of each model, and retain that none of the four gives a price, a fee or a side to subsidize for a real platform or for the case.

Table 2.2 — Four models of pricing across sides, at the level read

THE RULE A model shows what follows from its assumptions, never what a real platform charges (Rochet & Tirole, 2003)

The abstract of the paper by Rochet and Tirole reports a model of platform competition and of the determinants of the price allocation between sides, read at its abstract only (Rochet & Tirole, 2003). The rule this book applies is this: a model shows what follows from its assumptions, and it is never evidence of what a real platform charges. A real fee, a real commission or a real revenue share is read on the platform's own page on the day it is read, with the page and the date, and it is that platform's term on that day and never a market rate. No price of a real platform is printed in this chapter, and no side to subsidize is recommended to any reader. The same rule applies to the other three models of this section, and to every model cited in this book.

2.4 Openness: Granting Access Versus Giving Up Control

A platform that calls itself open is describing one dimension of itself, and the complementor needs to know which dimension.

Openness has at least two parts. The first is how much access the owner grants: what an outside developer may build, what it may read, what it may write and what it may charge. The second is how much control the owner gives up: what the owner reserves, what it reviews, what it may change and what it may remove. A platform can grant wide access and keep tight control, and a platform can grant narrow access and give up little. The two parts move independently, and a claim of openness may describe only the first.

The study read for this book is one industry and one period. The abstract of the paper by Boudreau reports that in 21 handheld computing systems from 1990 to 2004, granting greater access to independent hardware developers was associated with up to a fivefold acceleration in new device development, while giving up control of the platform itself added a positive effect an order of magnitude smaller (Boudreau, 2010, abstract only). That is the author's own summary of one study, read at its abstract only, and it is an association in one sample and one period, never a gain for a reader and never a law for another industry.

The construct read for this book is a measure of the complementor's own perception. The abstract of the paper by Benlian, Hilkert and Hess reports a multidimensional construct of perceived platform openness, from the application developers' perspective, validated in two smartphone platform contexts and linked to developers' continued contributions (Benlian et al., 2015, abstract only). That is the authors' own summary, read at its abstract only, and it gives no threshold of openness and no rule for a business.

What a complementor feels as openness is the range of what it may do without asking. A platform that lets a developer read a customer's data, write a record and receive an event without a review at each step feels open to that developer, whatever the owner's internal review looks like. A platform that requires a review before each new field feels closed, even when its documentation is generous. The feeling is a fact about the developer's work and not a fact about the platform's policy, and the two can differ.

The case, posed by this book, meets openness on day 1 in two places. The first property-management system offers an interface that a product can call, and the two dominant mobile app stores carry the company's application under their own review. Laurence Bergeron, the president, product and engineering, reads what each platform lets the company do and what each platform reserves. Karim Haddad, the head of sales and operations, reads the terms under which the access is granted. Neither reads a claim of openness as a promise about tomorrow.

WATCH OUT The word 'open' describes one dimension of a platform, and a study of 21 handheld systems is not a promise (Boudreau, 2010)

The trap is reading an owner's claim of openness, or the result of one study, as what a small firm may do tomorrow. The study read for this book reports that in 21 handheld computing systems from 1990 to 2004, granting greater access to independent hardware developers was associated with up to a fivefold acceleration in new device development, while giving up control of the platform itself added a positive effect an order of magnitude smaller (Boudreau, 2010, abstract only). That is one sample and one period, and it is an association and never a gain for a reader. The signs of the trap are a promotion that says 'open' without saying what stays closed, and a percentage taken from the study and applied to a business. The remedy is to read what the platform lets a complementor do and what it reserves, in the platform's own documents, and to print the sample with the result whenever the study is cited. The reasoning is this book's own.

2.5 Boundary Resources: Interfaces, Kits and Documentation

A boundary resource is an interface, a kit or a document through which a platform owner and a complementor meet, and it is the place where the terms of access become something a developer can hold.

The case study read for this book describes the two drivers at work in such a resource. The abstract of the paper by Ghazawneh and Henfridsson reports that boundary resources such as application programming interfaces are designed and used under two drivers, resourcing and securing, shown in a case study of one smartphone platform, and that the conflict is between keeping control of the platform and transferring design capability to third-party developers (Ghazawneh & Henfridsson, 2013, abstract only). That is the authors' own summary of one case study, read at its abstract only, and it reports no measured effect.

The two drivers are worth naming in this book's own words. Resourcing is what the resource gives the complementor: a way to read data, a way to write a record, a way to receive an event, a kit that shortens the build, a document that explains what the platform expects. Securing is what the resource gives the owner: a way to see who is calling, a way to limit what each caller may do, a way to change the rules and a way to withdraw access. Every boundary resource carries both, and a complementor that reads only the resourcing half has read the half that helps it build and not the half that decides what happens when the owner changes its mind.

The resources a complementor meets are of a few kinds. An interface is a documented way for one system to call another, and its description says what the calls are and what they return. A kit is a package of code, examples and tools that shortens the work of calling the interface. A document is the written rule: what the platform expects of a complementor, what it reviews, what it may change and what it may remove. Interfaces and webhooks as integration concepts are Book K8's (No-Code, Low-Code and Integrations, chapter 2), cited here and not rewritten; this chapter holds the interface as a boundary resource of a platform and not as a technique of integration.

Chapter 5 turns the same idea around. When the company opens its own interface, it becomes the owner of a boundary resource, and the two drivers apply to the company: what it gives an integrator to build with, and what it keeps to itself. The design of that interface, its terms of use and its governance are Chapter 5's, and this chapter only names the shape.

The case, posed by this book, meets three boundary resources on day 1. The first property-management system offers an interface and a document; the two dominant mobile app stores offer a kit, a review process and a written set of guidelines. Laurence Bergeron reads the interfaces and the documents, and Karim Haddad reads the rules. This chapter builds nothing, and the first integration is built in Chapter 3.

WHO DOES THIS One person reads the interface and another reads the terms, and in the smallest business they are the same person

Who reads the border of a platform depends on the size of the business. A solo owner reads both the interface and the rules, because there is no one else to read either. In a small team, a developer reads the interface and the owner reads the rules, so that the person who builds is not the only person who has read what the platform reserves. In an established business, a partnerships manager and a product lead split the two, and Chapter 9 reads the roles behind platform work. In the case, posed by this book, Laurence Bergeron, the president, product and engineering, reads the interfaces and Karim Haddad, the head of sales and operations, reads the rules, with no hire and no dollar added to the plan.

2.6 Governance: Rules, Review and Enforcement

Governance is the set of rules a platform writes, the review that checks a complementor against them and the enforcement that follows, and a complementor meets it as a contract of the day.

The first reading for this book describes the platform as a kind of organization. The abstract of the paper by Kretschmer, Leiponen, Schilling and Vasudeva reports that platforms are conceptualized as meta-organizations, less formal and hierarchical than firms but more closely coupled than markets, bound by design rules and an overarching value proposition, and that they need coordination among participants whose interests are not all aligned, through sources of authority, incentives and governance (Kretschmer et al., 2022, abstract only). That is the authors' own summary of a conceptual paper, read at its abstract only, and it reports no measured effect.

The second reading describes the roles that hold an ecosystem together. The abstract of the paper by Jacobides, Cennamo and Gawer reports that modularity enables ecosystems, sets of interdependent organizations that coordinate without full hierarchical fiat through roles that face similar rules, bound by the non-redeployability of their collective investment, and that complementarities may be unique or supermodular, generic or specific, one- or two-directional (Jacobides et al., 2018, abstract only). That is the authors' own summary, read at its abstract only, and it reports no measured effect.

The third reading places governance in a moving system. The abstract of the research commentary by Tiwana, Konsynski and Bush reports that software-based platforms shift competition toward ecosystems, and that the coevolution of their design, governance and environmental dynamics shapes how they evolve, with five research questions set out (Tiwana et al., 2010, abstract only). That is the authors' own summary of a commentary, read at its abstract only, and it reports no finding.

What a complementor meets as governance is concrete. It meets a set of written rules: what it may build, what it may read, what it may charge, what it may say about the platform. It meets a review: a submission, a checklist, a decision, sometimes a rejection and a resubmission. It meets enforcement: a warning, a suspension, a removal, a change of terms with a notice period. The rules are a contract of the day, and the day is the day they were read. Chapters 4 and 6 read the terms of the platforms the case meets, and this chapter reads no platform's terms.

The case, posed by this book, meets governance on day 1 in the two app stores' review processes and in the first property-management system's partner program. The company's application is free on the stores and nothing is sold inside it, so the stores' commissions on digital purchases do not apply to it as the pages read on October 15, 2026 describe those commissions; the review still applies, and a rejection is still possible. Chapter 3 reads the rules and their limits, and Chapter 4 reads the partner program.

QUÉBEC & CANADA NOTE Platform terms are read in Québec through the books that hold the law, and this chapter rewrites none of it

In Québec and Canada, the terms a platform imposes are read through the books that hold the law. Contracts and contracts of adhesion are Book H1's (Contracts and Commercial Agreements), and this book reads them in sections 4.2 and 6.2. Competition law is Book H4's (Consumer Protection, Advertising Law, Competition and Language Requirements), read in section 6.9. Personal information is Book H2's (Privacy and Personal Information), read in section 7.7. This chapter reads no text of law and rewrites none: it describes how a platform's governance reaches a complementor and leaves the reading of any clause to the book that holds it and to a lawyer. Whether a given term of a given platform is enforceable, whether a platform abuses a dominant position or whether a clause is abusive is for a court or the Tribunal, never for this book. This book recommends no vendor, no platform, no marketplace, no store, no integrator, no agency, no adviser, no product and no tool.

TOOLS OF THE TRADE What a business needs to follow a platform's governance: stored terms, a calendar, a decision note and a register

Four functions carry the work, and a business should look for them rather than for a product. The first is a stored copy of each platform's terms with the day it was read, so that a change can be seen against what was read before. The second is a calendar of the dates when a review or a term is due, so that a renewal, a certification or a notice period is not missed. The third is a note of who decided what and on which reading, so that a decision can be read again without the person who took it. The fourth is one register where each platform is written with its way out, so that the business knows what it would do if the platform changed its terms or removed the listing. Chapter 10 gives the functions in full, and no brand name and no price belongs on this list.

2.7 Tipping, Multihoming and Why One Platform Rarely Takes All

Tipping is the movement of a market toward one platform, and multihoming is the use of several platforms at once; the two forces work against each other, and the complementor lives in the space between them.

The direct effect recalled from section 2.2 is the mechanism behind tipping. The abstract of the paper by Katz and Shapiro reports that in systems markets, where consumers use compatible components together, popular products are inherently more valuable, and that these network effects drive strategies (Katz & Shapiro, 1994, abstract only). A market in which the popular product is inherently more valuable is a market that can move toward one product, and the movement is what the word tipping names.

The model recalled from section 2.2 is the mechanism behind multihoming. The abstract of the paper by Caillaud and Jullien reports a model of imperfect price competition between intermediaries with indirect network externalities, the possibility of using several intermediaries at once and price discrimination, and that intermediaries have incentives to offer non-exclusive services, which moderates competition (Caillaud & Jullien, 2003, abstract only). That is a model, read at its abstract only, and the possibility of using several intermediaries at once is what keeps a market from tipping all the way.

The model recalled from section 2.3 describes the case in which one group joins all platforms. The abstract of the paper by Armstrong reports three models, among them competitive bottlenecks where one group joins all platforms, and that prices depend on the size of the cross-group externalities, on lump-sum or per-transaction fees, and on whether agents join one or several platforms (Armstrong, 2006, abstract only). That is a model, read at its abstract only, and it reports no measurement.

The review read for this book places the two forces in a wider literature. The abstract of the paper by Rietveld and Schilling reports a systematic review of 333 articles published from 1985 to 2019 on platform competition, with four themes: winner-takes-all dynamics from network effects, corporate decisions such as vertical integration, heterogeneity of platforms and users, and how the platform hub orchestrates value creation and capture (Rietveld & Schilling, 2021, abstract only). That is the authors' own summary of a review, read at its abstract only, and it gives no rule for a complementor.

The two studies read for this book are each one industry. The abstract of the paper by Cennamo and Santalo reports that in the United States video game industry, pursuing two winner-take-all strategies at once and with equal intensity — more applications and more exclusive ones — lowered platform performance, and that a differentiation strategy helped only for highly distinctive platforms (Cennamo & Santalo, 2013, abstract only). That is the authors' own summary of one study, read at its abstract only, and it applies to no other industry. The abstract of the paper by Cennamo, Ozalp and Kretschmer reports that in the United States video game industry, games released on several platforms had lower quality on the technologically more complex console, and that games released first on one platform performed worse on the platforms they were later ported to (Cennamo et al., 2018, abstract only). That is the authors' own summary of one study, read at its abstract only, and it applies to no other industry.

What a complementor takes from all of this is a posture and not a rule. Tipping is a possibility, not a certainty, and multihoming is what a complementor does when its customers are spread. A complementor may multihome because its customers are spread over several systems, and the cost of multihoming falls on quality and on effort: two integrations to build, two sets of terms to read, two reviews to pass and two versions to keep. Chapter 6 reads the cost of dependence and the ceiling a business sets for itself.

The case, posed by this book, is a multihoming business by the shape of its market. Its customers run their buildings in two property-management systems and in other systems or none, so no single platform covers the base. The company builds on the first system in Chapter 3, queues the second and leaves the smart-home standard for later, and the map of the spread is drawn in section 2.10.

The table below sets four readings beside their setting, what each abstract reports and what each does not support. Read it as a statement of the limits of each reading, and retain that no reading of this section gives a rule for a complementor or a forecast for a market.

Table 2.3 — Tipping and multihoming: four readings, each in its setting

2.8 When the Platform Owner Enters a Complement's Market

A platform owner can enter the market of its own complementors, and the studies read for this book show that the effect on a complementor depends on the setting. Each study is one platform and one period, and the directions differ.

The first study is one chip maker. The abstract of the paper by Gawer and Henderson reports that one platform owner's entry decisions were shaped by its belief that it could not enter all markets, so it had to encourage entry despite entrants' fear of being squeezed, and that it used organizational structure and processes as commitment mechanisms (Gawer & Henderson, 2007, abstract only). That is the authors' own summary of one study, read at its abstract only, and it applies to no other firm.

The second study is one retail marketplace. The abstract of the paper by Zhu and Liu reports that on one retail marketplace, the platform owner was more likely to enter successful product spaces and less likely to enter those that require greater seller effort, that entry discouraged affected sellers from pursuing growth on the platform, and that it raised demand and lowered shipping costs for consumers (Zhu & Liu, 2018, abstract only). That is the authors' own summary of one study, read at its abstract only, and it applies to no other platform.

The third study is one mobile platform. The abstract of the paper by Wen and Zhu reports that on one mobile platform, after the threat of the owner's entry increased, affected developers reduced innovation and raised prices on affected apps and shifted innovation to unaffected and new apps, and that the welfare effect is ambiguous (Wen & Zhu, 2019, abstract only). That is the authors' own summary of one study, read at its abstract only, and it applies to no other platform.

The fourth study is one photography category on one mobile platform. The abstract of the paper by Foerderer, Kude, Mithas and Heinzl reports that on a panel of 6,620 apps, one platform owner's entry into photography apps on its own mobile platform was associated with an increase in complementary innovation, a 9.6 percent higher likelihood of major updates for affected apps, through increased consumer attention, more so for larger and more diversified complementors (Foerderer et al., 2018, abstract only). That is the authors' own summary of one study, read at its abstract only, and it applies to no other category.

The survey read for this book places the four studies side by side. The abstract of the paper by Zhu reports a survey of empirical studies of platform owners' direct entry into complementors' product spaces, and finds that the motivation goes beyond value capture and that the impact on complementors varies across settings (Zhu, 2019, abstract only). That is the author's own summary of a survey, read at its abstract only, and it gives no single direction of effect.

What a complementor takes from all of this is a way of reading its own position and not a forecast. The owner's entry is a possibility, and the studies show that the effect depends on the setting: on the platform, on the category, on the complementor's size and on what the owner already sells. A complementor that reads the studies as a warning about its own platform has read them as a forecast, and the survey says the direction varies. What a complementor can do is read the owner's incentives before joining, which is section 2.9, and measure its own exposure, which is Chapter 6.

The case, posed by this book, meets the question in the first property-management system. The system's owner could build a leak-detection feature of its own, and the company's answer is not a legal one: it is to keep the alert path outside the platform, so that a customer's alert never depends on the platform's decision, and to keep the customer relationship in the company's own hands. The alert path is described in section 2.10.

The table below sets the five readings beside their setting, what each abstract reports and what each does not support. Read it as a statement of the limits of each reading, and retain that the directions differ by setting and that no reading is a forecast for the case.

Table 2.4 — The owner's entry into a complement's market: five readings, each in its setting

WHAT CHANGED The studies of the owner's entry in 2018 and 2019 point in different directions by setting (Zhu, 2019)

The dated change comes from the survey read at its abstract only on October 15, 2026: a survey of empirical studies of platform owners' direct entry into complementors' product spaces finds that the motivation goes beyond value capture and that the impact on complementors varies across settings (Zhu, 2019, abstract only). The change is in the question, not in a figure. The earlier question was whether the owner crowds out its complements, and the survey's answer is that the direction depends on the setting: one retail marketplace discouraged affected sellers from pursuing growth (Zhu & Liu, 2018, abstract only), one mobile platform saw developers reduce innovation and raise prices on affected apps (Wen & Zhu, 2019, abstract only), and one photography category saw a 9.6 percent higher likelihood of major updates for affected apps (Foerderer et al., 2018, abstract only). Each study is one platform and one period, and the survey gives no single direction of effect. No other date is printed, and no figure beyond the survey is printed here.

2.9 Reading a Platform's Incentives Before Joining It

Before a complementor joins a platform, it can read the owner's incentives, and the reading is a set of questions rather than a judgment about the owner's character.

The study read for this book describes what a complementor faces over time. The abstract of the paper by Kapoor and Agarwal reports that in two smartphone ecosystems, higher ecosystem complexity helped app developers sustain superior performance, more so for experienced firms, while generational transitions initiated by the platform owners made it harder (Kapoor & Agarwal, 2017, abstract only). That is the authors' own summary of one study, read at its abstract only, and it applies to no business-software setting.

The two studies recalled from section 2.8 describe the owner's own interests. The abstract of the paper by Gawer and Henderson reports that one platform owner's entry decisions were shaped by its belief that it could not enter all markets, so it had to encourage entry despite entrants' fear of being squeezed (Gawer & Henderson, 2007, abstract only). The abstract of the paper by Zhu and Liu reports that on one retail marketplace, the owner was more likely to enter successful product spaces and less likely to enter those that require greater seller effort (Zhu & Liu, 2018, abstract only). Both are one setting each, read at their abstracts only.

What a complementor asks before it joins is a short list. How does the owner earn from the platform, and from the complementor in particular? What could the owner build itself, and what does it already sell that competes with the complementor's product? How has the owner changed its terms in the past, and with what notice? Who else sits in the ecosystem and does the same work? And what would the complementor do if the platform moved to a new generation of its system, as the two smartphone ecosystems did?

The answers are read in the platform's own documents: its terms, its fee pages, its partner program, its change log and its announcements. They are read on the day they are read, and they are that platform's terms on that day. Chapters 3, 4 and 6 read the terms of the platforms the case meets, and this chapter reads no platform's terms.

The case, posed by this book, asks the five questions about the first property-management system before it builds the first integration, and writes the five answers down before the build, which is Chapter 3. Whatever those answers are, one thing is fixed by design: if the owner moved to a new generation of its system, the company's alert path would still run by text message and email, so the customer's alert would not depend on the platform.

METHOD Reading a platform's incentives before joining it in five steps

First, write down how the owner earns from the platform, and from the complementor in particular. Second, list what the owner could build itself and what it already sells that competes with the complementor's product. Third, read how the owner has changed its terms in the past and with what notice, from its own documents and its own change log. Fourth, list the other complementors that do the same work, so that the complementor knows who else is in the room. Fifth, write what the company would do if the platform moved to a new generation of its system, as the two smartphone ecosystems of the study did (Kapoor & Agarwal, 2017, abstract only). The sequence is this book's own, no source tests it, and it is a set of questions and not a judgment about any platform. No figure is printed here, and no platform is named.

2.10 The Case's Map of the Platforms Around Its Customers

On day 1, Hydrosentinelle inc. monitors 820 buildings under subscription, a figure posed by this book; Book L5 (Subscription and Recurring Revenue Models) prints a last base of 495 buildings, cited here and never recounted. The map of the platforms around those customers is drawn by Karim Haddad, the head of sales and operations, and the technical side is checked by Laurence Bergeron, the president, product and engineering. No hour and no dollar are given to the map in this chapter.

The map has three parts. The first is where the customers run the buildings: the first property-management system, the second property-management system, and other systems or none. The second is where the mobile application lives: two dominant mobile app stores, with nothing sold inside the application. The third is where an alert goes: by text message and by email directly, through no platform at all.

The split of the base by system is posed by this book and illustrative. The first property-management system holds 312 buildings, which is 38.0 percent of the base, and the 14 buildings of the largest customer (a property management company with fourteen buildings, Book G8) are inside that group. The second property-management system holds 148 buildings, which is 18.0 percent. Other systems or none hold 360 buildings, which is 43.9 percent. The three shares are posed by this book and rounded to one decimal, so that they sum to 100 percent within that rounding.

The mobile application is free on the two dominant mobile app stores, and nothing is sold inside it: the subscription is invoiced to the building owner, so the stores' commissions on digital purchases do not apply to it as the pages read on October 15, 2026 describe those commissions, and a store's review decides. Chapter 3 reads the rules and the limits of the rules, and this chapter draws no conclusion about what the stores charge.

The alert path never runs through a platform. An alert goes by text message and by email directly, and the application and the work order are conveniences that may fail without silencing an alert. That is the company's own design choice, posed by this book. The work order in the first property-management system is a convenience; the alert is not.

Figure 2.1 maps the platforms around the case's customers on day 1: where the customers run the buildings, where the mobile application lives, and where an alert goes.

Figure 2.1 — Day 1. Of 820 buildings, 312 sit in one property-management system, 148 in a second and 360 elsewhere; the alert path runs through no platform (posed).

The table below gives the same split as a table, with the buildings and the share of the base. Read it as the map that decides which dominant offer matters to the customers, and retain that no single platform covers the base.

Table 2.5 — The case on day 1: where the customers run the buildings, posed by this book

In La Machine, as of the application copy of September 7, 2026, the pages that touch this chapter are Products → For Partner Websites (/products/partners), a public page that announces a REST interface, components, single sign-on, isolation, a dashboard and webhooks although none of them has a screen in the copy read, and Offers → Marketplace (client/marketplace), a demonstration of a buying experience. It offers no documented public interface, no user-managed interface key, no webhook a user can configure, no single sign-on, no connector marketplace and no listing on another company's marketplace; check it in your installation (La Machine, 2026). Every fact holds in the application copy of September 7, 2026, read in its code on October 15, 2026. The case does not use La Machine; this book is valid with any tool; La Machine is described and never sold.

CASE IN POINT Hydrosentinelle inc. maps the platforms around its 820 buildings on day 1 and finds that its alerts run through none of them

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. On day 1 the company monitors 820 buildings under subscription, posed by this book. The first property-management system holds 312 buildings, the second holds 148, and other systems or none hold 360. The mobile application is free on two dominant mobile app stores and nothing is sold inside it, so the stores' commissions on digital purchases do not apply to it as the pages read on October 15, 2026 describe those commissions. The alert path runs through no platform: an alert goes by text message and by email directly, and the application and the work order are conveniences that may fail without silencing an alert. Karim Haddad, the head of sales and operations, draws the map, and Laurence Bergeron, the president, product and engineering, checks the technical side. No result is credited to the map, and no sale, no customer and no growth is credited to any platform.

DO THE MATH Three groups of buildings, one share each: the map of day 1 in numbers

Illustrative figures; the case is fictional. Step 1 — 312 plus 148 plus 360 buildings are 820 buildings on day 1, posed by this book, while the last base printed by Book L5 is 495 buildings, cited and never recounted. Step 2 — 312 of 820 buildings is 38.0 percent, posed by this book. Step 3 — 148 of 820 is 18.0 percent, posed by this book. Step 4 — 360 of 820 is 43.9 percent, the shares posed by this book and rounded to one decimal so that they sum to 100 percent within that rounding. Step 5 — the 14 buildings of the largest customer, a property management company with fourteen buildings (Book G8), are inside the first group, and every count is posed by this book and illustrative, never a measured result.

IN LA MACHINE La Machine announces partner-site features that have no screen, and its marketplace is a demonstration

In the application copy read on October 15, 2026, the public page Products → For Partner Websites (/products/partners) announces a REST interface, components, single sign-on, isolation, a dashboard and webhooks, and none of them has a screen in the copy read; the gap between the announcement and the copy read is stated here as a gap, with no figure and without blaming anyone. Offers → Marketplace (client/marketplace) is a demonstration of a buying experience, with a seeded catalog and a simulated payment; it is never a marketplace in operation and never a catalog of integrations, and Book F5 (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces) holds marketplaces. Check it in your installation. The case does not use La Machine, and La Machine is described and never sold.

Costly Mistakes

• Reading a platform's installed base and stopping there. The base is what the complementor comes for, and the terms are the price of the rent; a complementor that has read only the base has read half the offer.
• Deducing a real platform's fee from a model. A model shows what follows from its assumptions, and a real fee is read on the platform's own page on the day it is read.
• Treating the word 'open' as a description of the whole platform. Openness has at least two parts, access and control, and a claim of openness may describe only the first.
• Reading one study of one platform as a law for another. Each study read for this book is one platform and one period, and the entry studies point in different directions by setting.
• Reading the interface and never the terms. The interface is the resourcing half of a boundary resource, and the terms are the securing half; a business that reads only the first has not read what the platform reserves.
• Assuming that a free application means the platform's rules do not apply. A free application on a store still passes the store's review, and the review can reject it.
• Putting a platform between an event and its warning. The case keeps every alert outside every platform, because a platform that decides whether a warning leaves can also silence it; the alert goes by text message and email directly, and the work order and the application are conveniences that may fail without silencing an alert.

Key Takeaways

• A platform is a place where two or more groups meet, and a complementor meets it in one of two postures: it builds on the platform, or it trades through it.
• A direct network effect makes a product more valuable to a user as other users join, and an indirect effect makes one group value the size of another; what a complementor rents is the platform's installed base, and the rent is the platform's terms.
• A platform may charge one side little or nothing and the other side more, and the complementor is sometimes the paying side and sometimes the subsidized one; a real fee is read on the platform's own page on the day it is read, never deduced from a model.
• Openness has at least two parts, how much access the owner grants and how much control it gives up, and a complementor feels openness as the range of what it may do without asking.
• A boundary resource is an interface, a kit or a document through which a platform owner and a complementor meet, and each resource both gives the complementor something to build with and lets the owner keep control.
• Governance is the rules a platform writes, the review that checks a complementor against them and the enforcement that follows; a complementor meets it as a contract of the day, and the day is the day the terms were read.

Your Action Plan

1. Draw the map of the platforms around your customers. Write, for each customer group, which system the customer already runs, which store carries your application and where an alert goes. Deliverable: a one-page map with the buildings or accounts in each group. Verification: every customer group appears in the map, and the alert path is written as running through no platform.
2. Write down what you rent and what you pay for it. For each platform on the map, write the installed base it gives you access to and the terms under which the access is granted, with the day you read them. Deliverable: a one-line entry per platform. Verification: every entry names the base, the terms and the day read.
3. Read the border of each platform in two passes. Read the interface and the documents in one pass, and the rules, the review and the enforcement in another. Deliverable: a note per platform with what it lets you do and what it reserves. Verification: the note names at least one thing the platform reserves, and a second person has read it.
4. Ask the five questions of a platform's incentives before you build. Write the answers to how the owner earns, what it could build itself, how it has changed its terms, who else is in the ecosystem and what you would do if the platform moved to a new generation. Deliverable: a written answer to each of the five questions. Verification: each answer cites a document of the platform, with the day read.
5. Keep the alert path outside every platform. Write, for each alert your product sends, the path it takes and the platform it depends on, if any. Deliverable: a written alert path per alert type. Verification: no alert path names a platform as a required step.

In La Machine

In the application copy read on October 15, 2026, the pages that touch this chapter are Products → For Partner Websites (/products/partners), a public page that announces a REST interface, components, single sign-on, isolation, a dashboard and webhooks, and Offers → Marketplace (client/marketplace), a demonstration of a buying experience with a seeded catalog and a simulated payment (La Machine, 2026). The first is an announcement without a screen in the copy read, and the second is a demonstration and never a marketplace in operation. Both are described here as the copy shows them, with no figure and without blaming anyone, and a business should check it in its own installation.

What a business needs for the work of this chapter lives elsewhere. La Machine offers no documented public interface, no interface key a user manages, no webhook a user configures, no single sign-on, no provisioning of users between systems, no connector marketplace and no listing on another company's marketplace, so it holds no register of the platforms a business depends on, no stored copy of a platform's terms with the day read, no calendar of the dates when a review or a term is due and no measure of exposure to a platform. Those live in a spreadsheet, a document store or a tool the business chooses by function, and this book is valid with any tool. The case does not use La Machine, and La Machine is described and never sold.

Self-Check

1. What are the two kinds of platforms a complementor meets, and how do they differ in what the complementor's product does?
2. What is the difference between a direct and an indirect network effect, and what does a complementor rent from a platform?
3. Why is a model of pricing across sides never evidence of what a real platform charges?
4. What are the two parts of openness, and what does a complementor feel as openness?
5. What is a boundary resource, and what are the two drivers at work in one?

Answers. 1. A platform one builds on is a system the complementor's product runs inside or exchanges data with, so the product extends the platform and the customer keeps using it; a platform one trades through carries the complementor's offer to buyers, so the platform carries the listing, the transaction and often the payment, and the product does not run inside it. The two kinds overlap, and a business can meet both on the same day, as Hydrosentinelle inc. does on day 1, posed by this book. 2. A direct effect is the one a user feels from other users of the same group, and an indirect effect is the one a user feels from the size of a different group; what a complementor rents is the platform's installed base, and the rent is the platform's terms, which the owner writes and may change with notice. 3. A model shows what follows from its assumptions, and the four models read for this book — Rochet and Tirole, Parker and Van Alstyne, Armstrong, and Caillaud and Jullien — each report a model at its abstract only and none gives a price for a real platform; a real fee is read on the platform's own page on the day it is read, with the page and the date. 4. Openness has at least two parts, how much access the owner grants and how much control it gives up, and a complementor feels openness as the range of what it may do without asking, which is a fact about the developer's work and not a fact about the platform's policy. 5. A boundary resource is an interface, a kit or a document through which a platform owner and a complementor meet, and the two drivers at work in one are resourcing, what the resource gives the complementor to build with, and securing, what the resource gives the owner to keep control; the reading is the abstract of one case study of one smartphone platform, read at its abstract only (Ghazawneh & Henfridsson, 2013, abstract only).

Chapter References

Armstrong, M. (2006). Competition in two-sided markets. The RAND Journal of Economics, 37(3), 668–691. https://doi.org/10.1111/j.1756-2171.2006.tb00037.x

Benlian, A., Hilkert, D., & Hess, T. (2015). How open is this platform? The meaning and measurement of platform openness from the complementers' perspective. Journal of Information Technology, 30(3), 209–228. https://doi.org/10.1057/jit.2015.6

Boudreau, K. (2010). Open platform strategies and innovation: Granting access vs. devolving control. Management Science, 56(10), 1849–1872. https://doi.org/10.1287/mnsc.1100.1215

Caillaud, B., & Jullien, B. (2003). Chicken & egg: Competition among intermediation service providers. The RAND Journal of Economics, 34(2), 309–328. https://doi.org/10.2307/1593720

Cennamo, C., & Santalo, J. (2013). Platform competition: Strategic trade-offs in platform markets. Strategic Management Journal, 34(11), 1331–1350. https://doi.org/10.1002/smj.2066

Cennamo, C., Ozalp, H., & Kretschmer, T. (2018). Platform architecture and quality trade-offs of multihoming complements. Information Systems Research, 29(2), 461–478. https://doi.org/10.1287/isre.2018.0779

Foerderer, J., Kude, T., Mithas, S., & Heinzl, A. (2018). Does platform owner's entry crowd out innovation? Evidence from Google Photos. Information Systems Research, 29(2), 444–460. https://doi.org/10.1287/isre.2018.0787

Gawer, A., & Cusumano, M. A. (2014). Industry platforms and ecosystem innovation. Journal of Product Innovation Management, 31(3), 417–433. https://doi.org/10.1111/jpim.12105

Gawer, A., & Henderson, R. (2007). Platform owner entry and innovation in complementary markets: Evidence from Intel. Journal of Economics & Management Strategy, 16(1), 1–34. https://doi.org/10.1111/j.1530-9134.2007.00130.x

Ghazawneh, A., & Henfridsson, O. (2013). Balancing platform control and external contribution in third-party development: The boundary resources model. Information Systems Journal, 23(2), 173–192. https://doi.org/10.1111/j.1365-2575.2012.00406.x

Jacobides, M. G., Cennamo, C., & Gawer, A. (2018). Towards a theory of ecosystems. Strategic Management Journal, 39(8), 2255–2276. https://doi.org/10.1002/smj.2904

Kapoor, R., & Agarwal, S. (2017). Sustaining superior performance in business ecosystems: Evidence from application software developers in the iOS and Android smartphone ecosystems. Organization Science, 28(3), 531–551. https://doi.org/10.1287/orsc.2017.1122

Katz, M. L., & Shapiro, C. (1994). Systems competition and network effects. Journal of Economic Perspectives, 8(2), 93–115. https://doi.org/10.1257/jep.8.2.93

Kretschmer, T., Leiponen, A., Schilling, M., & Vasudeva, G. (2022). Platform ecosystems as meta-organizations: Implications for platform strategies. Strategic Management Journal, 43(3), 405–424. https://doi.org/10.1002/smj.3250

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /products/partners and client/marketplace.

McIntyre, D. P., & Srinivasan, A. (2017). Networks, platforms, and strategy: Emerging views and next steps. Strategic Management Journal, 38(1), 141–160. https://doi.org/10.1002/smj.2596

Parker, G. G., & Van Alstyne, M. W. (2005). Two-sided network effects: A theory of information product design. Management Science, 51(10), 1494–1504. https://doi.org/10.1287/mnsc.1050.0400

Rietveld, J., & Schilling, M. A. (2021). Platform competition: A systematic and interdisciplinary review of the literature. Journal of Management, 47(6), 1528–1563. https://doi.org/10.1177/0149206320969791

Rochet, J.-C., & Tirole, J. (2003). Platform competition in two-sided markets. Journal of the European Economic Association, 1(4), 990–1029. https://doi.org/10.1162/154247603322493212

Rysman, M. (2009). The economics of two-sided markets. Journal of Economic Perspectives, 23(3), 125–143. https://doi.org/10.1257/jep.23.3.125

Tiwana, A., Konsynski, B., & Bush, A. A. (2010). Research commentary—Platform evolution: Coevolution of platform architecture, governance, and environmental dynamics. Information Systems Research, 21(4), 675–687. https://doi.org/10.1287/isre.1100.0323

Wen, W., & Zhu, F. (2019). Threat of platform-owner entry and complementor responses: Evidence from the mobile app market. Strategic Management Journal, 40(9), 1336–1367. https://doi.org/10.1002/smj.3031

Zhu, F. (2019). Friends or foes? Examining platform owners' entry into complementors' spaces. Journal of Economics & Management Strategy, 28(1), 23–28. https://doi.org/10.1111/jems.12303

Zhu, F., & Liu, Q. (2018). Competing with complementors: An empirical look at Amazon.com. Strategic Management Journal, 39(10), 2618–2642. https://doi.org/10.1002/smj.2932

Chapter 3 — Integrating with Dominant Offers

A small business plugs into the offers that its own customers already run, so this chapter says what counts as a dominant offer for a small firm, follows the customer's systems and never the loudest platform, reads the terms of mobile app stores as of the day they were read, describes business software ecosystems and their marketplaces and the device and home standards that certify before they make compatible, separates read, write and event access, ranks the depth of an integration from a link to an embedded workflow, scores candidate integrations on one grid, says that no typical cost of building and keeping an integration is known, and chooses one integration for Hydrosentinelle inc. among three candidates, posed by this book.

What You'll Be Able to Do

• Decide what counts as a dominant offer for a small firm, by counting the customers who already run it rather than by reading a market share in a source.
• Draw the map of the systems the customers run, and write the reach of each candidate integration in the customers' own count of buildings or accounts.
• Read the terms of a mobile app store as that store's term of the day it was read, with its page and its date, and never as a market rate.
• Separate read access, write access and event access, and say what each kind asks of the complementor that holds it.
• Rank the depth of an integration from a link to an embedded workflow, and say what each step deeper adds to the customer and to the business's dependence.
• Score candidate integrations on one grid of six weighted criteria, apply the rule, and write the decision and its date down.

Why It Matters

A small firm chooses where to plug in with the information it has, and that information may be about the platforms it hears about rather than about the systems its customers run. The gap between the two is where the work is wasted. A platform that fills the news and serves none of the firm's customers is a platform whose integration will be built, listed and maintained for a year without changing a single customer's day, while a quiet platform that serves many of the customers is where a modest integration changes the work of many buildings. The map of the customers' systems is the instrument that tells the two apart, and it is drawn from the firm's own records rather than from a market report.

The second reason is that the terms of an offer are read once and bind for as long as the business uses the offer. A store's guidelines say when a free companion application needs no purchase inside it, and a store's review decides how a given application is reviewed. A fee page read on one day is that store's term of that day and never a market rate. None of this is advice about the reader's own agreement, and all of it is worth reading on the day it is signed and keeping a copy of, because a page that moved once can move again.

The third reason is that depth is a choice and not a consequence. An integration can be a link on a page, a one-way export of data, a one-way event, a two-way synchronization or a workflow embedded in the platform's own screens, and each step deeper adds value for the customer and adds dependence for the business. This chapter puts the five depths in order, scores the candidates on one grid, and writes the decision down with its date, so that the depth is a decision the business made rather than one it discovered.

In This Chapter

Section 3.1 says what counts as a dominant offer for a small firm and draws the frontier between this chapter and its neighbors. Section 3.2 follows the customer's systems rather than the loudest platform. Section 3.3 reads mobile app stores as distribution the company does not own, with the terms of two stores as of October 15, 2026. Section 3.4 describes business software ecosystems and their marketplaces. Section 3.5 reads device and home standards, where certification comes before compatibility. Section 3.6 separates read, write and event access. Section 3.7 ranks the depth of an integration. Section 3.8 scores candidate integrations on one grid. Section 3.9 says what is known about the cost of building and keeping an integration. Section 3.10 chooses one integration for Hydrosentinelle inc. among three candidates, posed by this book.

3.1 What Counts as a Dominant Offer for a Small Firm

A dominant offer, seen from a small firm, is not the platform with the largest share of a market read in a source. It is the offer that dominates the customer's own working life: the system the customer already runs every day, the store the customer already uses to find an application, the standard the customer's devices already follow. This is this book's own reasoning, and no source read for this chapter measures a market share, a customer count or a share of businesses that run any system. The distinction matters because a share read in a source would be a figure about a market rather than a fact about the customers the firm actually serves.

The test is therefore a test about the customers, and it has three parts. The first part is the count: how many of the firm's own customers run the system, use the store or follow the standard. A count of the firm's own customers is a fact the firm can establish from its own records, and it is the only count that decides. The second part is the work: whether the offer sits where the customer's work already happens, so that plugging into it changes something the customer does rather than adding a place the customer must visit. The third part is the terms: what the offer asks of a business that plugs into it, which is the subject of Chapter 4 and the reason a candidate is scored on its terms before anything is built.

A dominant offer can be of three kinds, and a small firm meets all three. The first kind is a core system: the software a business runs to hold its customers, its properties, its orders or its accounts, which Book K2 (CRM and ERP Systems) holds as the core systems of a business. The second kind is a store: a place where a customer looks for an application, which Book F5 (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces) holds as selling in app stores and marketplaces. The third kind is a standard: a specification that devices follow so that they work together, where compatibility is earned by certification rather than granted by a listing. The three kinds ask different things of a complementor, and this chapter reads each of them in turn.

A dominant offer is not a platform that is large in the news, a platform that a competitor has joined or a platform that a consultant recommends. Each of those is a reason to look, and none of them is a reason to build. The reason to build is that the firm's own customers run the offer and that the integration would change something in their work.

The frontier of this chapter is worth drawing before the reading begins, because four neighbors hold parts of the subject and none of them is redone here. The table below sets each neighbor beside what that neighbor holds and what this chapter holds. Read it as a map of the chapter's own ground: the rows are the books that touch this subject, the middle column is what each of them owns, and the right column is the part left to this chapter. The neighbors are cited and never rewritten, and a matter that lies in another book is not treated here.

Table 3.1 — Where this chapter stops and its neighbors begin

The multi-sided model behind this reading is Book A1's (From Idea to Business Model, chapter 6 of Book A1), developed here from the complementor's side and never redefined, and what a dominant offer is was defined in section 1.1 of this book. What this chapter adds is the practice: which offer to look at first, how to read the access and the terms, how deep to go, how to score the candidates, what the build and the upkeep cost in the business's own plan, and how to write the decision down.

DEFINITION The words this book uses for a candidate integration, reach, depth, a pilot and upkeep

These are this book's working words, and no source read for this chapter defines them in this sense. A candidate integration is a plug-in to one dominant offer that the company considers building, scored before anything is built. Reach is the number of the company's customers or buildings that the integration would serve, counted in the customers' own units and never in a market's size. Depth is how much of the company's workflow the integration carries, from a link on a page to a workflow embedded in the platform's own screens. A pilot is the integration in service for a few customers before it is offered to all, with a named customer and a named end. Upkeep is the yearly work of keeping an integration compatible: versions, the renewal of a security review and the reading of terms that move. A dominant offer is defined in section 1.1 of this book and is not redefined here. The words are this book's own, and the case's figures are posed by this book.

3.2 Following the Customer's Systems, Not the Loudest Platform

The map decides. Chapter 2 draws the map of the platforms around a business's customers, and this chapter reads that map as the only list from which a candidate integration is drawn. A small firm plugs into the system its customers run, and it does not plug into the platform that fills the news. The reason is arithmetic rather than taste: the value of an integration is the number of the firm's own customers it serves, and a platform that serves none of them serves none of them however large it is.

The case shows the arithmetic. On day 1, Hydrosentinelle inc. monitors 820 buildings under subscription, a figure posed by this book; Book L5's last printed base is 495 buildings at the close of its year, and it is cited and never recounted. The buildings are run by the customers in different systems, and the map of day 1, posed by this book, puts 312 of the 820 buildings in the first property-management system, 148 in the second and 360 in other systems or none. The largest customer, a property management company with fourteen buildings that Book G8 (Business Insurance and Risk Financing) prints, is inside the 312. No integration with a platform that none of the customers runs is scored, and the third candidate of section 3.10 is scored low on reach for exactly that reason.

The map is drawn from the company's own records, and it is drawn before any candidate is named. The order matters, because a candidate named first attracts a map that supports it. The head of sales and operations asks each customer, in the ordinary course of service, which system the buildings are run in, and writes the answer beside the building. The count is then a count of buildings and not a count of customers, because a customer with fourteen buildings is fourteen buildings of reach and a customer with one building is one. The count is written in the customers' own unit, and it is the number that decides whether a candidate is worth scoring at all.

A platform that serves no customer of the firm is a distraction however large it is, and the distraction has a cost that is easy to miss. The hours of reading the terms, answering the security questionnaire, keeping the listing current and renewing the review are the same hours whether the integration serves many buildings or none, and a business that spends them on a platform its customers do not run has spent them on a listing rather than on a service.

The map also decides the order of the work. A firm with its buildings spread over two systems has a first candidate and a second candidate, and the second is queued rather than dropped. The queue is written down with its score, so that the second candidate is read again at the next yearly reset of the integration roadmap rather than rediscovered. A candidate that scores below the rule is written down as not now, with the reason, so that the same candidate is not scored again from memory in six months.

WATCH OUT The loudest platform is the one in the news, and the customers' system is the one that counts

The trap is to integrate with the platform heard about most before the map of the customers' systems is drawn. A platform that fills the news and serves none of the company's customers is a distraction however large it is, and the work spent on it is work not spent on the system the customers run. Two signs catch the trap. The first is a decision taken before the map is drawn: the platform was chosen in a conversation, and no list of the customers' systems exists. The second is a reach that no one can state in buildings: asked how many customers run the platform, the answer is a feeling rather than a count. The remedy is to draw the map first, as Chapter 2 does, and to write the reach of each candidate in the customers' own count. In the case, posed by this book, the map of day 1 puts 312 of 820 buildings in the first property-management system, 148 in the second and 360 in other systems or none, and no integration with a platform that none of the customers runs is scored. The reasoning is this book's own.

3.3 Mobile App Stores: Distribution You Do Not Own

A mobile app store is a dominant offer of the second kind, and it is the one where a small firm most easily forgets who owns the shelf. The store reviews the application and decides whether it is listed; the distribution is real and it is not owned by the company that publishes. The listing, the ranking and the marketplace economics of a store are Book F5's (chapters 2, 4, 5 and 7 of Book F5), and this chapter reads the store's terms as the terms of the day they were read, because the terms are what a complementor signs.

Three pages were read on October 15, 2026, and each is that platform's own term of that day, never a market rate and never stable. The first is one store's review guidelines, last updated June 8, 2026, read in full: in-app purchase is required to unlock features or functionality (3.1.1); certain applications may use other purchase methods (3.1.3); enterprise services sold directly to organizations for their employees may give access to content bought outside the application (3.1.3(c)); a free stand-alone application that companions a paid web-based service needs no in-app purchase as long as it has no purchasing inside and no call to buy outside (3.1.3(f)); and features that depend on specific hardware may be unlocked without in-app purchase (3.1.4) (Apple, 2026). The page does not say how a given application will be reviewed, and it gives no notice period for changes to the guidelines.

The second page is the same store's small business program, as of October 15, 2026: a developer with no more than 1 million USD of proceeds in the previous calendar year and the current year qualifies for a reduced commission of 15 percent on paid applications and in-app purchases; subscriptions after their first year and developers under the alternative terms in the European Union pay 10 percent; the standard rate is named but its percentage is not on the page; and enrollment requires accepting the paid applications agreement (Apple, n.d.). The third page is the other store's service fees page, as of October 15, 2026, with no update date shown: in the markets not yet moved to the new regional tier, 15 percent on the first 1 million USD of earnings a year and 30 percent above, and 15 percent on subscriptions for developers enrolled in the 15 percent tier; a regional tier for Australia, the European Economic Area, Japan, the United Kingdom and the United States, rolled out on June 30, 2026 or September 30, 2026, splits a service fee and a billing fee of 5 percent by kind of install and transaction; the billing fee applies to digital purchases made through the store's billing; and the page gives no rate for Canada after a future rollout and no fee on a service invoiced outside the store (Google, n.d.).

The table below sets the two stores' terms side by side for a free companion application that sells nothing inside itself, and adds the reading the case draws from each. Retain that the two pages do not answer the same questions, and that a row where a page gives nothing is a row where no inference is drawn.

Table 3.2 — Two stores' terms for a free companion application, as of October 15, 2026

The case's own situation is simple and it is posed by this book. The mobile application is free on two dominant mobile app stores, and nothing is sold inside it: the subscription is invoiced to the building owner, so the commissions on digital purchases do not apply to it as the pages read on October 15, 2026 describe those commissions. A store's review decides how a given application is reviewed, and this reading, which is not legal advice, is that of the pages read on that day. The company keeps a copy of each page it read, with the day, because the copy is what the company compares against when a page moves.

Distribution through a store is distribution the company does not own, and the consequences are the subject of Chapter 6. Whether a store may review, reject or remove an application is a matter of its agreement, which Chapter 6 reads. The remedy is not to avoid stores; it is to keep the critical path outside them. In the case, the alert path never runs through a platform: an alert goes by text message and by email directly, and the application is a convenience that may fail without silencing an alert. That is the arrangement that makes a store's decision survivable.

WHAT CHANGED One store moved to a regional fee tier on June 30, 2026 or September 30, 2026 (Google, n.d.)

The dated change comes from the page read on October 15, 2026: the other store's service fees page says that a regional tier for Australia, the European Economic Area, Japan, the United Kingdom and the United States rolled out on June 30, 2026 or September 30, 2026, and that the tier splits a service fee and a billing fee of 5 percent by kind of install and transaction (Google, n.d.). The page shows no update date, and it gives no rate for Canada after a future rollout and no fee on a service invoiced outside the store. It is one store's term of the day it was read, never a market rate and never stable. A business that lists an application reads the fee page again on the day it signs and keeps the copy it read. The case's application is free and sells nothing inside, so the tier does not apply to it as the page describes it, and that reading is posed by this book.

THE RULE A store's guidelines say when a free companion application needs no in-app purchase, as of the day read (Apple, 2026)

The rule is the store's own term, read on October 15, 2026, in the guidelines last updated June 8, 2026: a free stand-alone application that companions a paid web-based service needs no in-app purchase as long as it has no purchasing inside and no call to buy outside (Apple, 2026, 3.1.3(f)). This is that store's term of the day it was read and never a market rate, and the page gives no notice period for changes to the guidelines. A store's review decides how a given application is reviewed, and nothing here is advice about the reader's own application. The case's application is free, sells nothing inside and calls for no purchase outside, and that reading is posed by this book.

3.4 Business Software Ecosystems and Their Marketplaces

The core software of a business is the dominant offer of the first kind, and it is the one a small firm meets most often. A property manager runs the buildings in a property-management system; a distributor runs its orders in an enterprise resource planning system; a sales team runs its accounts in a customer relationship management system. Book K2 (CRM and ERP Systems) holds those core systems as the systems of a business, and this chapter holds the customer's core system as the offer that a small firm integrates with. The system is dominant in the customer's eyes because the customer's work already happens inside it, and an integration that appears where the work happens is an integration the customer uses.

A core system of any size may have two things beside it, and both matter to a complementor. The first is a partner program: a set of terms under which another business may build on the system, list what it built and be recognized as a partner. The second is a marketplace of partner integrations: a catalog inside the system where the customer finds the partner's integration and installs it. The two are related and they are not the same. The program is the contract; the marketplace is the shelf. A business that joins the program without listing is a business the customer cannot find, and a business that lists without reading the program has signed terms it has not read.

Three things are read before a small firm plugs into a core system, and they are read in this order. The first is reach: the number of the firm's own customers who run the system, counted in the customers' own units, as section 3.2 counts it. The second is access: what the system lets a complementor do, whether it may read the system's records, write into them or be told when something happens, which is the subject of section 3.6. The third is the terms of the partner program: what the program asks, what it gives, what it charges and what notice it gives before a change, which is the subject of Chapter 4. The order matters because reach decides whether the candidate is scored at all, access decides how deep the integration can go, and terms decide what the business is signing.

The marketplace of a core system is a shelf with its own rules, and those rules are Book F5's. The listing, its ranking, its fees and the marketplace economics of a partner catalog are held by Book F5 (chapters 2, 4, 5 and 7 of Book F5), and this chapter does not redo them. What this chapter adds is the reading that comes before the listing: whether the system is worth listing in at all, which is a question about the firm's own customers and not about the catalog's size. A catalog with a long list of integrations and none of the firm's customers is a catalog that will not be found.

The case's first candidate is a core system, and its terms are posed by this book. The first property-management system has a partner program that asks an annual fee of $3,000 and no share of the subscriptions, which the company keeps invoicing. No real program's fee is presented as the case's, and the program is never named. The fee is a fixed fee posed by this book and illustrative, and it is not a market price; the terms of the program are read by the outside lawyer before the decision is written, and the reading of a partner agreement is Chapter 4's. The company's subscriptions are invoiced to the building owner, and the platform takes no share of them, which is the arrangement the company wants and the one it reads the terms to confirm.

3.5 Device and Home Standards: Certification Before Compatibility

A standard is the dominant offer of the third kind, and on this book's reading it works the other way round from a platform of software. A platform of software grants access by a listing and a key; a standard grants compatibility by certification. The difference changes the first question a business asks. For a platform, the first question is what the platform lets the business do. For a standard, the first question is what certification involves, because the page read describes certification as a process without giving the detail a business needs.

The page read for this chapter describes the standard and not the gate. The alliance's page on its smart home standard, read on October 15, 2026, describes an internet-protocol-based smart home connectivity standard, running on Wi-Fi and Thread with Bluetooth Low Energy for commissioning, developed by the alliance's members in an open-source approach; the page names a certification process, certified product listings, testing providers, an interoperability testing facility and a compliance ledger (Connectivity Standards Alliance, n.d.). The page does not give the steps, the cost or the duration of certification, and it does not give the latest version. A business that plans around certification therefore plans around a process whose steps it has not read, and it asks the alliance or a testing provider for the steps before it commits.

The research read for this chapter describes the problem the standard answers. The abstract of the article reports that smart home devices have lacked interoperability, and that industry organizations collaborated on a connectivity solution intended as a universal smart home standard; the article overviews and evaluates its design, features and performance (Madadi-Barough et al., 2025, abstract only). The abstract is the authors' own summary of an article about a design and its performance, and it reports no adoption figure. What it supports is a reading of why a standard exists: devices from different makers did not work together, and a common standard is the attempt to make them work together. What it does not support is any statement about how many devices or households follow the standard, and none is printed here.

For a small firm, a standard may be attractive and may be slow. It may be attractive because certified devices are meant to work together, so the firm's reach could be the reach of the standard rather than of one platform. It may be slow because certification is a process with steps the firm does not control, and because a standard's reach among the firm's own customers is a fact the firm must establish rather than assume. A business that builds for a standard asks two questions before it builds: how many of its customers' buildings follow the standard today, and what certification involves in steps, cost and duration. The first question is answered from the firm's own map, and the second is answered by the alliance or a testing provider.

The case's third candidate is the smart-home standard for rental units, and it is scored low on reach and on value, posed by this book. The reason is the map: the standard's reach among the company's 820 buildings is not established, and the work it would change in a property manager's day is small compared with the work a work order changes. The candidate is scored 2 on reach and 2 on value, and the verdict is not now. The verdict is not a judgment about the standard; it is a reading of the company's own customers on the day the grid was scored, and it is read again at the next yearly reset of the integration roadmap.

A standard also asks a different kind of patience. A platform's terms can change with notice and the business reads the notice; a standard may change by version. The page read for this chapter gives no version and no schedule, so a business that builds for a standard keeps its own record of the version it relied on and the day it relied on it, and it reads the alliance's page again before it relies on a version. That record belongs in the register that section 3.6 describes, and it is kept by the business rather than by the standard.

3.6 Interfaces: Read, Write and Event Access

A platform grants a complementor access in three kinds, and the three kinds ask different things of the business that holds them. The first kind is read access: the business may look at the platform's records, such as the buildings a customer runs or the orders a customer placed. The second kind is write access: the business may create or change a record in the platform, such as opening a work order. The third kind is event access: the business may be told when something happens in the platform, or may tell the platform that something has happened in the business's own system. A platform grants each kind on its own terms, and it may withdraw any of them, which is the subject of Chapter 6.

The three kinds are not interchangeable and they are not ranked. Read access is the narrowest and the easiest to hold, and it is enough for an integration that shows the customer something. Write access is what makes an integration change the customer's work, and it is also what makes the business answer for what it writes: a record created by the integration is a record the customer will act on. Event access is what makes an integration timely, and it is what asks the business to send each event once, with an identifier, so that a repeated delivery does not produce a second record. A business that holds write access without event access writes records late; a business that holds event access without an identifier writes records twice.

The concepts behind the three kinds are Book K8's. Interfaces, webhooks, polling, authentication and rate limits as integration concepts are held by Book K8 (No-Code, Low-Code and Integrations, chapter 2 of Book K8), and this chapter cites them rather than rewriting them. What this chapter adds is the choice: which kind of access the integration needs, and how narrow the permission can be kept. Delegated access, scoped permissions and the security practice that goes with them are Chapters 5 and 7, and this chapter does not read them. The rule this chapter keeps is the narrowest one: ask for the access the task needs and no more, because a permission that is not held cannot be misused and cannot be withdrawn.

The table below sets the three kinds of access beside what each lets a complementor do, what each asks of the complementor and how the case's first integration uses it. Read it row by row: the first column is the kind of access, the second and third are what it gives and what it asks, and the fourth is the case's use, posed by this book. Retain that the fourth column is the narrowest use that serves the customer's work, and that a business which cannot state its use in one sentence has asked for more access than it needs.

Table 3.3 — Read, write and event access, and the first integration's use

The case's first integration uses the third kind and one write, and it is posed by this book. The integration sends the alert event of a building whose manager enabled it to the first property-management system, where it opens one work order. The event carries the building, the unit label, the sensor's location, the time and the severity, and no tenant's name. Each event has an identifier, and a repeated delivery never opens a second work order. The company reads nothing of the customer's system, which is the narrowest reading that serves the work: the customer's staff see a work order where the work is done, and the company holds no copy of the customer's records.

The narrowest access is also the easiest to explain. A security questionnaire asks what data the integration touches and where it goes, and the case's questionnaire, answered by the president, product and engineering, has a short answer because the integration reads nothing and writes one record.

TOOLS OF THE TRADE What a business needs to read an interface: stored documents, a test client, a sandbox account and a register

Four functions carry the reading of an interface, and a business should look for them rather than for a product. The first is a stored copy of each interface's documents with the day it was read, because a page that moved once can move again and the copy is what the business compares against. The second is a test client that can call an interface without the customer's data, so that a first call is made against a test address and never against a live account. The third is a sandbox account on the platform's side where one exists, because a sandbox is where a first write is tried and a mistake costs nothing. The fourth is one register where each integration is written with the access it holds, the customer it serves and its way out, so that the business can answer what it depends on without opening five pages. Chapter 10 gives the functions in full, table by table. No brand name belongs on this list and no price; the requirement is the function, and the case uses no tool of this kind, posed by this book.

3.7 Depth of Integration: From a Link to an Embedded Workflow

An integration has a depth, and the depth is a decision rather than a consequence. Five depths are worth naming, from the shallowest to the deepest. The first is a link: the platform's page carries a link to the business's own page, and nothing crosses between the two systems. The second is a one-way export of data: the business sends the platform a copy of something, and the platform holds it. The third is a one-way event: the business tells the platform that something happened, or the platform tells the business, and one record is created on the other side. The fourth is a two-way synchronization: two records are kept in step, and a change on either side is written to the other. The fifth is an embedded workflow: the business's work runs inside the platform's own screens, so that the customer never leaves the platform to use the business's service.

Each step deeper adds value for the customer and adds dependence for the business, and the two move together. A link costs little to keep and asks little of the platform, and it also changes little in the customer's work. A one-way export gives the customer a copy and asks for read access, and the copy goes stale. A one-way event makes the customer's system timely and asks for event access, and the business now depends on the platform's delivery. A two-way synchronization keeps two records in step and asks the business to answer for what it writes, and a conflict between the two records is now the business's problem. An embedded workflow puts the company's work inside another company's product, and a change of that product's terms is a change of the company's own service.

The deepest depth is also the one a platform owner may take for itself. The abstract of the study read for this section reports one case: after one social platform tightly integrated its own photo-sharing application, the user base of that application grew, big third-party applications saw a small increase in demand and small ones a decrease, and demand for the whole photo-sharing ecosystem increased (Li & Agarwal, 2017, abstract only). That is one social platform and one period, and it is not a business-software setting; the direction of the effect on complementors differs by setting (section 2.8), and the study is read as one case rather than as a rule. What it shows is that a platform owner can integrate its own application tightly, and that the complementors around it feel the change.

The case builds the shallowest depth that serves the customer's own work, and it is posed by this book. The first integration is a one-way event with one work order: the alert event goes to the first property-management system, and one work order is opened. Nothing deeper is built. The company does not synchronize records, does not embed its workflow in the platform's screens and does not read the customer's system. The reason is that the customer's own work is changed by a work order appearing where the work is done, and a deeper integration would add dependence without adding work the customer does. The depth is written down with the decision, so that a later request to go deeper is read as a new decision rather than as an extension of the old one.

KEY CONCEPT Each step deeper into a customer's system adds value and adds dependence

The idea of this section is this book's own reading and never a finding of a source: each step deeper into a customer's system adds value for the customer and adds dependence for the business. A link on a page costs little to keep and asks little of the platform. A one-way export of data gives the customer a copy and asks for read access. A one-way event tells the customer's system that something happened and asks for event access. A two-way synchronization keeps two records in step and asks the business to answer for what it writes. A workflow embedded in the platform's own screens puts the company's work inside another company's product, where a change of terms is a change of the company's own service. The abstract of the study read for this section reports one case: after one social platform tightly integrated its own photo-sharing application, the user base of that application grew, big third-party applications saw a small increase in demand and small ones a decrease, and demand for the whole photo-sharing ecosystem increased (Li & Agarwal, 2017, abstract only). That is one platform and one period, and the case builds the shallowest depth that serves the customer's own work.

3.8 Scoring Candidate Integrations on One Grid

A candidate integration is scored on one grid, and the grid is the same for every candidate so that the candidates can be read against one another. The grid has six criteria, each with a weight, and each candidate is scored from 1 to 5 on each criterion, a higher score being better. For four of the criteria a higher score means less effort or less risk, and the text says so where the criterion is read. The total is out of 100: each weight is multiplied by its score, the products are added and the sum is divided by five. The rule is posed by this book: build at 70 or more, queue from 55 to 70, not now below 55.

The six criteria are chosen so that a candidate cannot win on one of them alone. Reach is the buildings the integration would serve, and it carries the heaviest weight with value, because an integration that serves nobody is not worth building however cheap it is. Value to the customer's own work is whether the integration changes something the customer does, and it carries the same weight as reach, because an integration that serves many customers without changing their work is a listing rather than a service. Effort to build and effort to keep each year carry the next weights, and they are scored so that a higher score means less effort. Terms and dependence risk carries a weight of its own, because a candidate with light terms and low dependence is a candidate that can be left as easily as it was joined. Data and privacy exposure carries the last weight, and a higher score means less data crosses the integration.

The table below sets the six criteria beside their weights and what a score of 5 means on each. Read it as the grid itself: the first column is the criterion, the second is the weight, and the third is the reading of a top score. The weights and the readings are posed by this book and illustrative, and they are written before any candidate is scored, so that the weights are a decision about what matters rather than a justification of a favorite.

Table 3.4 — The six criteria of the grid and their weights, posed by this book

The grid is scored with one sentence of reason beside each score: a score of 5 on reach is written with the count of buildings that supports it, and a score of 2 on terms with the clause that supports it. A grid without reasons is a set of numbers that cannot be re-read.

The rule is applied to the total and not to a criterion. A candidate that scores 5 on reach and 1 on terms can still be built if its total reaches 70. The rule is a threshold and not a ranking: two candidates can both be built, and a candidate that scores 68 is queued rather than dropped. The queue is written down with its score and its date, so that the next yearly reset reads the same grid rather than a new one.

The standard's certification process is recalled here because it belongs to the grid: the alliance's page names a certification process and does not give its steps, its cost or its duration (Connectivity Standards Alliance, n.d.), so a candidate that is a standard is scored on effort to build and effort to keep with an unknown in it, and the unknown is written into the reason beside the score rather than smoothed over.

METHOD Scoring candidate integrations on one grid in five steps

First, list the candidate integrations that the map of the customers' systems supports, and drop any platform that none of the customers runs. Second, write the six weights before any score is given, so that the weights are a decision about what matters and not a justification of a favorite. Third, score each candidate from 1 to 5 on each criterion, with the reason in one sentence beside the score, so that a later reader can see why the number was chosen. Fourth, multiply each weight by its score, add the products and divide the sum by five, then apply the rule: build at 70 or more, queue from 55 to 70, not now below 55. Fifth, write the decision and the date and keep the grid in the register, so that the next review reads the same grid rather than a new one. The sequence is this book's own, no source read tests it, and the weights and the rule are posed by this book for the case. The grid is a way of writing a decision down, never a measurement of a platform.

WHO DOES THIS Two founders score the grid together, and the outside lawyer reads the terms of the first candidate

Who scores depends on the size of the business, and the division below is this book's suggestion and not part of the case. A solo owner scores alone and asks one outside reader to look at the grid before the decision is written, because a grid scored by one person has no second reading. In a small team the owner and the developer score together, and a lawyer reads the terms of the candidate that scores highest, because the terms are where the dependence is written. In an established business a product lead scores the grid and a partnerships manager checks the terms, and Chapter 9 reads the roles behind platform work. In the case, posed by this book, Karim Haddad, the head of sales and operations, scores reach and terms, Laurence Bergeron, the president, product and engineering, scores build, upkeep and data, and the outside lawyer reads the terms of the first candidate by day 21. No hire is made, and the two founders score the grid together before the decision is written on day 28.

3.9 The Cost of Building and Keeping an Integration

No source read for this book gives a typical cost of building or keeping an integration, so no figure is printed as typical. That is the state of the evidence, and it is worth stating plainly because the question is the first one a business asks. There is no source in this book for a typical, average or benchmark cost to build or to keep an integration, for any sector or size of business, and a figure quoted as typical would be a figure with no source behind it. What a business can do instead is write the cost as lines of its own plan, with its own hours and its own fees, and read the total against the value it expects.

The lines of the cost are four, and each is written separately. The first is the build: a fixed fee paid to an outside developer or the hours of the business's own people, and it is written as one line with the acceptance criterion beside it. The second is the platform's fee: what the partner program asks, whether an annual fee, a share of revenue or both, and it is written as the platform's term of the day it was read rather than as a market rate. The third is the upkeep: the yearly work of keeping the integration compatible, which is versions, the renewal of a security review and the reading of terms that move. The fourth is the hours of the founders and the staff, which are the hours the business would otherwise spend elsewhere, and they are written as hours rather than as money unless the business values them at a rate.

The case's lines are posed by this book and illustrative. The build is a fixed fee of $12,000 paid to the outside integration developer, a provider of the bench of Book I8 (Freelancers, Agencies and Outsourcing), with the acceptance criterion written by the president, product and engineering. The first platform's partner program asks an annual fee of $3,000, and the company keeps invoicing its subscriptions, so the platform takes no share of them. The upkeep is 48 hours a year of the president, product and engineering, which is the yearly work of versions and of renewing the security review, and the routine that carries it is Chapter 8's. Every figure is posed by this book and is not a market price, and the annual fee rises to $3,600 on day 365 with 60 days' notice, which is the subject of Chapter 6.

The cost is read against the value, and the value is written in the customers' own units. A build of a fixed fee and an annual fee is read against the number of buildings the integration serves and the work it changes in their day. The reading is not a return on investment and this book prints no such figure; it is a comparison of a written cost with a written reach, made before the build rather than after it. A business that cannot write the reach in buildings has not yet drawn the map, and the cost is read after the map rather than before it.

QUÉBEC & CANADA NOTE The thresholds of the stores are stated in United States dollars, and this book converts none of them

The Canadian point of this section is a matter of currency and of contracts. The thresholds and tiers of the two stores' programs, read on October 15, 2026, are stated in United States dollars on the two pages read, one store's small business program (Apple, n.d.) and the other store's service fees page (Google, n.d.), and the case's own amounts are posed by this book and are in its own dollars; this book converts none of them and prints no exchange rate. A contract with a platform or with an integration developer is a commercial agreement, and Book H1 (Contracts and Commercial Agreements) holds contracts and contracts of adhesion, with a lawyer for a given case. A contract whose clauses a platform draws and a business cannot negotiate is the kind of contract that Book H1 treats as a contract of adhesion, and whether a given clause binds is a question for a lawyer and never for this book. This book recommends no vendor, no platform, no store and no developer, and it prints no fee of any real program as the case's own.

3.10 The Case's Three Candidates and One Choice

Hydrosentinelle inc. scores three candidate integrations on the grid of section 3.8, and the three are posed by this book. The first is the first property-management system, where 312 of the 820 buildings of day 1 are run. The second is the second property-management system, where 148 are run. The third is the smart-home standard for rental units, whose reach among the company's buildings is not established. The partner terms of the first candidate are read by the outside lawyer by day 21, and the decision is written on day 28. One integration is built, the first; the second is queued; the third is not now.

The scores are given in two tables, so that no table is wider than six columns. The first table gives each candidate's scores on reach, value, build and upkeep. Read it row by row: the first column is the candidate, and the next four are the scores from 1 to 5, a higher score being better, with a higher score on build and upkeep meaning less effort. The scores are posed by this book and illustrative, and they are read beside the second table rather than alone.

Table 3.5 — The three candidates on reach, value, build and upkeep, posed by this book

The second table gives each candidate's scores on the last two criteria, terms and data, then the weighted total out of 100 and the verdict of the rule. Read it row by row, beside the first: the first column is the candidate, the next two are the scores on terms and on data, the fourth is the total, and the fifth is the verdict. The totals are posed by this book and illustrative, and the rule that reads them is the rule of section 3.8: build at 70 or more, queue from 55 to 70, not now below 55.

Table 3.6 — The three candidates on terms and data, with the total out of 100 and the verdict, posed by this book

Figure 3.1 scores the case's three candidate integrations on one grid of six weighted criteria, against the thresholds of the grid's rule.

Figure 3.1 — One grid, one integration built. The first property-management system scores 77, the second 68 and the smart-home standard for rental units 44; build at 70, queue at 55 (posed).

The figure is read bar by bar. The first bar is the first property-management system, at 77, above the line of 70, and its verdict is build now. The second bar is the second property-management system, at 68, between the two lines, and its verdict is queue. The third bar is the smart-home standard for rental units, at 44, below the line of 55, and its verdict is not now; the unknown of its certification process is written into the reason beside the score on build. One integration is built, and the other two are written down with their scores and their date.

The choice is written as a decision with its date, and the decision is the company's own. The first integration is built at the shallowest depth that serves the customer's own work: a one-way event with one work order, as section 3.7 describes. The second candidate is queued for the next yearly reset of the integration roadmap, and the third is not now. The decision records what the company chose not to do as well as what it chose to do, and no sale, no customer and no growth is credited to the integration.

In La Machine, as of the application copy of September 7, 2026, the pages that touch this chapter are Me → My Websites (crm/me/websites), which lists, for a partner account, the external sites where that partner presents the platform and belongs to the publisher's original equipment manufacturer program, and Offers → Marketplace (client/marketplace), a demonstration of a buying experience. It offers no documented public interface, no user-managed interface key, no webhook a user can configure, no single sign-on, no connector marketplace and no listing on another company's marketplace; check it in your installation. Every fact holds in the application copy of September 7, 2026, read in its code on October 15, 2026. The case does not use La Machine; this book is valid with any tool; La Machine is described and never sold.

CASE IN POINT Hydrosentinelle inc. scores three candidate integrations by day 28 and builds the first one

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. Hydrosentinelle inc. scores three candidate integrations on the grid of section 3.8: the first property-management system, the second property-management system and the smart-home standard for rental units. The partner terms of the first candidate are read by the outside lawyer by day 21, and the decision is written on day 28. One integration is built, the first; the second is queued; the third is not now. Karim Haddad, the head of sales and operations, scores reach and terms, and Laurence Bergeron, the president, product and engineering, scores build, upkeep and data. The scores, the weights and the rule are posed by this book and illustrative, and no sale, no customer and no growth is credited to the integration. The company keeps invoicing its subscriptions, and the first platform's partner program asks an annual fee of $3,000 and no share of those subscriptions, posed by this book.

DO THE MATH Six weights, three candidates, one total each: the grid in numbers

Illustrative figures; the case is fictional. Step 1 — The six weights are 25, 25, 15, 10, 15 and 10, which add to 100. Step 2 — Each weight is multiplied by its score from 1 to 5, the products are added and the sum is divided by five, so that a candidate scored 5 on every criterion would total 100. Step 3 — The first candidate, scored 5, 5, 3, 3, 2 and 3, totals 77. Step 4 — The second candidate, scored 2, 5, 3, 3, 4 and 3, totals 68, and the third, scored 2, 2, 1, 2, 3 and 4, totals 44. Step 5 — The rule builds at 70 or more, queues from 55 to 70 and says not now below 55, so the first candidate is built, the second is queued and the third is not now. Every score, every weight and the rule are posed by this book and illustrative, and the sums are exact.

IN LA MACHINE La Machine lists the sites of the publisher's OEM partners and shows a marketplace that is a demonstration, and it integrates with no dominant offer

In the application copy read on October 15, 2026, Me → My Websites (crm/me/websites) lists, for a partner account, the external sites where that partner presents the platform, with a name, an address, sectors and a style source; it belongs to the publisher's original equipment manufacturer program (Book F2, OEM Partners and White-Label Programs), never to the case and never to an integration. Offers → Marketplace (client/marketplace) is a demonstration of a buying experience, with a seeded catalog and a simulated payment; it is never a marketplace in operation and never a catalog of integrations, and Book F5 (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces) holds marketplaces. La Machine offers no documented public interface, no interface key a user manages, no webhook a user configures, no single sign-on, no connector marketplace and no listing on another company's marketplace, so it integrates with no dominant offer on a business's behalf. Check it in your installation. The case does not use La Machine, and La Machine is described and never sold.

Costly Mistakes

• Choosing the platform before drawing the map. A candidate named first attracts a map that supports it, and the integration is then built for a platform the customers do not run.
• Reading a store's fee page once and never again. A page that moved once can move again, and the copy read on the day of signing is what the business compares against when the terms change.
• Asking for more access than the task needs. A permission that is not held cannot be misused and cannot be withdrawn, and a broad permission lengthens every security questionnaire the business answers.
• Going deeper than the customer's work requires. Each step deeper adds dependence, and a workflow embedded in another company's screens is a service the business can lose with a change of terms.
• Scoring the grid without writing the reason beside each score. A grid without reasons cannot be re-read, and a grid that cannot be re-read is scored again from memory six months later.
• Quoting a typical cost of an integration. No source read for this book measures one, and a figure quoted as typical is a figure with no source behind it.
• Treating a queued candidate as a rejected one. A candidate that scores between the two lines is written down with its score and its date, so that the next yearly reset reads the same grid rather than a new one.

Key Takeaways

• A dominant offer, seen from a small firm, is the offer that dominates the customer's own working life — the system the customer runs, the store the customer uses, the standard the customer's devices follow — and never a market share read in a source.
• The map of the customers' systems decides which candidates are scored at all: in the case, posed by this book, 312 of 820 buildings are run in the first property-management system, 148 in the second and 360 in other systems or none.
• A store's terms are that store's term of the day they were read, with the page and the date, and never a market rate.
• A platform grants read access, write access and event access, each on its own terms and each withdrawable, and the narrowest access that serves the customer's work is the one to ask for.
• An integration has five depths, from a link to an embedded workflow, and each step deeper adds value for the customer and adds dependence for the business.
• Candidate integrations are scored on one grid of six weighted criteria, with the reason beside each score, and no source read for this book gives a typical cost of building or keeping an integration.

Your Action Plan

1. Draw the map of the systems your customers run. Ask each customer which system the work is run in, and write the answer in the customers' own unit of buildings or accounts. Deliverable: a written map of the customers' systems with a count in each. Verification: every customer appears once, and the counts add to the number of customers or buildings served.
2. List the candidate integrations the map supports and drop the rest. Write each candidate as a plug-in to one dominant offer, with its reach in the customers' own count. Deliverable: a list of candidates, each with a written reach. Verification: no candidate has a reach of zero, and each reach is a count and not a feeling.
3. Write the six weights before scoring anything. Set the weights of reach, value, build, upkeep, terms and data, and write what a score of 5 means on each. Deliverable: a written grid with its weights and its readings. Verification: the weights add to 100 and no candidate has been scored yet.
4. Score each candidate with the reason beside each score, and apply the rule. Score from 1 to 5 on each criterion, write one sentence of reason beside each score, multiply, add, divide by five, and apply the rule. Deliverable: a scored grid with reasons and a verdict for each candidate. Verification: every score carries a reason, and every verdict follows the rule.
5. Write the decision with its date and read the terms of the candidate you chose. Write which candidate is built, at what depth, and what the business chose not to do, and have the terms read before the build starts. Deliverable: a written decision with its date and a copy of the terms read. Verification: the decision names the depth, the date and the terms read, and the copy of the terms carries the day it was read.

In La Machine

In the application copy read on October 15, 2026, the pages that touch this chapter are Me → My Websites (crm/me/websites), which lists, for a partner account, the external sites where that partner presents the platform, with a name, an address, sectors and a style source, and belongs to the publisher's original equipment manufacturer program (La Machine, 2026). Offers → Marketplace (client/marketplace) is a demonstration of a buying experience, with a seeded catalog and a simulated payment, and it is never a marketplace in operation and never a catalog of integrations. Both pages are the publisher's own and neither is the reader's: the first serves the publisher's partner program, and the second demonstrates a buying experience rather than listing anything a business could plug into.

What a business needs for the subject of this chapter lives outside the product. La Machine offers no documented public interface, no interface key a user manages, no webhook a user configures, no single sign-on, no connector marketplace and no listing on another company's marketplace, so it integrates with no dominant offer on a business's behalf and it holds no register of the platforms a business depends on. The map of the customers' systems, the grid of candidates, the register of integrations and the copy of each platform's terms read on the day it was read are kept by the business in a spreadsheet, a document or a tool it chooses by function, and this book is valid with any tool. The case does not use La Machine, and La Machine is described and never sold; check it in your installation.

Self-Check

1. What counts as a dominant offer for a small firm, and why is a market share read in a source not the test?
2. Why does the map of the customers' systems decide which candidates are scored, and what does the case's map show?
3. What do the two stores' pages read on October 15, 2026 say about a free companion application, and what do they not say?
4. What are the three kinds of access a platform may grant, and what does each ask of the complementor?
5. What are the five depths of an integration, and why does the case build the shallowest one?

Answers. 1. A dominant offer is the offer that dominates the customer's own working life — the system the customer already runs, the store the customer already uses, the standard the customer's devices already follow — and the test is a count of the firm's own customers, because a market share read in a source is a figure about a market rather than a fact about the customers the firm serves. 2. The map decides because the value of an integration is the number of the firm's own customers it serves; in the case, posed by this book, the map of day 1 puts 312 of 820 buildings in the first property-management system, 148 in the second and 360 in other systems or none, and no integration with a platform that none of the customers runs is scored. 3. The guidelines read on October 15, 2026 say that a free stand-alone application that companions a paid web-based service needs no in-app purchase as long as it has no purchasing inside and no call to buy outside (Apple, 2026, 3.1.3(f)); the pages do not say how a given application will be reviewed, they give no notice period for changes to the guidelines, and one fee page gives no rate for Canada after a future rollout. 4. The three kinds are read access, which asks the complementor to keep the permission as narrow as the task; write access, which asks the complementor to answer for what is written; and event access, which asks the complementor to send each event once, with an identifier. 5. The five depths are a link, a one-way export of data, a one-way event, a two-way synchronization and an embedded workflow; each step deeper adds value for the customer and dependence for the business, and the case builds a one-way event with one work order because that is the shallowest depth that serves the customer's own work.

Chapter References

Apple. (2026). App Store Review Guidelines (last updated June 8, 2026). Apple Developer. Retrieved October 15, 2026, from https://developer.apple.com/app-store/review/guidelines/

Apple. (n.d.). App Store Small Business Program. Apple Developer. Retrieved October 15, 2026, from https://developer.apple.com/app-store/small-business-program/

Connectivity Standards Alliance. (n.d.). Matter. Retrieved October 15, 2026, from https://csa-iot.org/all-solutions/matter/

Google. (n.d.). Service fees. Play Console Help. Retrieved October 15, 2026, from https://support.google.com/googleplay/android-developer/answer/112622?hl=en

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: crm/me/websites and client/marketplace.

Li, Z., & Agarwal, A. (2017). Platform integration and demand spillovers in complementary markets: Evidence from Facebook's integration of Instagram. Management Science, 63(10), 3438–3458. https://doi.org/10.1287/mnsc.2016.2502

Madadi-Barough, S., Ruiz-Blanco, P., Lin, J., Vidal, R., & Gomez, C. (2025). Matter: IoT interoperability for smart homes. IEEE Communications Magazine, 63(4), 106–112. https://doi.org/10.1109/MCOM.001.2400274

Chapter 4 — Becoming a Complementor

Hydrosentinelle inc. becomes a complementor on the day a platform's review passes and its partner terms are signed, so this chapter says what a platform partner program asks and gives, how to read the partner agreement before the listing, how a security review and a certification work at the level read, what a marketplace page must carry, how fees, revenue shares and billing differ from one platform to the next as each platform's own terms on the day read, what co-selling with a platform's sales team is and is not, how reviews, ratings and installs are signals and never causes, who answers first across two companies, and how the company keeps its customer relationship while listed.

What You'll Be Able to Do

• Describe what a platform partner program asks of a complementor and what it gives back, and say why each program is its own contract of the day.
• Read a partner agreement before the listing, finding the notice a change of terms gets, the reasons and the appeal for a removal, the termination, the clauses that refer to documents outside the agreement and the fees.
• Prepare a security questionnaire in five steps, answering in writing with what is true on the day rather than with what is planned.
• Write a listing page that says what the integration does and does not do, what data it moves, who answers first and which version it is.
• Read a platform's fee page as that platform's own term of the day, and say who bills the customer in each arrangement.
• Keep the customer relationship, the invoice, the data and the alert path outside the listing, and read installs, reviews and inquiries as signals rather than causes.

Why It Matters

A business becomes a complementor by passing a review and signing terms, and both of those happen before a single customer sees the listing. The order matters. A business that builds an integration first and reads the partner agreement afterward has already spent the money, and the terms it then reads are the terms it must accept or abandon. A business that reads the terms first, decides, and builds second keeps the choice in its own hands. This chapter is about that order, and about the small number of documents and pages that decide it: the program's page, the partner agreement, the security questionnaire, the listing page and the fee page.

The reason the reading is worth the hours is that a partner program is offered on terms the platform draws up. Where the complementor cannot negotiate the notice a change of terms gets, the reasons for which a listing may be removed, or the share of a sale the platform keeps, the contract is of the kind that Book H1 treats as a contract of adhesion, and the business that joins accepts those clauses as they stand. That does not make the terms unfair, and this book draws no such conclusion about any real agreement. It makes them worth reading on the day they are signed, because a term read after a removal is a term read too late.

The reason the reading is not enough on its own is that a listing is a page and a relationship is not. A platform shows the complement, and the platform's customers read the page, install the integration and form an opinion. What the platform does not carry is the customer's contract, the invoice, the data the integration moves and the alert path that must never depend on anyone else's uptime. A business that lets a listing carry those things has handed its customer relationship to a page it does not control. A business that keeps them has a listing that carries the offer and nothing more, and it can leave the platform without leaving its customers.

In This Chapter

Section 4.1 says what a platform partner program asks and gives, and where this chapter stops and its neighbors begin. Section 4.2 reads the partner agreement before the listing, with the contract of adhesion called to Book H1 (Contracts and Commercial Agreements) and a lawyer. Section 4.3 covers the security review and the certification. Section 4.4 sets out what a marketplace page must carry. Section 4.5 reads revenue share, listing fees and who bills the customer, as each platform's own term on the day read. Section 4.6 covers co-selling. Section 4.7 reads reviews, ratings and installs as signals and never as causes. Section 4.8 says who answers first across two companies. Section 4.9 keeps the customer relationship while listed. Section 4.10 follows Hydrosentinelle inc. from the partner terms to an approved listing, posed by this book.

4.1 What a Platform Partner Program Asks and Gives

A partner program is the set of terms on which a platform admits complementors, and it both asks and gives. What it asks is a review, a track record, an agreement and sometimes a fee. What it gives is a listing, and sometimes tiers or a certification. The proportions differ from one platform to the next, and no source read for this book measures them. What can be said without a measurement is that every program is its own contract of the day, written by the platform for the platform's reasons, and that the business joining it reads the program's own page on the day it reads it.

The table below sets this chapter beside the books that hold the neighboring subjects, so that a reader knows what is here and what is elsewhere. Read it as a frontier rather than a hierarchy: each row names a book, what that book holds, and what this chapter holds instead. The neighbors are cited and never rewritten.

Table 4.1 — Where this chapter stops and its neighbors begin

The page of a customer relationship management vendor's technology partner program, read on October 15, 2026, with no date on it other than a copyright notice, describes one such program. The page says that the Technology Partner Program is the evolution of the App Partner Program; that an app must pass a quality review and meet listing requirements, with at least 3 active installs from real customers before submission; that after six months listed an app may seek certification, with a further technical review; and that the program has four tiers, partner, rising, leading and premier, based on customer value, revenue influence and quality standards (HubSpot, n.d.). The page gives no fee. It also makes claims about the results of its own certification, and this book sets those claims aside and prints them nowhere.

The article of a business marketplace, last updated July 23, 2026 and read on October 15, 2026, describes another arrangement. For a transactable offer, the page says, the platform acts as the publisher's agent for billing, payment and collection while the publisher remains the seller and licensor; a 3 percent standard store service fee is deducted at payout; a software-as-a-service offer sold this way must use the platform's identity service and its fulfillment interfaces; and a listing may instead be non-transactable, free or bring your own license (Microsoft, 2026). Those are that platform's terms of the day read, and they will change.

What a small business can take from the research is narrower than it looks. The abstract of one study reports that among 1,210 small independent software vendors from 1996 to 2004, joining a major platform owner's ecosystem was associated with higher sales and a greater likelihood of an initial public offering, more so for vendors with stronger intellectual property rights or downstream capabilities (Ceccagnoli et al., 2012, abstract only). That is an association in one sample over one period, never a cause, and it says nothing about any business after 2004. It supports one reading and no more: a program is a door worth reading carefully, and what lies behind the door is not promised by the door.

DEFINITION The words this book uses for a partner program, a listing, certification, a tier and a transactable offer

These are this book's working words, and no source read defines them in this sense. A partner program is the set of terms on which a platform admits complementors. A listing is the page on which a platform shows a complement. Certification is a badge that a platform owner attaches to a complement after a further review. A tier is a level of a program, with its own requirements. A transactable offer is a listing that a platform can bill for, acting as the publisher's agent. The words describe the platform's side of the arrangement, and each one is a term of the platform's own document rather than a standard of the industry. The program of the vendor who runs a partner program, seen from that vendor's side, is Book F9's (Building and Running a Partner Program) and is not redefined here. No figure is given, because no source read measures how many programs use tiers, how many require a fee or how long a certification takes.

WHAT CHANGED A business marketplace's article, last updated July 23, 2026, says its platform acts as the publisher's agent for billing on a transactable offer (Microsoft, 2026)

The dated change comes from the article of a business marketplace, last updated July 23, 2026 and read on October 15, 2026. The page says that for a transactable offer the platform acts as the publisher's agent for billing, payment and collection while the publisher remains the seller and licensor, and that a 3 percent standard store service fee is deducted at payout (Microsoft, 2026). It also says that a software-as-a-service offer sold this way must use the platform's identity service and its fulfillment interfaces, and that a listing may instead be non-transactable. This is one platform's term of the day read, and it will change; the page carries its own date and no other. Nothing here says that another platform bills the same way, and nothing here says that the arrangement is stable. A business reads the page of the program it is considering on the day it reads it, and it keeps the date. Book F5 (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces) holds the listing, ranking and advertising inside a marketplace, and this chapter holds the agreement behind the listing.

4.2 Reading the Partner Agreement Before the Listing

The partner agreement is the document that decides what happens when the relationship goes wrong, and it is read before the listing rather than after it. The distribution agreement of the other store, effective September 15, 2025 and read on October 15, 2026, shows the shape of such a document as that platform's contract of the day (Google, 2025). The agreement may be changed with notice, and a change takes effect for an existing developer on the date in the notice, at least 30 days after it is posted, except a change required by law, while the developer's remedy is to stop using the store (Google, 2025, s. 15). The platform may reject, remove, suspend, limit or reclassify a product or suspend a developer, with an appeal process and no promise of advance notice (Google, 2025, s. 8.3). It may terminate immediately on written notice for named causes, or on 30 days' written notice for any reason where the law allows (Google, 2025, s. 10.3). How a Québec court would read those clauses is not on the page, and Book H1 (Contracts and Commercial Agreements) and a lawyer hold that question.

The Québec law that frames the reading is the Civil Code of Québec, up to date to August 12, 2026 and read on October 15, 2026. Article 1379 defines a contract of adhesion as one whose essential stipulations were imposed or drawn up by one party and were not negotiable. Article 1435 provides that an external clause binds, but in a consumer contract or a contract of adhesion it is null if it was not expressly brought to the attention of the consumer or adhering party at formation, unless the other party proves that the consumer or adhering party otherwise knew of it. Article 1436 provides that in such a contract a clause that is illegible or incomprehensible to a reasonable person is null if the adhering party suffers injury, unless the other party proves that an adequate explanation of its nature and scope was given. Article 1437 provides that an abusive clause is null or the obligation may be reduced, an abusive clause being excessively and unreasonably detrimental and contrary to good faith. Those provisions are read at their text, they are called to Book H1 and to a lawyer, and this book applies them to no real platform's clause.

The rule of another jurisdiction is worth reading as a yardstick and never as a right. Regulation (EU) 2019/1150, read as published in the Official Journal through the Publications Office on October 15, 2026, requires in its article 3 that the terms of the online intermediation services it covers be drafted in plain language and that proposed changes be notified on a durable medium with at least 15 days' notice. That is what the European Union requires of the services it covers. It is not a right or a duty of a business in Québec, and it is printed here only as a way of asking a platform's own terms a sharper question: what notice does this agreement give, and where is it written?

The table below gives five clauses to find in a partner agreement before the listing, what to look for in each, what the sources read for this chapter say about that kind of clause, and the book that holds the rule. Read it as a reading list rather than a checklist of compliance: the sources describe one platform's agreement and two legal texts, and none of them decides whether a given clause is valid, illegible or abusive.

Table 4.2 — Five clauses to find in a partner agreement before the listing

In the case, posed by this book, the outside lawyer reads the partner terms of the first platform's program by day 21, at Book F9's illustrative rate of $300 an hour, counted in hours. The reading is not a legal opinion on whether the agreement is fair; it is a reading of what the agreement says, written down, so that the decision on day 28 is taken with the terms in hand. The decision itself is the one Chapter 3 set out: build the first integration, queue the second, and not now for the standard.

QUÉBEC & CANADA NOTE Partner terms that cannot be negotiated are read through the contract of adhesion, and this book explains the law as published and is not legal advice

This book explains the law as published and is not legal advice. The Québec point is the contract of adhesion: the Civil Code of Québec, up to date to August 12, 2026 and read at its text on October 15, 2026, defines it in article 1379, treats an external clause in article 1435 as null in such a contract unless the other party proves the adhering party knew of it, judges an illegible or incomprehensible clause in article 1436 against a reasonable person and saves it when an adequate explanation was given, and treats an abusive clause in article 1437 as null or reducible. Those provisions are called to Book H1 (Contracts and Commercial Agreements) and to a lawyer, and this book applies them to no real platform's clause and decides nothing about any agreement. The point of another jurisdiction is the at least 15 days' notice that Regulation (EU) 2019/1150, article 3, requires of the services it covers, a yardstick only and never a right of a business in Québec. This book recommends no vendor and no platform, and a business with a question about its own agreement asks a lawyer.

4.3 Security Review and Certification

A security review and a certification are two different things, and a program may ask for one, the other or both. A review checks what an integration can read and write and how its maker answers for it. A certification is a badge that the platform owner attaches to a complement after a further review, and a business that aligns its offer to a badge depends on the badge's terms, which is a dependence Chapter 6 reads. Security as a subject belongs to Book K3 (Cybersecurity, Backups and Business Continuity), and this section describes only what a program asks and how a small business answers.

The page of the customer relationship management vendor's program, read on October 15, 2026, describes both steps at the level read. An app must pass a quality review and meet listing requirements, with at least 3 active installs from real customers before submission; after six months listed an app may seek certification, with a further technical review; and the program has four tiers, partner, rising, leading and premier, based on customer value, revenue influence and quality standards (HubSpot, n.d.). The page gives no fee. The security review pages of a business-software marketplace were not read for this book, and this chapter describes no such review and prints no step, cost or duration of one.

What the research supports is narrow and worth stating at its own level. The abstract of one study reports that on one microfinance platform, a badge certifying a subset of complementors led certified institutions to reorient their offer toward the certification, and those that aligned enjoyed stronger demand-side benefits, while the platform gained borrowers, lenders and funding (Rietveld et al., 2021, abstract only). That is one platform, in one industry, and it is not a software marketplace. The abstract of another study reports that in enterprise software, vendors with more formal intellectual property rights and stronger downstream capabilities were more likely to be certified by a platform owner and to build compatible applications, suggesting that these protect against expropriation by the platform owner (Huang et al., 2013, abstract only). That is one industry and one period, and it is an association rather than a rule. Neither abstract promises a gain to any reader.

What a small business can do with those readings is to treat the review as a piece of work with an owner and a date. The review asks what the integration reads, what it writes, where the data goes, who can see it and what happens when something fails. The answers are written down, dated and kept, because the next review will ask the same questions about a changed integration. The business that answers with what is true on the day, rather than with what is planned, has a document it can hand to the next platform and to its own customers.

In the case, posed by this book, the security questionnaire of the first platform's partner program is answered by Laurence Bergeron, the president, product and engineering, and submitted on day 58. The answers describe the alert event and its work order: the building, the unit label, the sensor's location, the time and the severity, and no tenant's name. The alert path itself never runs through the platform, so a failure of the integration never silences an alert. The questionnaire is kept with its date, and it is renewed when the integration changes.

METHOD Preparing a security questionnaire in five steps

First, list the data that the integration moves, item by item, and say for each item whether it is personal information, because that question belongs to Chapter 7 and to a privacy adviser and this chapter does not answer it. Second, write what each system can read and what it can write, so that the answer describes the access rather than the intention. Third, write who answers each question and who signs, because a questionnaire answered by several people without a signer is a questionnaire that will be answered twice. Fourth, answer in writing with what is true on the day, never with what is planned, because a planned feature is not a feature and a reviewer reads the difference. Fifth, keep the answers with their date and renew them when the integration changes, so that the next review starts from a document rather than from memory. The sequence is this book's own, no source read tests it, and security as a subject is Book K3's (Cybersecurity, Backups and Business Continuity). No figure is given.

4.4 The Listing: What a Marketplace Page Must Carry

The listing is the page on which a platform shows a complement, and it is the only part of the relationship that the platform's customers read before they decide. What a given platform requires of that page is the platform's own requirement, and the listing requirements page of one business-software marketplace was not read at its address for this book, so no platform's requirement is printed here. What follows is a checklist of this book's own reasoning, said to be its own, and it is written to be read beside whatever a program's own page asks.

The first element is what the integration does, in one sentence a customer can repeat. The second is what it does not do, because an honest page prevents a wrong expectation and a wrong expectation becomes a support call. The third is the data it moves, because the customer and the privacy officer read that line, and Chapter 7 reads what may travel. The fourth is who answers first when something fails, because a customer who does not know whom to call calls everyone. The fifth is the version and the date of the page, because a page is a promise of the day it was written and a page without a date is a promise of nothing.

The table below sets those five elements beside why each one matters and what the company's own page carries, posed by this book. Read it as a checklist for a page rather than a template for one: the elements are this book's own, the company's column is the case's, and no platform's requirement is reproduced.

Table 4.3 — What a listing page can carry, a checklist of this book

A page written this way does a second job that is easy to miss. It is the document the business reads when the integration changes, because a page that says what the integration does is a page that must be rewritten when the integration does something else. The version and the date are what make that possible, and they cost little to write.

In the case, posed by this book, the listing is approved on day 84, and its page says what the integration does and does not do. The page says that the integration opens one work order for each alert of a building whose manager enabled it, that it never carries the alert path and never sends a tenant's name, that it moves the building, the unit label, the sensor's location, the time and the severity, that the company answers first, and that the page carries its version and its date. The page is a page of the first platform's marketplace, and the company keeps a stored copy of its text with the version and the date, so that the next change is a change the business can see.

TOOLS OF THE TRADE What a business needs to keep a listing true: a stored copy, a version and date, a log of inquiries and a register

Four functions keep a listing true, and a business should look for them rather than for a product. The first is a stored copy of the listing text with its version and its date, so that a change to the page is a change the business can compare. The second is a log of the inquiries that the listing receives, with the date of each and what was asked, so that the page's effect is read as a count of inquiries rather than as a count of sales. The third is a calendar of the dates when the listing or the review is due, so that a renewal is a task with a date rather than a memory. The fourth is one register where the listing is written with its way out, so that the business knows what it does on the day the listing is removed or the program ends. Chapter 10 gives the functions in full. No brand name belongs on this list and no price; the requirement is the function.

4.5 Revenue Share, Listing Fees and Who Bills the Customer

The money question in a partner program has two parts, and they are easy to confuse. The first is what the platform keeps of a sale it processes. The second is who bills the customer at all. A platform may bill the customer for a digital purchase made through its own billing, act as the publisher's agent for a transactable offer, take a share of an app's revenue, or take nothing because the business invoices the customer itself. Each arrangement is the platform's own term on the day it is read, and none of them is a market rate.

The pages read for this chapter on October 15, 2026 describe four arrangements, each as that platform's term of that day. One app store's guidelines, last updated June 8, 2026 and read on October 15, 2026, require in-app purchase to unlock features or functionality (3.1.1), allow other purchase methods for certain apps (3.1.3), and allow a free stand-alone app that companions a paid web-based service to need no in-app purchase as long as it has no purchasing inside and no call to buy outside (3.1.3(f)) (Apple, 2026). The same store's small business program page, as of October 15, 2026, says that a developer with no more than 1 million USD of proceeds in the previous calendar year and the current year qualifies for a reduced commission of 15 percent on paid apps and in-app purchases, and that subscriptions after their first year pay 10 percent; the standard rate is named on the page but its percentage is not on the page (Apple, n.d.). The other store's service fees page, as of October 15, 2026, says that in the markets not yet moved to the new regional tier, 15 percent applies on the first 1 million USD of earnings a year and 30 percent above, with 15 percent on subscriptions, and that the regional tier splits a service fee and a billing fee of 5 percent by kind of install and transaction; it gives no fee on a service invoiced outside the store (Google, n.d.). A commerce platform's revenue share page, as of October 15, 2026, says 0 percent on the first 1 million USD of lifetime gross app revenue counted from January 1, 2025 and then 15 percent, with the 0 percent tier applying to developers under 20 million USD of app store revenue in the prior calendar year and under 100 million USD of company revenue, a one-time registration fee of 19 USD per Partner account, and a processing fee of 2.9 percent charged separately (Shopify, n.d.). The business marketplace's article, last updated July 23, 2026 and read on October 15, 2026, says a 3 percent standard store service fee is deducted at payout, with the platform acting as the publisher's agent for billing (Microsoft, 2026).

The table below sets four platform kinds beside what the page read says and what the page does not say, each as of October 15, 2026. Read it as four contracts of a day rather than as a comparison: the columns are the platform kind, the term as the page prints it, and the limit of the page. No row is a market rate, no row is stable, and no row is the case's.

Table 4.4 — Four platform kinds and their terms, as of October 15, 2026

Who bills the customer follows from the arrangement rather than from the fee. Where a digital purchase is made through a store's billing, the store's page prints a fee on that purchase. Where the business marketplace acts as the publisher's agent for a transactable offer, the platform bills and collects while the publisher remains the seller and licensor (Microsoft, 2026). Where a commerce platform takes a share of app revenue, its page prints the share and a processing fee charged separately, and the page read says no more about who bills. And where the business invoices the customer itself, no platform is in the payment path at all. A business should be able to say which of those describes its own arrangement, and to point to the page that says so.

In the case, posed by this book, the company invoices the building owner itself. The first platform's partner program asks an annual fee of $3,000, posed by this book, and no share of the subscriptions, and no real program's fee is presented as the case's. The mobile application is free and nothing is sold inside it, so the stores' commissions on digital purchases do not apply to it as the pages read on October 15, 2026 describe those commissions; a store's review decides, and this is not legal advice. Book F5 (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces) holds the listing, ranking, fees and marketplace economics, and Book L5 (Subscription and Recurring Revenue Models) holds the subscription itself.

THE RULE A fee is the platform's term as of the day read, with its page, and never a market rate (Shopify, n.d.)

The rule is this book's own and it is applied to every figure in this section. The revenue share page of a commerce platform, read on October 15, 2026, with no update date shown, says 0 percent on the first 1 million USD of lifetime gross app revenue counted from January 1, 2025 and then 15 percent, with a one-time registration fee per Partner account and a processing fee charged separately (Shopify, n.d.). That is that platform's term of the day read. It is never the case's term, never a market rate, and never stable: the page carries no update date, and a term without a date cannot be compared with the next one. A business prints a fee only with its page and the day it was read, and it writes beside it what the page does not say. No other figure is given here, and no fee of any program is presented as typical.

4.6 Co-Selling With the Platform's Sales Team

Co-selling is an arrangement in which the platform's sales team mentions or introduces a complementor to the platform's own customers. It is a benefit some programs describe and others do not, and no source read for this book describes a co-selling benefit, so none is printed or promised here. The business marketplace's article read for this chapter says no such thing. A program that offers co-selling describes it on the program's own page, and the description is read on the day it is read, like every other term.

What co-selling is not is worth stating plainly, because the word invites more than a page may say. On this book's reading, it is not a promise of introductions, a quota, a discount or a place in a sales team's pipeline, and it is not a substitute for the complementor's own selling: a business that stops selling because a program mentions co-selling has misunderstood the arrangement. Where a program does describe co-selling, a description worth reading says who may request it, what the platform's team does with a request, and what the complementor must supply, and these are read on the page rather than assumed.

The reason the distinction matters to a small business is that co-selling is a part of a partner program that is easy to imagine. A listing is visible and a fee is written down; co-selling happens inside another company's sales process, where the complementor cannot see it. A business that counts on introductions it has not been promised will build a forecast on nothing. A business that reads the program's page, finds no co-selling described, and plans its own selling accordingly has lost nothing and risked nothing.

Channel conflict is the neighboring question, and it belongs to Book F1 (Go-to-Market and Channel Strategy, chapter 6 of Book F1). A platform's program is one channel's door, and a business that sells through several channels reads the conflict between them there rather than here. The vendor's side of a partner program, including the mechanics of tiers and payouts, belongs to Book F9 (Building and Running a Partner Program), and this chapter cites that book rather than repeating it.

What a business can do with co-selling, in the absence of a benefit read, is to treat the platform's partner manager as a relationship rather than a pipeline. The partner manager is a role who works for the platform and never a person of the case, and the relationship is kept by a regular review in which the business reports what it has done and asks what the program has changed. That review is a task of the routine, and Chapter 8 sets it on the calendar. Nothing is credited to co-selling, and no introduction is assumed.

In the case, posed by this book, the first platform's partner manager holds a quarterly review with Karim Haddad, the head of sales and operations. The review covers the listing, the integration's health, the program's terms and any change the platform has announced. Nothing is credited to co-selling, because no co-selling benefit was read on the program's page, and the company's own selling continues unchanged. The review is one of the routine's lines, and its hours are counted in Chapter 8 rather than here.

4.7 Reviews, Ratings and Installs as Signals

Installs, reviews, ratings and badges are signals that a platform and a customer read, and a signal is not a cause. A count of installs says that customers use the integration; it does not say why they chose it, and it does not say whether the listing brought them. A review says what a customer thought; it does not say what share of customers thought it. A badge says that the platform's own review passed; it does not say that a certified app earns more, and the page that makes such a claim is a vendor's claim about its own program, which this book sets aside. An inquiry says that someone asked after reading the page; it does not say that the page caused the signature that followed.

The program page read for this chapter gives one threshold and no measure of quality. An app must have at least 3 active installs from real customers before submission (HubSpot, n.d.). That is the program's own requirement of the day read, and it is a threshold rather than a measure: three installs is what the program asks before it will look at an app, and it says nothing about whether the app is good. The same page's claims about the results of certified apps are set aside, and no figure from them is printed.

The research read for this chapter describes a badge on one platform and no software marketplace. The abstract of one study reports that on one microfinance platform, a badge certifying a subset of complementors led certified institutions to reorient their offer toward the certification, and those that aligned enjoyed stronger demand-side benefits, while the platform gained borrowers, lenders and funding (Rietveld et al., 2021, abstract only). That is one platform, in one industry, and it is an association rather than a rule. It supports one reading: a badge can change what a complementor does, and a business that aligns its offer to a badge depends on the badge's terms, which is a dependence Chapter 6 reads.

The table below sets four signals beside what each can mean, what each cannot show, and the company's own reading, posed by this book. Read it as a discipline for reading a listing's numbers: the columns are the signal, its possible meanings, its limits and the case's reading, and the row that says none is printed is a row where the case has no figure to give.

Table 4.5 — Four signals, what they can mean and what they cannot show

The discipline that keeps a signal honest is a sentence written beside it. The sentence says what the count is and what it is not. A count of inquiries is written as a count of inquiries, and the accounts that signed afterward are written as accounts that signed after an inquiry rather than as accounts the listing brought. The difference is not a matter of modesty; it is a matter of knowing what the business would do differently if the count changed.

In the case, posed by this book and told in Chapter 11, the listing has received 52 inquiries by day 365, and 11 accounts with 34 buildings have signed after an inquiry, which is 17.9 percent of the 190 new buildings of the year. Those accounts came after an inquiry, and nothing says that the listing caused those signatures. The company writes the sentence that way, and it credits no sale to the listing.

WATCH OUT A count of installs or inquiries is a signal, and a signature that follows an inquiry is not a signature the listing caused

The trap is the signal that becomes a cause. A count of installs or inquiries is credited with the sales that follow it, and the business then plans as though the listing produced customers. The signs are two: the words "thanks to the listing" in a report, and a share printed without its denominator, so that a reader cannot tell what the share is a share of. The remedy is a sentence, written beside the count, that says the accounts signed after an inquiry and that nothing says the listing caused the signatures. The case's 52 inquiries and 11 accounts with 34 buildings, posed by this book and told in Chapter 11, are written that way. The reasoning is this book's own, and no source read measures what share of a listing's inquiries becomes a customer. A business that writes the sentence keeps its planning honest, and it keeps the count useful.

4.8 Support Across Two Companies: Who Answers First

When an integration fails, the customer calls the company, and the platform's support may not know the integration exists. That is the ordinary shape of support across two companies, and the answer is written into the listing before the failure happens. The first answer is the company's. The company receives the call, says what it knows, and takes the customer's problem as its own until the problem is either fixed or handed to the platform with a name and a date. A failure on the platform's side is the platform's to fix, and the company says so to the customer in the same hour it reads it, rather than leaving the customer to discover it.

The reason the first answer is the company's is that the customer bought from the company. The customer's contract, the customer's invoice and the customer's expectation all point at the business that sold the integration, and a customer who is told to call the platform has been handed a second relationship that was never sold. The listing says who answers first, which is why section 4.4 puts that line on the page. A page that says the company answers first is a page that commits the company to answering first, and that commitment is worth making because the alternative is worse.

What the company needs in order to answer first is small. It needs a way to see whether the integration is working, which is the monthly health reading of Chapter 8. It needs a way to tell a failure of the integration from a failure of the platform, which is a matter of reading two logs rather than one. And it needs a sentence for the customer that says what is known, what is not known and when the customer will hear again. None of those requires a support team; they require a person and a habit.

In the case, posed by this book, the alert path never runs through the platform, so a failure of the integration or of the platform never silences an alert. The work order is a convenience, and if the platform fails, a work order is opened by hand from the alert email, which is the way out written in the dependence register of Chapter 6. The largest customer's operations manager, a role, receives the work orders, and the company's first answer covers the integration while the platform's own support covers the platform.

WHO DOES THIS The president answers the technical question first, and the head of sales and operations answers the account

Who answers first changes with the size of the business, and the shape of the answer does not. A solo owner answers everything, and the listing says so. In a small team, a developer answers the technical question and the owner answers the account, so that a customer with a technical problem is not routed through a sales conversation. In an established business, a support lead answers first and a partnerships manager takes the platform side, which is the division Chapter 9 sets out. In the case, posed by this book, Laurence Bergeron, the president, product and engineering, answers the technical question first, and Karim Haddad, the head of sales and operations, answers the account and speaks with the first platform's partner manager. The largest customer's operations manager, a role, receives the work orders. No hire is made, and no amount is promised to a reader.

4.9 Keeping the Customer Relationship While Listed

A listing carries the offer, and the business keeps everything else. What the business keeps is the customer's contract and the invoice, the customer's data, the alert path and the right to leave. What the listing carries is the offer and its page. The line between the two is the line between being a complementor and being a reseller of somebody else's relationship, and it is drawn by the business rather than by the platform.

The contract and the invoice are the clearest part. If the business invoices the customer, the business holds the commercial relationship, and the platform holds a listing. If the platform bills the customer, the platform holds the payment relationship, and the business holds a listing. Those are different positions, and the difference is read on the fee page rather than discovered later. A business that wants to keep the invoice says so in its own arrangements and reads the program's page to see whether the program takes the billing.

The data is the second part. An integration sends what a work order needs and nothing more, and the listing says what that is. The building, the unit label, the sensor's location, the time and the severity are what the case's integration sends, and no tenant's name travels. A business that sends more than the integration needs has widened the surface for no benefit, and Chapter 7 reads what may travel and under what conditions.

The alert path is the third part, and it is the part that must never depend on anyone else's uptime. In the case, every alert goes directly by text message and email, and the work order in the first property-management system is a convenience that may fail without silencing an alert. That arrangement is what makes the dependence register's ceiling meaningful, and it is the reason a platform's outage is an inconvenience rather than an incident.

The right to leave is the fourth part, and it is the one a business tests before it needs it. A business that can export its own data, keep its own customer list and open a work order by hand has a way out that does not depend on the platform's cooperation. Disintermediation, where a platform or a vendor bypasses the other, is Book A1's (From Idea to Business Model, chapter 6 of Book A1), and Chapter 6 of this book reads it from the complementor's side.

The research read for this chapter is worth recalling at its own level and no further. The abstract of one study reports that among 1,210 small independent software vendors from 1996 to 2004, joining a major platform owner's ecosystem was associated with higher sales and a greater likelihood of an initial public offering, more so for vendors with stronger intellectual property rights or downstream capabilities (Ceccagnoli et al., 2012, abstract only). That is an association among software vendors in one period, and it gives no gain to any reader. What it supports is a reading of this section: in that sample the association was stronger for vendors with stronger intellectual property rights or downstream capabilities of their own.

KEY CONCEPT A listing may carry the offer, and it must never carry the customer relationship, the invoice, the data or the alert path

The idea of this section is this book's own reading and never a finding of a source. A listing is a page on which a platform shows a complement, and it is good at that. It is not a place to keep a customer's contract, a customer's invoice, a customer's data or an alert path, because each of those is something the business needs on the day the listing is removed or the program ends. The business that keeps them has a way out that does not depend on the platform's cooperation, and it can leave the platform without leaving its customers. The association reported by the abstract of one study, among 1,210 small independent software vendors from 1996 to 2004, is an association among software vendors in one period and gives no gain for a reader (Ceccagnoli et al., 2012, abstract only). No other figure is given, and no result of the case is credited to the listing.

4.10 The Case's Listing and Certification Path

The path from the partner terms to an approved listing is counted in days, and every day of it is posed by this book and illustrative. The first platform's partner terms are read by the outside lawyer by day 21, and the decision is written on day 28: build the first integration, queue the second, and not now for the standard. The pilot is live on the largest customer's fourteen buildings on day 52, with one work order for each alert. The security questionnaire is answered by Laurence Bergeron, the president, product and engineering, and submitted on day 58. The listing is approved on day 84, and its page says what the integration does and does not do. The first platform's partner program asks an annual fee of $3,000, posed by this book, and no share of the subscriptions, and the company keeps invoicing the building owner.

Figure 4.1 follows the case from the partner agreement to an approved listing, day by day, and shows what the company keeps while listed.

Figure 4.1 — From the agreement to the listing. Terms read, a decision, a pilot, a security questionnaire and an approved listing by day 84; the company keeps the customer, the invoice, the alert path and its data (posed).

The figure is read step by step. The time line runs across ninety days and carries five steps. The first step is day 21, when the outside lawyer reads the agreement of the first platform's program. The second is day 28, when the decision is written. The third is day 52, when the pilot is live on the fourteen buildings of the largest customer, with one work order for each alert. The fourth is day 58, when the security questionnaire is answered and submitted. The fifth is day 84, when the listing is approved, with a page that says what the integration does and does not do. Below the time line, the figure shows what the company keeps while listed: the customer relationship and the invoice, since the program asks an annual fee of $3,000, posed by this book, and no share of the subscriptions; the alert path, which runs through no platform; and its own data, of which the integration sends only what a work order needs.

The table below gives the same path in rows, so that each step can be read aloud with its day. Read it as the case's own sequence, posed by this book, and not as a schedule any other business should follow: the days are the case's, the steps are the case's, and the terms of the first platform's program are the case's own posed terms rather than any real program's.

Table 4.6 — The case's path from the partner terms to the approved listing, posed by this book

The path points backward and forward in this book. The choice of the integration is Chapter 3's, and the grid of six criteria that produced the decision on day 28 is Chapter 3's. The company's own interface is Chapter 5's, the risks of dependence are Chapter 6's, the data and identity architecture is Chapter 7's, and the routine that keeps the listing and the integration alive is Chapter 8's.

CASE IN POINT Hydrosentinelle inc. reads the first platform's terms by day 21 and has an approved listing on day 84

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. The outside lawyer reads the partner terms of the first platform's program by day 21, and the decision is written on day 28: build the first integration, queue the second, and not now for the standard. The pilot is live on the largest customer's fourteen buildings on day 52, with one work order for each alert. Laurence Bergeron, the president, product and engineering, answers the security questionnaire and submits it on day 58. The listing is approved on day 84, with a page that says what the integration does and does not do. The program asks an annual fee of $3,000, posed by this book, and no share of the subscriptions, and the company keeps invoicing the building owner. Every day and every figure here is posed by this book and illustrative, and no sale, no customer and no growth is credited to the listing.

DO THE MATH From the terms read to the listing approved: the path in days

Illustrative figures; the case is fictional. Step 1 — The decision on day 28 comes 7 days after the terms read on day 21. Step 2 — The pilot is live on day 52, which is 24 days after the decision on day 28. Step 3 — The questionnaire is submitted on day 58, which is 6 days after the pilot on day 52. Step 4 — The listing is approved on day 84, which is 26 days after the questionnaire on day 58. Step 5 — Day 84 falls 6 days before the gate on day 90, and every day here is posed by this book and illustrative. The five steps are the case's own sequence, they are counted in days and never in calendar months, and no step is a duration any other business should expect.

IN LA MACHINE La Machine's partner pages serve the publisher's own programs, and it has no listing on another company's marketplace

In La Machine, as of the application copy of September 7, 2026, the pages that touch this chapter are Business → Partnerships → Program settings (business/partner-programs/settings), which holds the publisher's own partner programs, and the public page Earn Revenues → Partner (/become-partner), which takes an application with a typed signature and the version of the terms accepted. They serve the publisher's own programs, never the reader's: no real path links a subscriber to a partner's site, no revenue share is computed, and no interface identifier, single sign-on or webhook is given to a partner. Book F9 (Building and Running a Partner Program) holds partner programs. La Machine offers no listing on another company's marketplace and no tracking of a certification or a security review, and it offers no co-selling with a platform. Check it in your installation. The case does not use La Machine, and La Machine is described and never sold.

Costly Mistakes

• Building the integration before reading the partner agreement. A business that builds first and reads the terms afterward has already spent the money, and the terms it then reads are the terms it must accept or abandon.
• Treating a program's fee page as a market rate. A fee is the platform's own term on the day it was read, with its page; a fee printed without its page and its date cannot be compared with the next one.
• Answering a security questionnaire with what is planned. A planned feature is not a feature, and a reviewer reads the difference; the answers are written with what is true on the day and kept with their date.
• Writing a listing page that says only what the integration does. A page that omits what the integration does not do invites a wrong expectation, and a wrong expectation becomes a support call.
• Counting on co-selling that no page describes. Co-selling happens inside another company's sales process, and a business that forecasts introductions it has not been promised has built a forecast on nothing.
• Reading a count of installs or inquiries as a cause of the sales that follow. A signal says that something happened; it does not say why, and a share printed without its denominator tells a reader nothing.
• Letting the listing carry the customer relationship, the invoice, the data or the alert path. Each of those is something the business needs on the day the listing is removed, and a business that hands them to a page it does not control has handed over its way out.

Key Takeaways

• A platform partner program asks for a review, a track record, an agreement and sometimes a fee, and it gives a listing and sometimes tiers or a certification; every program is its own contract of the day, and the program of the vendor who runs one is Book F9's (Building and Running a Partner Program).
• The partner agreement is read before the listing, and the clauses to find are the notice a change of terms gets, the reasons and the appeal for a removal or a suspension, the termination, the clauses that refer to documents outside the agreement, and the fees; the Civil Code of Québec, up to date to August 12, 2026, frames the reading through the contract of adhesion, and Book H1 (Contracts and Commercial Agreements) and a lawyer hold the question.
• A security review checks what an integration can read and write and how its maker answers for it, a certification is a badge attached after a further review, and a business that aligns its offer to a badge depends on the badge's terms; security as a subject is Book K3's (Cybersecurity, Backups and Business Continuity).
• A listing page carries what the integration does, what it does not do, the data it moves, who answers first, and its version and date; the listing carries the offer, and the business keeps the customer relationship, the invoice, the data and the alert path.
• A fee is the platform's own term as of the day read, with its page, and never a market rate; who bills the customer follows from the arrangement, and a business should be able to point to the page that says which arrangement is its own.
• Installs, reviews, ratings, badges and inquiries are signals and never causes; the association reported by the abstract of one study, among 1,210 small independent software vendors from 1996 to 2004, is an association in one sample over one period and gives no gain to any reader (Ceccagnoli et al., 2012, abstract only).

Your Action Plan

1. Read the program's page and the partner agreement before you build anything. Write down what the program asks, what it gives, the notice a change of terms gets, the reasons and the appeal for a removal, the termination and the fees. Deliverable: a written reading of the program's page and the agreement, with the date of each page read. Verification: every clause you would need on the day the relationship ends is written down, and a lawyer has read the agreement where the stakes justify it.
2. Prepare the security questionnaire in the five steps of section 4.3. List the data the integration moves, write what each system can read and write, name who answers and who signs, answer with what is true on the day, and keep the answers with their date. Deliverable: a dated questionnaire with a named signer. Verification: every answer describes the integration as it is, and no answer describes a feature that does not exist.
3. Write the listing page with the five elements of section 4.4. Say what the integration does, what it does not do, the data it moves, who answers first, and the version and the date of the page. Deliverable: a listing text with its version and its date, and a stored copy. Verification: a customer who reads only the page knows what the integration does and whom to call.
4. Write the sentence that keeps a signal honest. Beside every count of installs, reviews or inquiries, write what the count is and what it is not, and never credit a signature to the listing. Deliverable: a written reading of the listing's signals with the sentence beside each count. Verification: no report of yours says that the listing brought a customer, and every share you print has its denominator.
5. Write the way out of the listing into the dependence register. Say what the business does on the day the listing is removed or the program ends, and check that the customer relationship, the invoice, the data and the alert path survive it. Deliverable: one register line for the listing, with its way out. Verification: the way out has been tested once, by exporting the data and opening a work order by hand.

In La Machine

In the application copy read on October 15, 2026, the pages that touch this chapter are Business → Partnerships → Program settings (business/partner-programs/settings), which holds the publisher's own partner programs, and the public page Earn Revenues → Partner (/become-partner), which takes an application with a typed signature and the version of the terms accepted (La Machine, 2026). They serve the publisher's own programs and never the reader's: no real path links a subscriber to a partner's site, no revenue share is computed, and no interface identifier, single sign-on or webhook is given to a partner. Book F9 (Building and Running a Partner Program) holds partner programs, and a business should check the pages in its own installation.

What a business needs for this chapter lives outside the product. La Machine offers no listing on another company's marketplace, no tracking of a certification or a security review, and no co-selling with a platform; it holds no place for a stored copy of a listing text with its version and date, no log of the inquiries a listing receives, and no register of the listings a business depends on with their way out. Those live in a spreadsheet, a document store or a tool the business chooses by function, and this book is valid with any tool. The case does not use La Machine, and the pages above are one worked example of a business platform, described and never sold.

Self-Check

1. What does a platform partner program ask of a complementor and what does it give, and why is each program its own contract of the day?
2. Which clauses are read in a partner agreement before the listing, and which book and which adviser hold the question of whether a clause is valid?
3. What does a security review check, what is a certification, and what does the research read for this chapter actually report about a badge?
4. What five elements can a listing page carry, and what does the business keep while listed?
5. Why is a count of installs or inquiries a signal rather than a cause, and what sentence keeps it honest?

Answers. 1. A program asks for a review, a track record, an agreement and sometimes a fee, and it gives a listing and sometimes tiers or a certification; each program is its own contract of the day because it is written by the platform for the platform's reasons and changes with notice, and the program of the vendor who runs one is Book F9's (Building and Running a Partner Program). 2. The clauses to find are the notice a change of terms gets, the reasons and the appeal for a removal or a suspension, the termination, the clauses that refer to documents outside the agreement, and the fees; the Civil Code of Québec, up to date to August 12, 2026, frames the reading through the contract of adhesion in articles 1379 and 1435 to 1437, and Book H1 (Contracts and Commercial Agreements) and a lawyer hold the question, which this book decides for no real agreement. 3. A security review checks what an integration can read and write and how its maker answers for it; a certification is a badge that a platform owner attaches to a complement after a further review; and the abstract of one study reports that on one microfinance platform a badge led certified institutions to reorient their offer toward the certification, with stronger demand-side benefits for those that aligned, which is one platform in one industry and an association rather than a rule (Rietveld et al., 2021, abstract only). 4. A listing page can carry what the integration does, what it does not do, the data it moves, who answers first, and its version and date; the business keeps the customer's contract and the invoice, the customer's data, the alert path and the right to leave. 5. A count says that something happened and not why, so a signature that follows an inquiry is not a signature the listing caused; the sentence that keeps it honest says what the count is and what it is not, and the case's 52 inquiries and 11 accounts with 34 buildings, posed by this book and told in Chapter 11, are written that way.

Chapter References

Apple. (2026). App Store Review Guidelines (last updated June 8, 2026). Apple Developer. Retrieved October 15, 2026, from https://developer.apple.com/app-store/review/guidelines/

Apple. (n.d.). App Store Small Business Program. Apple Developer. Retrieved October 15, 2026, from https://developer.apple.com/app-store/small-business-program/

Ceccagnoli, M., Forman, C., Huang, P., & Wu, D. J. (2012). Cocreation of value in a platform ecosystem: The case of enterprise software. MIS Quarterly, 36(1), 263–290. https://doi.org/10.2307/41410417

Civil Code of Québec, CQLR c CCQ-1991, arts. 1379, 1435, 1436 and 1437 (Québec). LégisQuébec, up to date to August 12, 2026 — read October 15, 2026. https://www.legisquebec.gouv.qc.ca/en/document/cs/CCQ-1991

Google. (2025). Google Play Developer Distribution Agreement (effective September 15, 2025). Retrieved October 15, 2026, from https://play.google/developer-distribution-agreement.html

Google. (n.d.). Service fees. Play Console Help. Retrieved October 15, 2026, from https://support.google.com/googleplay/android-developer/answer/112622?hl=en

Huang, P., Ceccagnoli, M., Forman, C., & Wu, D. J. (2013). Appropriability mechanisms and the platform partnership decision: Evidence from enterprise software. Management Science, 59(1), 102–121. https://doi.org/10.1287/mnsc.1120.1618

HubSpot. (n.d.). Technology partner program. Retrieved October 15, 2026, from https://www.hubspot.com/partners/technology

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: business/partner-programs/settings and /become-partner.

Microsoft. (2026). Microsoft Marketplace transact capabilities (last updated July 23, 2026). Microsoft Learn. Retrieved October 15, 2026, from https://learn.microsoft.com/en-us/partner-center/marketplace-offers/marketplace-commercial-transaction-capabilities-and-considerations

Regulation (EU) 2019/1150 of the European Parliament and of the Council of 20 June 2019 on promoting fairness and transparency for business users of online intermediation services, OJ L 186, 11.7.2019, p. 57, arts. 1, 3, 4, 8, 9 and 11 (European Union). Read October 15, 2026 through the Publications Office of the European Union (EUR-Lex answered 202 with an empty body). https://eur-lex.europa.eu/eli/reg/2019/1150/oj

Rietveld, J., Seamans, R., & Meggiorin, K. (2021). Market orchestrators: The effects of certification on platforms and their complementors. Strategy Science, 6(3), 244–264. https://doi.org/10.1287/stsc.2021.0135

Shopify. (n.d.). Revenue share [App distribution]. Shopify Dev Docs. Retrieved October 15, 2026, from https://shopify.dev/docs/apps/launch/distribution/revenue-share

Chapter 5 — Building Your Own Ecosystem

A small business that has plugged into other companies' systems may one day be asked to open its own, so this chapter says when a small firm should open its product to others and when it should not, how to design an interface that others can build on, how to make event notifications that others can rely on, which terms of use bind developers and integrators, how documentation, sandboxes and versions keep an interface usable, how developer relations work in a company without a developer team, how technology partners differ from selling partners, how access, quality and removal are governed, and how to measure an ecosystem without counting vanity.

What You'll Be Able to Do

• Decide whether a small firm should open its product to outside developers, by testing the four conditions this chapter sets and the three conditions under which it should not open.
• Design a first interface that is small, stable and narrow, and choose what it opens, how an integrator proves who it is, what its access may do and how fast it may call.
• Build event notifications that a receiver can rely on, with an identifier that does not change, a signature, a timestamp and a retry that is safe to repeat.
• Write terms of use that cover who may use the interface, what an integrator may do with the data, the limits, the removal of an integrator and the rotation of a key.
• Document and version an interface, with a description in a standard format, a sandbox and a numbered state on every change.
• Measure an ecosystem without counting vanity, by reading the few counts that show the interface is used and governed and by crediting them with no sale and no growth.

Why It Matters

A business that has spent a year reading other companies' terms and plugging into their systems reaches a point where the traffic runs the other way. A customer's own developer asks whether the company's product can send its alerts somewhere else, or a small software firm that serves the same buildings asks whether it can read the company's sensor list. The request is flattering and it is also a commitment, because an interface that a company documents and offers to approved outside developers must be described, kept working, signed, limited and governed, and every one of those acts costs hours that the same small team could spend elsewhere. The decision is therefore not whether to have an interface but whether this is the moment and whether this is the surface.

The reason the decision is worth a chapter, on this book's own reasoning, is that an interface opened too early is harder to close than to open. An integrator that has built on a promise the firm cannot keep has built a business on it, and the firm that withdraws the promise has to say so in writing, rotate a key and answer the questions that follow. An interface opened too late is a smaller loss: a customer who asked and was told no may ask again, and a firm that has not opened has lost nothing but the ask. The asymmetry is the reason this chapter puts the conditions before the design, and the reason it keeps the alert path outside every interface the company opens.

The cost of the work is real and it is small at the start. The case of this book, Hydrosentinelle inc., describes its first public interface by day 60 of the plan of Chapter 11 and approves two integrators by day 90, and the hours of that work sit inside the 99 hours of the plan and the 106 hours a year of the routine, both posed by this book. The interface is deliberately small: it opens reading and events and never the alert path, so that an integrator's failure or removal never silences an alarm. That choice is the spine of the chapter, and every section below returns to it.

In This Chapter

Section 5.1 says when a small firm should open its product to others and when it should not, and sets the frontier between this chapter and its neighbors. Section 5.2 designs an interface others can build on, with the four design choices a first interface makes. Section 5.3 builds event notifications that others can rely on, with the identifier, the signature, the timestamp and the retry. Section 5.4 covers the terms of use that bind developers and integrators. Section 5.5 covers documentation, sandboxes and versioning. Section 5.6 covers developer relations in a company without a developer team. Section 5.7 sets technology partners beside selling partners. Section 5.8 governs the ecosystem through access, quality and removal. Section 5.9 measures an ecosystem without counting vanity. Section 5.10 sets out the case's first public interface, version 1, posed by this book.

5.1 When a Small Firm Should Open Its Product to Others

A business that has spent a year plugging into other companies' systems may one day be asked to open its own, and the request arrives in a plain form: a customer's own developer asks whether the company's product can send its alerts somewhere else, or a small software firm that serves the same buildings asks whether it can read the company's sensor list. The question of this chapter is what a small firm does with that request.

The first thing to say is that opening an interface is a decision and not a feature. An interface that a company documents and offers to approved outside developers is a commitment: it must be described, kept working, signed, limited and governed, and every one of those acts costs hours that the same small team could spend elsewhere. The decision is therefore not whether to have an interface but whether this is the moment and whether this is the surface.

Three studies read at their abstracts bear on the question, and each of them is narrower than it sounds. The abstract of one study reports that in 21 handheld computing systems from 1990 to 2004, granting greater access to independent hardware developers was associated with up to a fivefold acceleration in new device development, while giving up control of the platform itself added a positive effect an order of magnitude smaller (Boudreau, 2010, abstract only). That is one industry and one period, and the association is not a cause. The abstract of a second work reports a formal model of code spillovers, in which a rising number of external developers can lead a firm to innovate through open external contracts rather than closed vertical integration, moving the locus of value creation outside the firm (Parker et al., 2017, abstract only). That is a model, and a model shows what follows from its assumptions; it measures nothing. The abstract of a third study reports that public firms that adopted public application programming interfaces grew an additional 38.7 percent over 16 years relative to similar non-adopters, with no significant effect from interfaces used only internally, that adopters which attracted more third-party complementors grew faster, and that public interfaces raised the risk of a data breach; the work was partly supported by two interface-management vendors (Benzell et al., 2024, abstract only). Those are public firms over 16 years, with funding stated, and the figure is never an expectation for a small private firm and never a cause for a reader's business.

Then the conditions. This book's own reading, and never a finding of a source, is that a small firm should open its product to others when four conditions hold together. First, customers or outside developers ask for access to its data or its events, and the ask is repeated rather than a single request. Second, the product is stable enough to be described: the objects it holds, the events it sends and the meaning of each have not changed in the recent past and are not expected to change every week. Third, the firm can govern what it opens: it can approve an integrator, limit what the integrator may do, watch what the integrator calls, and remove the integrator or rotate a key. Fourth, no critical path depends on the interface: the alert path of the business, above all, runs outside it, so that an integrator's failure or removal never silences an alert.

And when it should not open. This book's own reading is that a small firm should not open when the product changes every week, because an interface that changes every week cannot be documented or versioned honestly. It should not open when the firm cannot answer an integrator, because an unanswered question from an outside developer is worse than a closed interface: the integrator has built on a promise the firm cannot keep. And it should not open when opening would put the alert path or personal information at risk, because the value of the interface is never worth the loss of the path that carries the alarm.

The case, posed by this book, is a small firm that decides to open. Hydrosentinelle inc. designs and sells connected water-leak detectors for commercial and rental buildings, with two founders (Book A5). By day 60 of the plan of Chapter 11, the company describes its first public interface, and by day 90 it approves two integrators. The interface is small on purpose, and section 5.10 sets it out in full.

The table below sets the frontier of this chapter against its neighbors, so that a reader knows which book holds which question. It has three columns and five rows, and it is read row by row: the neighbor, what that neighbor holds, and what this chapter holds instead. Retain that this chapter opens an interface and builds no marketplace, and that the running of a platform business lies outside this book.

Table 5.1 — Where this chapter stops and its neighbors begin

DEFINITION The words this book uses for a public interface, an integrator, an approval, a version and a sandbox

These are this book's working words, and no source read defines them in this sense. A public interface is an interface that a company documents and offers to approved outside developers. An integrator is an outside business that builds on that interface for itself or for its customers. An approval is the company's written decision to let one integrator in under the terms of use. A version is a numbered state of the interface, changed only with a new number. A sandbox is a place where an integrator tries the interface with fake data. None of the five is a promise of a result, and none of them is a contract of adhesion that a platform imposes on the company; the terms the company writes are the company's own, and section 5.4 says what they cover. Interfaces and webhooks as integration concepts are Book K8's (chapter 2) and are not redefined here. The words are this book's own, and the case's interface is posed by this book.

5.2 Designing an Interface Others Can Build On

An interface that others build on is small, stable and narrow in what it lets an integrator do, and the first design choices are the ones that decide how much of the company's work the interface exposes. The four choices are what to open, how an integrator proves who it is, what its access may do, and how fast it may call.

The text read for this book on delegated access is the OAuth 2.0 authorization framework, read on October 15, 2026 at the level of its text, a Standards Track document updated by RFC 9700 among others. The framework lets a third-party application obtain limited access to an HTTP service, either on behalf of a resource owner through an approval interaction, or on its own behalf (Hardt, 2012). That is what the text says, and it says nothing about any security practice beyond its own text.

The security practice comes from a second text, the best current practice for OAuth 2.0 security, read on October 15, 2026. It says that redirection addresses are compared by exact string, except the port numbers of localhost redirection addresses of native apps; that public clients must use proof key for code exchange; that the implicit grant should not be used; that access tokens should be restricted to the minimum privileges and to a specific resource server; and that the resource owner password credentials grant must not be used (Lodderstedt et al., 2025). Those are practices of a specification and never a rule of law.

The limit on how fast an integrator may call comes from a third text, the additional HTTP status codes, read on October 15, 2026 at its section 4. Status 429 means too many requests in a given time; the response should explain the condition and may carry a Retry-After header; the specification does not define how a server counts requests and gives no particular limit (Nottingham & Fielding, 2012). The number a company chooses is therefore the company's own, and the case's 120 requests a minute is posed by this book.

The design of a boundary resource is studied in one case. The abstract of a study reports that boundary resources such as application programming interfaces are designed and used under two drivers, resourcing and securing, shown in a case study of one smartphone platform; the conflict is between keeping control of the platform and transferring design capability to third-party developers (Ghazawneh & Henfridsson, 2013, abstract only). That is one case study and it measures no effect, and it is recalled again in section 5.5.

The case, posed by this book, makes the four choices in a small form. Version 1 opens read access to buildings, sensors and alerts and two events, with client credentials for each approved integrator, a limit of 120 requests a minute for each integrator, a sandbox and written terms of use. The interface opens reading and events and never the alert path. Delegated access and its security practice are told again in Chapter 7, the choice of what to plug into is Chapter 3, and the listing in a platform's program is Chapter 4.

The table below sets the four design choices beside what each means, what the text read says about it and the company's own choice, posed by this book. It has four columns and four rows, and it is read row by row: the choice, its meaning, the text, and the case. Retain that the text read gives no number for a limit and no rule of law, and that every figure in the last column is the case's own.

Table 5.2 — Four design choices for a first interface, with the text read and the company's choice

KEY CONCEPT A first interface is small on purpose: it opens reading and events, and never the alert path

This is the idea of the section, and it is this book's own reading and never a finding of a source. A small surface is easier to document, easier to sign, easier to limit and easier to remove than a large one, and the four design choices of the section are all made smaller by it. The case opens read access to buildings, sensors and alerts and two events, and it keeps every alert outside any platform and any integrator, so that an integrator's failure or removal never silences an alarm. The figure of section 5.10 shows the three columns of that interface: what it opens, who gets in, and the rules that govern it. The choice is not a claim about what an interface brings; it is a statement about what the company is willing to keep working, to sign and to withdraw. No source read measures what a small surface earns, and the case's interface is posed by this book.

5.3 Event Notifications Others Can Rely On

An event is a message that the company sends when something happens, and a receiver can rely on it only if each event has an identifier that does not change, a signature that proves who sent it, a timestamp that bounds a replay and a retry that is safe to repeat. The notion of a webhook as an integration concept is Book K8's (chapter 2), and this section builds the properties a receiver depends on.

The first property is the identifier. The community specification read for this book on October 15, 2026, version 1.0.0, says that the identifier stays unchanged across retries and that it serves as an idempotency key (Standard Webhooks, n.d.). It is a community specification and not a standards body's, and it gives no requirement of law. The notion of an idempotent method comes from a second text, the HTTP semantics, read on October 15, 2026 at its section 9.2.2, an Internet Standard: a method is idempotent if several identical requests have the same intended effect on the server as one; PUT, DELETE and the safe methods are idempotent; and a client should not automatically retry a non-idempotent request unless it knows the semantics are idempotent or can detect that the original was never applied (Fielding et al., 2022). That text says nothing about webhook practice.

The second property is the signature. The community specification says that the signed content is the identifier, the timestamp and the body joined by full stops, with HMAC-SHA256 or an asymmetric signature, and that a signature list allows key rotation (Standard Webhooks, n.d.). The third property is the timestamp: a consumer rejects a timestamp outside a tolerance, for which the specification gives no value. The fourth is the retry: retries span several days with exponential backoff, and an example schedule reaches about three days. The fifth is the answer code: a consumer answers 2xx for success and 410 to stop deliveries.

The case, posed by this book, sends two events in version 1: leak.detected and sensor.offline. Each is signed with a hash-based message authentication code, HMAC-SHA256, over the identifier, the timestamp and the body, and each event has an identifier, so that a repeated delivery never opens a second work order. On day 365, posed by this book, 1,240 alert events were relayed, 1,231 on the first attempt and 9 after retries, with 0 duplicate work orders. The alert path itself never runs through the interface: an alert goes by text message and by email directly, and the events of the interface are a convenience that may fail without silencing an alert.

The table below sets five properties of a reliable event beside what each means, where it is read and the company's own events, posed by this book. It has four columns and five rows, and it is read row by row: the property, its meaning, the text, and the case. Retain that the specification gives no tolerance value and no requirement of law, and that the case's counts are posed.

Table 5.3 — Five properties of a reliable event and the company's events

THE RULE An event that can be retried must carry an identifier that does not change (Standard Webhooks, n.d.)

The rule comes from the community specification read on October 15, 2026, version 1.0.0: the identifier stays unchanged across retries, it serves as an idempotency key, and the signed content is the identifier, the timestamp and the body joined by full stops (Standard Webhooks, n.d.). It is a community specification and not a standards body's, and it gives no requirement of law. The rule matters because a retry is a copy of an event and not a new event, and a receiver that cannot tell the two apart will act twice on one happening. The case applies the rule in a small form, posed by this book: each event of version 1 has one identifier, and a repeated delivery never opens a second work order. The rule is stated here as the specification states it and is never applied to a reader's own interface, which is a question for the reader's own documents and, where a contract is involved, for Book H1 (Contracts and Commercial Agreements) and a lawyer.

5.4 Terms of Use for Developers and Integrators

Terms of use are a contract that the company writes and an integrator accepts, and they are the instrument that turns an interface from a technical object into a governed one. This section rests on this book's own reasoning, said to be its own, and on the books that hold the law: the contract is Book H1's (Contracts and Commercial Agreements) with a lawyer, the intellectual property of the interface, its documents and its terms is Book H5's (Intellectual Property), and personal information that an integration touches is Book H2's (Privacy and Personal Information), which section 7.7 of this book also reads. This chapter reads no text of law and rewrites none.

What written terms of use cover, in this book's own words, is six topics. The first is who may use the interface and how access is approved: the application an integrator makes, the reading the company gives it, and the written acceptance that follows. The second is what an integrator may do with the data and what it may never do: which objects it may read, which events it may receive, whether it may store them, and whether it may pass them to a third party. The third is the limits and the right of the company to change the interface with notice: the rate limit, the versioning rule, and the notice the company gives before a change that breaks an integrator. The fourth is what the company answers for and what it does not: the availability it promises, the failures it does not promise to prevent, and the fact that the alert path of the business does not run through the interface. The fifth is the removal of an integrator and the rotation of a key: the grounds for removal, the warning that precedes it where the circumstances allow, and the rotation of a credential. The sixth is the ownership of what each side builds: the interface and its documents on one side, and the integrator's own product on the other.

The case, posed by this book, has the outside lawyer draft the terms of use of the public interface, in hours at Book F9's illustrative rate of $300 an hour (Chapter 11), and each approved integrator accepts them in writing. The terms are drafted before the first approval, so that the removal of an integrator and the rotation of a key are written before they are needed, which is the remedy of section 5.8.

QUÉBEC & CANADA NOTE Terms of use for an interface are a contract and a question of intellectual property, held by other books, and this chapter rewrites none of it

The Québec and Canadian point of this section is that the terms of use of an interface are read through three books of this library and never through this chapter. The contract that the company writes and an integrator accepts is Book H1's (Contracts and Commercial Agreements), read with a lawyer, and the contract of adhesion and its external, illegible and abusive clauses are Book H1's as well. The intellectual property of the interface, of its documents and of its terms is Book H5's (Intellectual Property). Personal information that crosses an interface is Book H2's (Privacy and Personal Information), which section 7.7 of this book also reads. This chapter reads no text of law and rewrites none, and it decides nothing about whether a given set of terms complies with any rule. The book recommends no vendor, no platform, no integrator and no adviser, and a business with a question about its own terms should ask a lawyer.

5.5 Documentation, Sandboxes and Versioning

Documentation is the first boundary resource an integrator sees, and it is the part of the work that decides whether an outside developer can build without asking a question. The boundary resources model read for this book, at its abstract only, reports that boundary resources such as application programming interfaces are designed and used under two drivers, resourcing and securing, shown in a case study of one smartphone platform (Ghazawneh & Henfridsson, 2013, abstract only). This book's own reading, never a finding of the study, is that documentation is the resourcing side of that pair and that the terms of use of section 5.4 are the securing side.

A description written in a standard format can be read by people and by computers. The specification read for this book on October 15, 2026 is the OpenAPI Specification version 3.2.1 of September 10, 2026, and it describes a standard, programming-language-agnostic description of HTTP interfaces that lets people and computers discover what a service can do without its source code, other documentation or traffic inspection; the description has a field for the webhooks a consumer may receive (OpenAPI Initiative, 2026). The specification says nothing about any tool that renders it, and this chapter names none.

A sandbox gives an integrator a place to try an interface with fake data, so that the integrator never touches a customer's buildings or a tenant's information while building. The sandbox is not a second interface: it is the same interface, pointed at data that belongs to nobody, and its purpose is to let an integrator make mistakes where a mistake costs nothing.

Every change to the interface carries a version number, so that an integrator is never surprised. A version is a numbered state of the interface, changed only with a new number, and the rule the company writes is that a change which breaks an integrator is a new version and never a silent edit. The case, posed by this book, describes the interface in its first version by day 60, with a sandbox and a version number on every change.

TOOLS OF THE TRADE What a business needs to document and test an interface: a description, a sandbox, a test client and a register of versions

Four functions carry the documentation of an interface, and a business should look for them rather than for a product. The first is a description of the interface in a standard format that a person can correct, so that the document is written once and read by people and by computers. The second is a sandbox with fake data, so that an integrator can build without touching a customer's buildings or a tenant's information. The third is a test client that calls the interface, so that the company can check a change before an integrator meets it. The fourth is a register of versions with their dates, so that an integrator can see what changed and when. Chapter 10 gives the functions in full, and no brand name and no price belongs on this list. The requirement is the function, and a business that has none of the four can still open a small interface with a written document and a test account.

WHAT CHANGED The OpenAPI Specification stands at version 3.2.1 of September 10, 2026 (OpenAPI Initiative, 2026)

The dated change comes from the specification read on October 15, 2026: the page read shows version 3.2.1 of September 10, 2026, a standard, programming-language-agnostic description of HTTP interfaces that lets people and computers discover what a service can do without its source code, other documentation or traffic inspection, and the description has a field for the webhooks a consumer may receive (OpenAPI Initiative, 2026). The version is that of the day read and it will change; the date is the specification's own and never a date of the case. A company that writes its description in this format writes it once and reads it with any tool that understands the format, and a company that writes its description in a plain document writes it once and reads it by hand. The specification says nothing about any tool that renders it, and this chapter names none and recommends none.

5.6 Developer Relations in a Company Without a Developer Team

Developer relations is the work of answering an integrator, keeping the documents true and telling integrators what will change. It is not a department and it is not a role that a small firm hires for; it is a named person, a written answer time and a habit of telling integrators about a change before the change arrives.

The model of external developers read for this book, at its abstract only, shows how a rising number of external developers can lead a firm to innovate through open external contracts rather than closed vertical integration, moving the locus of value creation outside the firm (Parker et al., 2017, abstract only). It is a model and it measures nothing, and it is recalled here only as the abstract states it. This book's own reading, never a finding of the model, is that the more an outside developer builds on the interface, the more the company's own roadmap is shaped by what the developer needs.

The signals an operator sends are studied on one platform. The abstract of a study reports that on one open geodata platform, opportunity signals and endorsement signals from the operator influenced the volume and diversity of content contributed by complementors (Hukal et al., 2020, abstract only). That is one open platform and never a commercial platform, and it measures no effect for a reader. This book's own reading, which the study does not test for a company like this one, is that what the company says it wants, and whom it endorses, shapes what outsiders build, so that a company that says nothing gets what it did not ask for.

A company without a developer team does three things. It names one person who answers an integrator, and it writes an answer time, so that an integrator knows when to expect a reply. It keeps the documents true, by reading them against the interface on a fixed day and correcting them where they have drifted. And it tells integrators what will change, by writing to the approved integrators before a new version, so that no integrator meets a change by surprise. The case, posed by this book, has Laurence Bergeron hold the relationship with the integrators and review the public interface and its integrators every quarter (Chapter 8).

WHO DOES THIS One named person holds the relationship with the integrators, and in the case it is the president

The roles below are the case's, posed by this book. In a solo business the owner does developer relations alone and keeps a short list of integrators, with the documents read against the interface once a quarter. In a small team one developer answers the integrators and the owner approves the terms, so that the technical answer and the contractual answer come from two people. In an established business a product lead and a partnerships manager share the work, and Chapter 9 reads the roles behind platform work. In the case, posed by this book, Laurence Bergeron answers the integrators and Karim Haddad approves the terms with the outside lawyer. No hire is made for this work, and no dollar is spent on it beyond the hours already counted. The work is small and it is named, and a company that leaves it unnamed leaves an integrator unanswered.

5.7 Technology Partners Beside Selling Partners

A selling partner brings customers and a technology partner builds on the interface, and the two are different programs with different terms, different approvals and different things the company keeps. This section rests on this book's own reasoning, said to be its own, and on Book F9 (Building and Running a Partner Program), which holds the company's program of plumbers and installers.

Book F9's program is unchanged by this chapter. Ten partners are active, seven referral and three certified installers, a partner is not an employee, and no hire was made (Book F9). Book F9 holds the mechanics of any partner program, its tiers and its payouts, and this chapter calls Book F9 for those mechanics and adds a technical program for integrators on the public interface. The two programs sit beside each other and neither replaces the other.

What a selling partner does is bring customers: a referral partner introduces a building owner, and a certified installer installs the sensors and the gateway. What a technology partner does is build on the interface: an integrator reads the buildings, the sensors and the alerts, and receives the two events of version 1. How a selling partner is approved is by the terms of the program of Book F9; how a technology partner is approved is by written terms of use and an approval, and the case, posed by this book, approves two integrators by day 90. What a partner is, in both programs, is an outside business and never an employee. What the company keeps differs: from the selling program it keeps the customer relationship and the invoice, and from the technical program it keeps the interface and its governance, the alert path and the fact that no hire was made.

The publisher's own partner pages in La Machine serve the publisher's programs and never the reader's, and section 5.10 says so in one sentence. Book F2 (OEM Partners and White-Label Programs) holds original equipment manufacturer and white-label programs and the dependence ceiling of a partner, and this chapter does not read them.

The table below sets the two kinds of partner side by side, so that a reader sees what each does, how each is approved, what each is and what the company keeps. It has four columns and four rows, and it is read row by row: the aspect, the selling partner, the technology partner and the company's own position, posed by this book. Retain that the two programs are different and that neither is a hire.

Table 5.4 — Selling partners and technology partners side by side

5.8 Governing the Ecosystem: Access, Quality and Removal

Governing an ecosystem is three acts, and each of them is written in the terms of use before it is needed: approving who gets in, reading quality, and removing an integrator that breaks the terms. A company that opens an interface without the third act has given its control away, and, on this book's own reasoning, the trap is easy to fall into because the first two acts are the pleasant ones. The risks of depending on a platform's terms are Chapter 6, and this section reads the company's own side of the arrangement.

The construct of perceived openness is studied from the developers' side. The abstract of a study reports a multidimensional construct of perceived platform openness, from the application developers' perspective, validated in two smartphone platform contexts and linked to developers' continued contributions (Benlian et al., 2015, abstract only). That is two smartphone platform contexts and it gives no threshold of openness, and it measures no effect for a reader. The construct is openness as the developer perceives it, and this book's own reading, never a finding of the study, is that a company that approves an integrator and then answers no question may be perceived as closed whatever its terms say.

The signals an operator sends are recalled from section 5.6: on one open geodata platform, opportunity signals and endorsement signals from the operator influenced the volume and diversity of content contributed by complementors (Hukal et al., 2020, abstract only). That is one open platform and never a commercial platform.

Approving who gets in is a written application, a reading of the integrator's purpose and security, and a signed acceptance of the terms. Reading quality is watching the errors, the misuse of limits and the complaints, on a fixed day, so that a problem is seen before it becomes a removal. Removing is a warning, a suspension of access, the rotation or revocation of a key, and the removal of an integrator, each written in the terms of use before it is needed. The case, posed by this book, approves two integrators under written terms of use on days 75 and 88; on day 365 four integrators use the public interface, one key has been rotated and no integrator has been removed.

WATCH OUT An interface that cannot remove an integrator or rotate a key has given its control away

The trap of this section is opening an interface before writing how access is withdrawn. The signs are plain: terms of use that do not mention removal, and a credential that was never planned to expire. A company that opens in that state has handed an integrator a permanent seat, and the company discovers it on the day the integrator misuses the interface and there is no clause to point to and no key to rotate. The remedy is small and it is written before the first approval: the terms of use say on what grounds an integrator is removed, what warning precedes a removal where the circumstances allow, and how a key is rotated or revoked. The case, posed by this book, drafts the terms with the outside lawyer before the first approval, and on day 365 one key has been rotated and no integrator has been removed. The reasoning is this book's own, and whether a given set of terms is enforceable is a question for Book H1 (Contracts and Commercial Agreements) and a lawyer.

5.9 Measuring an Ecosystem Without Counting Vanity

A vanity count is a number that rises without telling whether the interface is used or governed. Sign-ups that never build anything, and calls that have no outcome, are two examples of the vanity counts of an interface, and both of them rise on their own. A business measures instead the few counts that show use and governance, and it credits them with no sale and no growth.

The study of public interfaces read for this book, at its abstract only, is recalled from section 5.1: public firms that adopted public application programming interfaces grew an additional 38.7 percent over 16 years relative to similar non-adopters, adopters that attracted more third-party complementors grew faster, and public interfaces raised the risk of a data breach; the work was partly supported by two interface-management vendors (Benzell et al., 2024, abstract only). Those are public firms over 16 years, with funding stated, and the figure is never an expectation for a reader and never a cause for a reader's business. This book's own reading, never a finding of the study, is that the counts worth reading are the ones that show whether integrators are actually building, and that the risk of a breach is worth watching beside them.

The few counts that show use and governance are these: the approved integrators, the integrations in use, the events delivered, the duplicates, the keys rotated and the integrators removed. Each of them is a count of a fact, and none of them is a promise. The case, posed by this book and told in Chapters 7 and 11, reads them on day 365: four integrators use the public interface, 1,240 alert events were relayed, 1,231 on the first attempt and 9 after retries, with 0 duplicate work orders, one key was rotated and no integrator was removed. Nothing is credited to the interface, and no sale and no customer is attributed to it.

METHOD Measuring an ecosystem without counting vanity in five steps

First, write what the interface is for, in one sentence, so that a count can be read against a purpose. Second, choose the few counts that show it is used and governed: the approved integrators, the integrations in use, the events delivered, the duplicates, the keys rotated and the integrators removed. Third, read them on a fixed day each quarter, beside the review of the public interface and its integrators that Chapter 8 sets. Fourth, never credit the counts with sales or growth, because no count of an interface is a sale and no source read measures what an interface earns. Fifth, drop any count that nobody acts on, so that the reading stays short enough to be read. The sequence is this book's own, no source tests it, and the case's counts are posed by this book. A count that rises while nobody acts on it is a vanity count whatever it measures.

5.10 The Case's First Public Interface

The case's first public interface is small on purpose, and this section sets it out in full. Version 1 is described by day 60 of the plan of Chapter 11, posed by this book: read access to buildings, sensors and alerts; two events, leak.detected and sensor.offline; client credentials for each approved integrator; a limit of 120 requests a minute for each integrator; a sandbox; written terms of use drafted with the outside lawyer; events signed with a hash-based message authentication code, HMAC-SHA256, over the identifier, the timestamp and the body; two integrators approved on days 75 and 88, which is two on day 90, and four on day 365. The interface opens reading and events and never the alert path.

The table below sets out the elements of version 1 beside what each holds and why, posed by this book. It has three columns and six rows, and it is read row by row: the element, what version 1 holds and the reason. Retain that every element is small, that access is a decision and that the interface can be withdrawn.

Table 5.5 — The case's first public interface, version 1, posed by this book

Figure 5.1 sets out the case's first public interface: what it opens, who gets in, and the rules that govern it. The figure has three columns. The first column, what it opens, shows read access to buildings, sensors and alerts and two signed events, leak.detected and sensor.offline. The second column, who gets in, shows approved integrators only, each with its own client credentials, two approved on day 90 and four on day 365. The third column, the rules, shows a limit of 120 requests a minute for each integrator, answered with the status for too many requests; a version number on every change; a sandbox; written terms of use drafted with the outside lawyer; and the removal of an integrator that breaks the terms. A note at the foot of the figure says that the interface is small on purpose: it opens reading and events, never the alert path and never a write into a customer's building, and a larger interface waits for the yearly reset of the roadmap that Chapter 8 sets. Every element of the figure is posed by this book.

Figure 5.1 — A small interface, governed. Reading and two signed events, approved integrators only (2 on day 90, 4 on day 365), 120 requests a minute each, numbered versions and written terms of use (posed).

In La Machine, as of the application copy of September 7, 2026, the pages that touch this chapter are Control center → Workflows (/registre), a register of workflows and agent routes with their trigger and state; Support → Plans & Pricing (plans), which lists API access and single sign-on among the features of some plans although the copy read has no screen for either; the public page Products → For Partner Websites (/products/partners), which announces features that have no screen in the copy read; and the publisher's partner pages, Business → Partnerships → Program settings (business/partner-programs/settings), Business → Partnerships → Applications (business/partner-programs/applications) and Earn Revenues → Partner (/become-partner), which serve the publisher's own programs. It offers no documented public interface, no user-managed interface key, no webhook a user can configure, no single sign-on, no connector marketplace and no listing on another company's marketplace; check it in your installation. Every fact holds in the application copy of September 7, 2026, read in its code on October 15, 2026. The case does not use La Machine; this book is valid with any tool; La Machine is described and never sold.

CASE IN POINT Hydrosentinelle inc. describes a small public interface on day 60 and approves two integrators by day 90

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. Version 1 of the public interface, posed by this book, opens read access to buildings, sensors and alerts and two signed events, leak.detected and sensor.offline, with client credentials for each approved integrator, a limit of 120 requests a minute for each integrator, a sandbox and written terms of use. The interface is described by day 60, and two integrators are approved on days 75 and 88, which is two on day 90. Laurence Bergeron holds the relationship with the integrators, and the outside lawyer drafts the terms of use. The interface opens reading and events and never the alert path, so that an integrator's failure or removal never silences an alarm. No sale, no customer and no growth is credited to the interface, and every figure here is posed by this book and illustrative.

DO THE MATH Five things opened, 120 requests a minute for each integrator: the interface in numbers

Illustrative figures; the case is fictional. Step 1 — Version 1 opens three kinds of read access, buildings, sensors and alerts, and two events, which are five things opened. Step 2 — Each approved integrator may call at most 120 requests a minute. Step 3 — The two integrators approved by day 90 can together call at most twice that limit. Step 4 — The four integrators of day 365 can together call at most four times that limit. Step 5 — One key was rotated and no integrator was removed by day 365, and every count here is posed by this book and illustrative. The limit is the company's own and not a number any specification gives, and nothing in these five steps is a result credited to the interface or a measure of how much it is used.

IN LA MACHINE La Machine's plans page lists interface access without a screen, and its partner pages serve the publisher's own programs

In the application copy read on October 15, 2026, there is no documented public interface, no interface key a user manages, no webhook a user configures and no single sign-on (La Machine, 2026). Control center → Workflows (/registre) shows one line for each workflow or agent route, with only its state editable and no owner column, and it can serve as a model for a register of integrations. Support → Plans & Pricing (plans) lists API access and single sign-on among the features of some plans although the copy read has no screen for either. The public page Products → For Partner Websites (/products/partners) announces an interface, components, single sign-on, isolation, a dashboard and webhooks that have no screen in the copy read, a gap between the announcement and the copy read. Business → Partnerships → Program settings (business/partner-programs/settings), Business → Partnerships → Applications (business/partner-programs/applications) and Earn Revenues → Partner (/become-partner) serve the publisher's own partner programs, never the reader's. Check it in your installation; the case does not use La Machine, and La Machine is described and never sold.

Costly Mistakes

• Opening an interface because a customer asked once. A single request is not a repeated ask, and an interface opened on one request is a commitment the firm may not be able to keep.
• Opening a product that changes every week. An interface that changes every week cannot be documented or versioned honestly, and an integrator that builds on it builds on sand.
• Letting a critical path run through the interface. An alert that depends on an integrator's availability is an alert that can be silenced by a failure the company does not control.
• Writing terms of use that do not mention removal or rotation. A company that opens without a way to withdraw access has handed an integrator a permanent seat and discovers it on the day the integrator misuses the interface.
• Counting sign-ups and calls as if they were use. A vanity count rises on its own and tells nothing about whether the interface is used or governed.
• Leaving developer relations unnamed. An unanswered question from an outside developer is worse than a closed interface, because the integrator has built on a promise the firm cannot keep.
• Crediting the interface with sales or growth. No source read measures what an interface earns, and a count of an interface is never a sale.

Key Takeaways

• A small firm should open its product to others when four conditions hold together — customers or outside developers ask repeatedly, the product is stable enough to be described, the firm can govern what it opens, and no critical path depends on the interface — and it should not open when the product changes every week, when it cannot answer an integrator, or when opening would put the alert path or personal information at risk.
• A first interface is small on purpose: it opens reading and events and never the alert path, and its four design choices are what to open, how an integrator proves who it is, what its access may do and how fast it may call.
• An event that a receiver can rely on carries an identifier that does not change, a signature, a timestamp and a retry that is safe to repeat, and the community specification read for this book gives no tolerance value and no requirement of law (Standard Webhooks, n.d.).
• Terms of use are a contract that the company writes and an integrator accepts, and the contract is Book H1's (Contracts and Commercial Agreements) with a lawyer, the intellectual property of the interface is Book H5's (Intellectual Property), and personal information that crosses an interface is Book H2's (Privacy and Personal Information).
• Governing an ecosystem is three acts written before they are needed — approving who gets in, reading quality, and removing an integrator that breaks the terms — and a company that cannot remove an integrator or rotate a key has given its control away.
• A business measures an ecosystem by the few counts that show use and governance — approved integrators, integrations in use, events delivered, duplicates, keys rotated and integrators removed — and it credits them with no sale and no growth.

Your Action Plan

1. Test the four conditions before opening anything. Write, in one page, whether customers or outside developers ask repeatedly for access, whether the product is stable enough to be described, whether the firm can approve, limit and remove an integrator, and whether any critical path would run through the interface. Deliverable: a one-page decision with the four conditions answered. Verification: every condition is answered yes or no, and a no on the fourth condition stops the work until the path is moved.
2. Choose the smallest surface that serves the ask. Write what the interface opens, how an integrator proves who it is, what its access may do and how fast it may call, and keep the alert path outside it. Deliverable: a written design of version 1 with its four choices. Verification: the design names what it opens and what it does not, and no alert depends on it.
3. Write the terms of use before the first approval. Cover who may use the interface, what an integrator may do with the data, the limits and the notice of a change, what the company answers for, the removal of an integrator and the rotation of a key, and the ownership of what each side builds. Deliverable: written terms of use, read with a lawyer. Verification: the terms name removal and rotation, and the first integrator accepts them in writing.
4. Document, sandbox and version the interface. Write the description in a standard format that a person can correct, open a sandbox with fake data, keep a test client that calls the interface, and put a version number on every change. Deliverable: a description, a sandbox, a test client and a register of versions. Verification: an integrator can build against the sandbox without touching a customer's data, and every change carries a number.
5. Name the person who answers integrators and read the counts each quarter. Name one person, write an answer time, and read the few counts that show use and governance on a fixed day each quarter, crediting them with no sale and no growth. Deliverable: a named person, a written answer time and a quarterly reading of the counts. Verification: every approved integrator has an answer within the written time, and no count is reported as a sale.

In La Machine

In the application copy read on October 15, 2026, the pages that touch this chapter are Control center → Workflows (/registre), which shows one line for each workflow or agent route, with its trigger and state, and only the state can be changed on the screen (La Machine, 2026). It can serve as a model for a register of integrations, and it holds no owner column. Support → Plans & Pricing (plans) lists API access and single sign-on among the features of some plans, although the copy read has no screen for either. The public page Products → For Partner Websites (/products/partners) announces an interface, components, single sign-on, isolation, a dashboard and webhooks, and none of them has a screen in the copy read. The publisher's partner pages, Business → Partnerships → Program settings (business/partner-programs/settings), Business → Partnerships → Applications (business/partner-programs/applications) and Earn Revenues → Partner (/become-partner), serve the publisher's own programs, never the reader's.

What a business needs for the subject of this chapter lives outside the product. La Machine offers no documented public interface, no interface key a user manages, no webhook a user configures, no single sign-on, no provisioning of users, no connector marketplace and no listing on another company's marketplace, so the interface a company opens to its own integrators, its description, its sandbox, its version register and its terms of use are kept in the company's own documents and tools, chosen by function. The case does not use La Machine (Books G8, I8 and L5), this book is valid with any tool, and La Machine is described and never sold; check it in your installation.

Self-Check

1. What are the four conditions under which a small firm should open its product to others, and the three under which it should not?
2. What are the four design choices of a first interface, and what does the text read say about each?
3. What five properties make an event one that a receiver can rely on, and what does the community specification give for each?
4. What do written terms of use cover, and which books of this library hold the law behind them?
5. What is a vanity count, and which few counts show that an interface is used and governed?

Answers. 1. A small firm should open when customers or outside developers ask repeatedly for access to its data or events, when the product is stable enough to be described, when the firm can approve, limit and remove an integrator, and when no critical path depends on the interface; it should not open when the product changes every week, when it cannot answer an integrator, or when opening would put the alert path or personal information at risk. 2. The four choices are what to open, how an integrator proves who it is, what its access may do and how fast it may call; the OAuth 2.0 framework lets an application obtain limited access on its own behalf (Hardt, 2012), the security practice restricts tokens to the minimum privileges and to a specific resource server (Lodderstedt et al., 2025), and the status for too many requests carries an explanation and possibly a Retry-After header with no particular limit given (Nottingham & Fielding, 2012). 3. An identifier unchanged across retries, a timestamp, a signature, retries with backoff and answer codes; the community specification says the identifier serves as an idempotency key, the signed content is the identifier, the timestamp and the body joined by full stops, the tolerance has no value given, retries span several days with an example schedule of about three days, and a consumer answers 2xx for success and 410 to stop deliveries (Standard Webhooks, n.d.). 4. Who may use the interface and how access is approved, what an integrator may do with the data, the limits and the notice of a change, what the company answers for, the removal of an integrator and the rotation of a key, and the ownership of what each side builds; the contract is Book H1's (Contracts and Commercial Agreements) with a lawyer, the intellectual property is Book H5's (Intellectual Property), and personal information is Book H2's (Privacy and Personal Information). 5. A vanity count is a number that rises without telling whether the interface is used or governed, such as sign-ups that never build anything and calls that have no outcome; the counts that show use and governance are the approved integrators, the integrations in use, the events delivered, the duplicates, the keys rotated and the integrators removed, and none of them is credited with a sale or a growth.

Chapter References

Benlian, A., Hilkert, D., & Hess, T. (2015). How open is this platform? The meaning and measurement of platform openness from the complementers' perspective. Journal of Information Technology, 30(3), 209–228. https://doi.org/10.1057/jit.2015.6

Benzell, S. G., Hersh, J., & Van Alstyne, M. (2024). How APIs create growth by inverting the firm. Management Science, 70(10), 7120–7141. https://doi.org/10.1287/mnsc.2023.4968

Boudreau, K. (2010). Open platform strategies and innovation: Granting access vs. devolving control. Management Science, 56(10), 1849–1872. https://doi.org/10.1287/mnsc.1100.1215

Fielding, R., Nottingham, M., & Reschke, J. (Eds.). (2022, June). HTTP semantics (RFC 9110; STD 97). RFC Editor. https://doi.org/10.17487/RFC9110

Ghazawneh, A., & Henfridsson, O. (2013). Balancing platform control and external contribution in third-party development: The boundary resources model. Information Systems Journal, 23(2), 173–192. https://doi.org/10.1111/j.1365-2575.2012.00406.x

Hardt, D. (Ed.). (2012, October). The OAuth 2.0 authorization framework (RFC 6749). RFC Editor. https://doi.org/10.17487/RFC6749

Hukal, P., Henfridsson, O., Shaikh, M., & Parker, G. (2020). Platform signaling for generating platform content. MIS Quarterly, 44(3), 1177–1206. https://doi.org/10.25300/MISQ/2020/15190

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /registre, plans, /products/partners, business/partner-programs/settings, business/partner-programs/applications and /become-partner.

Lodderstedt, T., Bradley, J., Labunets, A., & Fett, D. (2025, January). Best current practice for OAuth 2.0 security (RFC 9700; BCP 240). RFC Editor. https://doi.org/10.17487/RFC9700

Nottingham, M., & Fielding, R. (2012, April). Additional HTTP status codes (RFC 6585). RFC Editor. https://doi.org/10.17487/RFC6585

OpenAPI Initiative. (2026, September 10). OpenAPI Specification v3.2.1. The Linux Foundation. https://spec.openapis.org/oas/v3.2.1.html

Parker, G., Van Alstyne, M., & Jiang, X. (2017). Platform ecosystems: How developers invert the firm. MIS Quarterly, 41(1), 255–266. https://doi.org/10.25300/MISQ/2017/41.1.13

Standard Webhooks. (n.d.). Standard Webhooks specification (Version 1.0.0). Retrieved October 15, 2026, from https://github.com/standard-webhooks/standard-webhooks/blob/main/spec/standard-webhooks.md

Chapter 6 — Risks of Dependence

Access to a platform is paid in dependence, so this chapter says how dependence builds one convenience at a time, what notice a business gets when a platform changes its terms, how fees move, what removal and suspension involve and the statement of reasons that the European Union requires of the services it covers, how disintermediation runs in both directions, how the platform owner may become a competitor in one setting or another, how to measure exposure on revenue, customers, data and operations, how to diversify without spreading too thin, and when competition law is the right door, called to Book H4 and never taught, and builds the dependence register and the ceiling of Hydrosentinelle inc. on day 365, posed by this book.

What You'll Be Able to Do

• Describe how dependence on a platform builds one convenience at a time, and why the power in the arrangement sits with the owner of the platform rather than with the business that plugs into it.
• Read the notice that a platform's terms give before a change or an end takes effect, and write in a register what each platform gives or the absence of any notice at all.
• Measure exposure on four things — revenue, customers, data and operations — and set a ceiling in advance on the share that any one platform may bring.
• Recognize the ways a fee moves, what removal and suspension mean for a complementor, and what a business keeps ready so that a platform's decision does not stop its service.
• Diversify by order rather than by spreading, so that a second system or a second route is built before the first one is asked to carry everything.
• Say when competition law is the right door, and refer the question to Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements) and to a lawyer rather than deciding it.

Why It Matters

A business that plugs into a platform gains something real on the day it plugs in, and it pays for that gain in a currency it does not see on the invoice. The gain is access: the customers are already there, the interface is already documented, the work is already done by somebody else. The currency is dependence, and it accumulates quietly. A connector here, a listing there, a feature that works only inside one system, a report that lives in one console, and after a year the business cannot answer a simple question: if this platform changed its terms tomorrow, what would we do? The question is not pessimistic. It is the same question a business asks about its largest customer, its only supplier or its single channel, and it has the same answer: measure it, cap it, and keep a way out written down.

The reason the question is harder for a platform than for a customer is that the platform writes the terms. A large customer negotiates; a platform publishes. The terms arrive as a page, they are accepted by a click, and they change with a notice that the business may not read. That is why this chapter spends its first half on the terms themselves — what notice they give, how a fee moves, what removal and suspension look like — and its second half on the instrument that keeps the business honest: a register of dependence with a ceiling set in advance, read every quarter. The register is not a legal document and it is not a forecast. It is a page a colleague could follow, and its value is that it is written before the pressure arrives rather than after.

None of this argues against integrating. A complementor that refuses every platform refuses the customers who live there, and this book holds that the decision to plug in is a decision and not a feature. What it argues is that the decision be taken with the terms read on the day they are signed, with the exposure measured, with a ceiling set in advance, and with every critical path — above all the alert path — kept outside any platform. The case of this book, Hydrosentinelle inc., a fictional company in Sherbrooke that designs and sells connected water-leak detectors for commercial and rental buildings (Book A5, Financing a Business), does exactly that, and its register is the subject of section 6.10.

In This Chapter

Section 6.1 explains how dependence builds one convenience at a time, names the power asymmetry that the arrangement carries, and sets the frontier between this chapter and its neighbors. Section 6.2 covers policy and term changes and the notice a business gets, with the notice that four terms give read as of October 15, 2026. Section 6.3 covers fees that move, in four ways, each a term of the day it was read. Section 6.4 covers removal, suspension and the statement of reasons. Section 6.5 covers disintermediation in both directions. Section 6.6 covers the platform owner as a future competitor, with eight readings of the owner's entry and the response, each in its setting. Section 6.7 covers the measurement of exposure on revenue, customers, data and operations, and the ceiling set in advance. Section 6.8 covers diversifying without spreading too thin. Section 6.9 covers when competition law is the right door, with the provisions of the Competition Act called to Book H4 and never taught. Section 6.10 builds the case's dependence register and its ceiling on day 365.

6.1 How Dependence Builds One Convenience at a Time

Dependence on a platform is not one decision. On this book's own reasoning, it is built one convenience at a time, by a series of small decisions that each look reasonable on the day they are taken. A business connects its alert to the property-management system its largest customer runs, because the customer asked and the connection saves a phone call. It lists its application in a store, because the store is where its customers look. It adds a feature that works only inside one platform, because the platform's interface makes that feature easy and the business's own interface would make it hard. It moves a report into the platform's console, because the console draws the chart and the business's spreadsheet does not. Each step is small, each step is defensible, and together they produce a business that cannot say what it would do without the platform.

The power in that arrangement sits with the owner of the platform, and the reason is structural rather than personal. The owner sets the terms, and the owner may change them. The owner decides what the interface exposes and what it withholds. The owner decides who is admitted to the program and who is removed from it. The owner sees, in its own console, what the complements on its platform sell. A complementor that has built its service around one platform has made an investment that may be costly to redeploy elsewhere.

The abstract of one conceptual analysis read for this book reports that, drawing on power-dependence theory, the power asymmetry between a platform and its ecosystem members is intrinsic to the economics and architecture of digital platforms, that it creates novel risks, and that entrepreneurs who depend on platforms develop strategies to mitigate their dependence (Cutolo & Kenney, 2021, abstract only). The analysis is conceptual and reports no measured effect, and it is the authors' own argument rather than a finding about any business. This book's own reading, never a finding of the analysis, is that the asymmetry is not a sign that a business chose badly: it follows from the arrangement itself, as the authors argue.

The abstract of a second study read for this book reports that, in two smartphone ecosystems, higher ecosystem complexity helped application developers sustain superior performance, more so for experienced firms, while generational transitions initiated by the platform owners made it harder (Kapoor & Agarwal, 2017, abstract only). The study is of two smartphone ecosystems and of one period, and it is not a business-software setting. Its direction is worth printing with its setting and no further: complexity in an ecosystem helped the developers in the sample, and the transitions that the platform owners initiated made it harder.

The practical reading of both abstracts is this book's own: dependence is not measured on the day a business signs, because on that day the business has gained access and lost nothing visible. It is measured a year later, when the connector is load-bearing and the listing is the main source of inquiries. A written register kept from the first integration, with a ceiling set before the exposure exists, is the instrument that catches it, and sections 6.7 and 6.10 give the method and the case's register.

The table below sets out what this chapter holds and what its neighbors hold. Read it as a frontier: each row names a book that owns a rule, a fee or a definition, says what that book holds, and says what this chapter holds instead, so that no rule is written twice and no definition is competed with. Dependence is defined in section 1.1 of this book.

Table 6.1 — Where this chapter stops and its neighbors begin

DEFINITION The words this book uses for exposure, a ceiling, a register of dependence, notice and a way out

These are this book's working words, and no source read defines them in this sense. Exposure is what of the business rests on a platform, its revenue, its customers, its data or its operations. A ceiling is the limit set in advance on the share that any one platform may bring. A register of dependence is the written list of each platform with what is exposed, the notice its terms give and the way out. Notice is the time that a platform's terms give before a change or an end takes effect. A way out is the written step that keeps the service running if a platform fails or ends. Dependence itself is defined in section 1.1 of this book, and the dependence ceiling of a partner in an original equipment manufacturer arrangement is Book F2's (OEM Partners and White-Label Programs) and is not redefined here.

6.2 Policy and Term Changes, and the Notice a Business Gets

A platform changes its terms in one of three ways, and a business should know which one it is dealing with before it signs. The first is a change with a notice: the platform publishes the new terms, says when they take effect, and the business has time to read them and to decide. The second is a change with a notice that is shorter than the business needs: the notice exists, it is measured in days, and the days are fewer than the work of adapting takes. The third is a change with no notice that the business can find: the terms are updated, the page carries a new date, and nothing tells the business what moved. This book prints no frequency for any of the three. What it prints is what four sources say, each read on October 15, 2026, each a term or a rule of its own jurisdiction.

The review guidelines of one app store, read as that platform's terms of the day, carry a date of last update and give no notice period for changes to the guidelines; none was found on the page (Apple, 2026). That is a fact about one page read on one day, and it is not a statement that the store changes its rules without warning.

The distribution agreement of the other store, read as that platform's contract of the day, says that the agreement may be changed with notice, and that a change takes effect for an existing developer on the date in the notice, at least 30 days after it is posted, except a change required by law, while the developer's remedy is to stop using the store (Google, 2025). How a Québec court would read those clauses is not on the page, and Book H1 (Contracts and Commercial Agreements) and a lawyer hold that question.

The Civil Code of Québec, article 1435, up to date to August 12, 2026 and read on October 15, 2026, provides that an external clause binds, but that in a consumer contract or a contract of adhesion it is null if it was not expressly brought to the attention of the consumer or the adhering party at formation, unless the other party proves that the consumer or adhering party otherwise knew of it. The article is read at its text and is never applied here to a real platform's clause; Book H1 and a lawyer hold the contract of adhesion, and only a court decides what a given clause means.

Regulation (EU) 2019/1150, article 3, read as published in the Official Journal through the Publications Office on October 15, 2026, requires that proposed changes to terms be notified on a durable medium with at least 15 days' notice for the online intermediation services it covers. It is a rule of another jurisdiction, printed as what the European Union requires of the services it covers and as a yardstick for reading a platform's terms, never as a right or a duty of a business in Québec or Canada.

The table below sets four sources beside the notice each gives, the kind of rule each is, and where the question it raises is held. Read it row by row: the first two rows are platforms' own terms of the day they were read, the third is a rule of another jurisdiction used as a yardstick, and the fourth is the case's own posed term, which belongs to no source and is marked as posed.

Table 6.2 — The notice that four terms give, read as of October 15, 2026

WATCH OUT A notice that was not found is not a promise that the terms will hold

A business reads the guidelines of one app store, finds no notice period for changes, and plans as though the terms will hold (Apple, 2026). What the page says is that no notice period was found there; it does not say that no change will come. The other store's agreement, by contrast, gives a notice (Google, 2025). The signs of the trap are a plan that assumes today's fee will hold, a budget built on today's revenue share, and no weekly reading of the terms. The remedy is small and it is a habit: read the terms of each platform every week, as Chapter 8 sets out, and write in the register the notice each platform gives, or the absence of one, with the day the page was read. The reasoning is this book's own and no source measures how often a platform changes its terms.

6.3 Fees That Move

A fee on a platform moves in four ways, and each of the four is visible in a page read on October 15, 2026. The first way is a threshold: the fee depends on a level of proceeds, so the same business pays one rate below the level and another above it. The second is a region and a kind of transaction: the fee depends on where the customer is and on what is being bought, so the same sale is charged differently in two places. The third is the life of an account: the fee depends on how much has been earned since a starting point, so the rate falls or rises as the account ages. The fourth is a decision of the platform: a new tier, a new fee or a new split is announced, and the business reads it in a notice. None of the four is a market rate, and none of the four is a term of the business's own. Each is a term of the day it was read.

One app store's small business program, read as of October 15, 2026, gives a reduced commission of 15 percent to a developer with no more than 1 million USD of proceeds in the previous calendar year and the current year, and 10 percent for subscriptions after their first year; the standard rate is named on the page and its percentage is not printed there (Apple, n.d.). The threshold is the first way a fee moves: a business that crosses the level pays a different rate, and a business that plans on the reduced rate should know what happens when it crosses.

The other store's service fee page, read as of October 15, 2026, gives 15 percent on the first 1 million USD of earnings a year and 30 percent above in the markets not yet moved to the new regional tier, and 15 percent on subscriptions for developers enrolled in the 15 percent tier; a regional tier for Australia, the European Economic Area, Japan, the United Kingdom and the United States, rolled out on June 30, 2026 or September 30, 2026, splits a service fee and a billing fee of 5 percent by kind of install and transaction; no rate for Canada after a future rollout is given (Google, n.d.). The region and the kind of transaction are the second way a fee moves.

A commerce platform's revenue share page, read as of October 15, 2026, gives a share that is 0 percent on the first tier of lifetime gross application revenue and 15 percent after it, with the figures dated in the callout below (Shopify, n.d.). The life of an account is the third way a fee moves: the rate depends on a total counted from a starting point, and a business that plans on the first tier should know where the second begins.

The fourth way is a decision of the platform, and the case carries one, posed by this book. The first platform's annual fee rises from $3,000 to $3,600 with 60 days' notice, and the weekly watch of terms reads the notice the week it arrives (Chapter 8). The case pays no store commission and no share of its subscriptions, and the application is free with nothing sold inside it. That reading rests on the store pages read on October 15, 2026; a store's review decides, and it is not legal advice. What a business does about a fee that moves is the same in all four cases: it reads the page on the day it signs, it writes the term and the day in the register, it reads the page again every week, and it decides in advance what it will do if the fee crosses a level it cannot carry.

WHAT CHANGED One commerce platform's revenue share moves from 0 percent to 15 percent after the first 1 million USD of lifetime gross app revenue (Shopify, n.d.)

The dated change comes from the page read on October 15, 2026, with no update date shown: the revenue share is 0 percent on the first 1 million USD of lifetime gross application revenue counted from January 1, 2025, and then 15 percent, with a one-time registration fee of 19 USD per Partner account and a processing fee of 2.9 percent charged separately (Shopify, n.d.). It is one commerce platform's term of the day it was read, never a market rate and never the case's, and no other date is printed for it. What the change shows is the third way a fee moves: the rate depends on a total counted from a starting point, so a business that plans on the first tier is planning on a term that ends at a level. The case's own fee change, the annual fee that rises from $3,000 to $3,600 with 60 days' notice, is posed by this book and belongs to no source.

6.4 Removal, Suspension and the Statement of Reasons

Removal, suspension and termination are three ways a platform ends or limits a business's access, and they are worth reading before they happen rather than after. In this book's words, removal takes the listing down or rejects the application: the product disappears from where the customers look, and the inquiries stop. Suspension limits the account: the developer can still sign in, but a product cannot be published, an update cannot be shipped, or a payment cannot be collected. Termination ends the agreement itself. For a complementor, the practical difference between the three is what the business can still do on the day after, and the answer should be written down in advance.

The distribution agreement of the other store, read as that platform's contract of the day, says that the platform may reject, remove, suspend, limit or reclassify a product or suspend a developer, with an appeal process and no promise of advance notice (Google, 2025). The same agreement says that it may terminate immediately on written notice for named causes, or on 30 days' written notice for any reason where the law allows (Google, 2025). How a Québec court would read those clauses is not on the page, and Book H1 (Contracts and Commercial Agreements) and a lawyer hold that question.

Regulation (EU) 2019/1150, articles 3, 4, 8 and 11, read as published in the Official Journal through the Publications Office on October 15, 2026, requires of the online intermediation services it covers that the grounds for suspension or termination be stated in the terms (art. 3), that a statement of reasons be given when a service is restricted or suspended and that at least 30 days' notice with reasons be given before a termination of the whole service, with stated exceptions (art. 4), that changes not be retroactive, that the conditions of termination be stated and that a description of access to information after the contract be given (art. 8), and that an internal complaint-handling system be provided, with small enterprises excepted (art. 11). It is a rule of another jurisdiction, printed as what the European Union requires of the services it covers and as a yardstick for reading a platform's terms, never as a right or a duty of a business in Québec or Canada.

What a business keeps ready is small and it is written. For each platform, a way out in a sentence a colleague could follow: if the listing goes, the inquiries come from somewhere else; if the application is rejected, the service still runs; if the account is limited, the customer still gets what was promised. And a person who answers within a day, because a removal notice that sits unread for a week is a week of customers asking questions with no answer. The case carries one removal event, posed by this book: one update of the mobile application is rejected by a store's review and fixed in 3 days, on day 365. The case also carries the sentence that makes the removal survivable: if a store rejects or removes the application, alerts still go by text message and email, because the alert path runs through no platform. That sentence is posed by this book and it is the reason the removal is an inconvenience rather than an outage.

6.5 Disintermediation in Both Directions

Disintermediation runs in two directions, and a business that reads only one of them is reading half the risk. The first direction is the platform bypassing the complementor: the platform sells to the complementor's customers directly, or offers its own version of what the complementor sells. That direction is the subject of section 6.6. The second direction is the complementor bypassing the platform: the business moves the customer relationship, the invoice and the data outside the platform, so that the platform is a route rather than a home. That direction is the one a business controls.

The multi-sided model, its launch and disintermediation are Book A1's (From Idea to Business Model, chapter 6 of Book A1), cited here and never redefined. The channel conflict that arises when a business serves the same customer through two routes is Book F1's (Go-to-Market and Channel Strategy, chapter 6 of Book F1), also cited and never redefined. What this chapter adds is the complementor's side of both: the platform can bypass the business, and the business can bypass the platform, and each direction has a cost and a term in the agreement.

The cost of the second direction is real and it is worth naming. Moving the customer relationship outside a platform means the business does the work the platform was doing: the invoice, the support, the record, the renewal. Moving the data outside means the business keeps a copy and keeps it current. Moving the invoice outside means the business collects, and collection has its own cost. The term in the agreement matters because an agreement may restrict what a business does with the customer relationship, and Book H1 (Contracts and Commercial Agreements) and a lawyer hold what a given clause means. The reading is done before the move, not after.

The case keeps the second direction open, and every element of it is posed by this book. Hydrosentinelle inc. invoices the building owner directly, so the customer relationship is the company's and not the platform's. The first platform's partner program takes no share of the subscriptions, so the revenue does not pass through the platform. The mobile application is free and sells nothing inside it, so no store sits between the company and a buyer. And no sale and no customer is credited to the platform: the accounts that signed after an inquiry from the listing are recorded as having signed after an inquiry, and nothing says the listing caused the signature.

6.6 The Platform Owner as a Future Competitor

The owner of a platform sees what its complements sell, may build or buy a version of it, and may favor its own version once it exists. Whether it does so depends on the setting, and the studies read for this book point in different directions in different settings. This section prints the direction and the setting of each, never a forecast and never a law. The studies are read at abstract only, each is one platform and one period or one industry, and none of them is a business-software setting unless it says so.

On one retail marketplace, the platform owner was more likely to enter successful product spaces and less likely to enter those that require greater seller effort, and entry discouraged affected sellers from pursuing growth on the platform while raising demand and lowering shipping costs for consumers (Zhu & Liu, 2018, abstract only). On one mobile platform, after the threat of the owner's entry increased, affected developers reduced innovation and raised prices on affected applications and shifted innovation to unaffected and new applications, and the welfare effect is ambiguous (Wen & Zhu, 2019, abstract only). On a panel of 6,620 applications, one platform owner's entry into photography applications on its own mobile platform was associated with an increase in complementary innovation, a 9.6 percent higher likelihood of major updates for affected applications, through increased consumer attention, more so for larger and more diversified complementors (Foerderer et al., 2018, abstract only). One platform owner, a chip maker, encouraged entry and used organizational structure and processes as commitment mechanisms, because it believed it could not enter all markets (Gawer & Henderson, 2007, abstract only). A survey of the empirical studies reports that the motivation for entry goes beyond value capture and that the impact on complementors varies across settings (Zhu, 2019, abstract only).

Two further readings narrow the picture. In enterprise software, vendors with more formal intellectual property rights and stronger downstream capabilities were more likely to be certified by a platform owner and to build compatible applications, which suggests that these protect against expropriation by the platform owner (Huang et al., 2013, abstract only). After one platform owner's entry with a file-management application, generalist complementors shifted effort toward a competing platform while specialists doubled down on the focal platform, and entries by other large firms did not elicit a meaningful response (Kapacinskaite & Mostajabi, 2024, abstract only). And one social platform's tight integration of its own photo-sharing application was followed by growth in that application's user base, a small increase in demand for big third-party applications and a decrease for small ones, and an increase in demand for the whole photo-sharing ecosystem (Li & Agarwal, 2017, abstract only).

KEY CONCEPT The platform owner's entry is a risk to read in its setting, never a forecast and never a law

The idea of this section is this book's own reading and never a finding of a source. The entry studies are one platform and one period each, and they point in different directions by setting: entry discouraged growth on one retail marketplace (Zhu & Liu, 2018, abstract only), reduced innovation on one mobile platform (Wen & Zhu, 2019, abstract only), and was associated with more complementary innovation in one photography category (Foerderer et al., 2018, abstract only), while a survey of the studies reports that the impact varies across settings (Zhu, 2019, abstract only). No study of entry read here measures a business-software platform, and none of them is a forecast for a reader's business. What follows is a practice rather than a prediction: a complementor reads its own platform's incentives, as section 2.9 sets out, and writes in the register the products it sells that the owner could one day sell. The register does not stop the entry. It makes the entry a line the business has already read.

6.7 Measuring Exposure: Revenue, Customers, Data and Operations

Exposure is measured on four things, and the measurement is written for each platform the business depends on. The four are revenue, customers, data and operations, and the reason for four rather than one is that a platform can be small on revenue and large on operations, or large on customers and small on data. A business that measures only revenue will miss the platform whose failure stops its service without costing it a dollar.

Revenue exposure is the share of the new business that a platform brings in a period. The measure is not the total revenue of the business and it is not the platform's fee; it is the share of the new buildings, the new accounts or the new orders that arrived through that platform in a quarter. Customers exposure is the number of customers that run in the platform, which is a different number from the revenue they bring. Data exposure is what crosses the integration: the fields, the identifiers and the personal information that travel, and what would be exposed if the platform were breached or if the business had to leave. Operations exposure is what stops if the platform stops: the work that has no other route, and the promises that cannot be kept without it.

The ceiling is set in advance and it is read every quarter. The case's ceiling, posed by this book, is that no single platform brings more than 40 percent of the new buildings of any quarter, and that no alert path runs through any platform. A ceiling set after the exposure exists is not a ceiling; it is a description.

The table below sets the four exposures beside what to count for each and the company's reading on day 365. The company's column is posed by this book and illustrative, and no revenue is computed from it. Read the table as a form to fill rather than as a result: the columns are the same for any business, and what changes is the numbers in the third column.

Table 6.3 — Four exposures, what to count and the company's reading, posed by this book

METHOD Building a dependence register in five steps

First, list each platform that the business depends on, by its function and not by its brand, so that the list survives a change of vendor. Second, write what is exposed for each, on revenue, customers, data and operations, using the four exposures of this section. Third, write the notice its terms give and the day the page was read, so that a term is a dated fact rather than a memory. Fourth, write the way out in a sentence a colleague could follow, because a way out that only one person understands is not a way out. Fifth, set the ceiling in advance and read the register every quarter, so that the ceiling is a decision rather than a description. The sequence is this book's own, no source tests it, and the case's ceiling of 40 percent is posed by this book and illustrative. The register is kept by a person and read by a person; a tool can hold the list and cannot make the judgment.

TOOLS OF THE TRADE What a business needs to measure its exposure: a list, an inventory with a measured version, a calendar of notices and a register

Four functions carry the measurement, and a business should look for them rather than for a product. The first is a list of the platforms that a person can correct, so that the list is maintained rather than abandoned. The second is an inventory of tools with the version measured and the date, so that the business knows what it runs and when it last looked. The third is a calendar of the notices and the review dates, so that a term that changes is read in the week it changes. The fourth is one register where each dependence is written with its way out, so that the exposure and the exit sit on the same line. Chapter 10 gives the functions in full, with the pricing model and without amounts. No brand name belongs on this list and no price; the requirement is the function, and the judgment stays with a person.

6.8 Diversifying Without Spreading Too Thin

Diversifying means serving a second system or a second route so that no single platform exceeds the ceiling. Spreading too thin means serving so many that quality falls. The two are different, and the difference is not the number of platforms; it is whether the second one is built before the first one is asked to carry everything, and whether the work of serving it is paid for.

The abstract of one study read for this book reports that, in the United States video game industry, games released on several platforms had lower quality on the technologically more complex console, and games released first on one platform performed worse on the platforms they were later ported to (Cennamo et al., 2018, abstract only). The study is of one industry and one period, and it is not a business-software setting. Its direction is worth printing with its setting: in that one industry, releasing on several platforms was associated with lower quality on the more complex console. A second reading, already used in section 6.6, reports that after one platform owner's entry with a file-management application, generalist complementors shifted effort toward a competing platform while specialists doubled down on the focal platform (Kapacinskaite & Mostajabi, 2024, abstract only). A third, already used in section 6.1, is a conceptual analysis drawing on power-dependence theory, which reports that entrepreneurs who depend on platforms develop strategies to mitigate their dependence, with no measured effect (Cutolo & Kenney, 2021, abstract only). None of the three is a rule, and none of them says how many platforms a business should serve.

What this book draws from them is an order rather than a number. Build the second route before the first one is load-bearing, so that the second is a choice rather than a rescue. Score the candidates on one grid, as Chapter 3 sets out, so that the order is a decision rather than an accident. And accept that the second route costs something, so that the cost is in the plan rather than in the surprise. The dependence ceiling of a partner in an original equipment manufacturer arrangement is Book F2's (OEM Partners and White-Label Programs), cited and not redefined here.

The case diversifies by order and not by spreading, and every element is posed by this book. Hydrosentinelle inc. builds the first integration with the first property-management system, queues the second property-management system, and puts the smart-home standard for rental units at "not now" on the grid of Chapter 3. The order is the diversification: the second candidate is scored and waiting, so that if the first platform's terms move past what the company can carry, the work of the second has already been read. The company makes no hire to serve the second route, and Book F9 (Building and Running a Partner Program) prints that no hire was made at month 12.

WHO DOES THIS The head of sales and operations keeps the register, and the president checks the technical exits

Who owns the register and the ceiling depends on the size of the business, and the distribution below is this book's suggestion and not part of the case. A solo owner keeps both, and the register is short because the business is short. In a small team the owner sets the ceiling and a lead keeps the register, so that the judgment and the upkeep sit with different people. In an established business a partnerships manager keeps the register and the owner reads it every quarter, as Chapter 9 sets out. In the case, posed by this book, Karim Haddad, the head of sales and operations, keeps the register and its ceiling, and Laurence Bergeron, the president, product and engineering, checks the technical exits, because a way out that says "open a work order by hand" is a technical claim and not a commercial one. No hire is made for this work, and no hour is promised to a reader.

6.9 When Competition Law Is the Right Door

Competition law is the right door for some questions and the wrong door for others, and this section does not teach it. It calls it, one sentence for each provision, to Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements, chapter 5 of Book H4), and it never concludes that a real platform abuses a dominant position, refuses to deal unlawfully or imposes an abusive clause. Only the Tribunal or a court decides those questions.

The Competition Act, R.S.C. 1985, c. C-34, current to September 21, 2026 and last amended on March 26, 2026, read on the Justice Laws Website on October 15, 2026, provides in section 75(1) that the Tribunal may order a supplier to accept a person as a customer in the conditions the text sets, including where insufficient competition prevents obtaining adequate supplies on usual trade terms. Section 77(1) defines exclusive dealing, market restriction and tied selling. Section 78(1) defines an anti-competitive act and lists acts, among them product specifications incompatible with others' products designed to prevent entry. Section 79(1) provides that where persons substantially or completely control a class or species of business, the Tribunal may make an order on either of two alternative paths, a practice of anti-competitive acts, or conduct that has the effect of preventing or lessening competition substantially and is not the result of superior competitive performance. Section 79(3.1) sets an administrative monetary penalty as the text sets it out, and no figure is computed or printed here. Section 103.1(1) provides that any person may apply to the Tribunal for leave to bring an application on refusal to deal, exclusive dealing or abuse of dominance, among others. Each of these is called to Book H4 and is not rewritten here.

The abuse of dominance enforcement guidelines of the competition regulator, dated March 7, 2019 and modified on the page on June 27, 2024, read on October 15, 2026, carry a notice at the top saying that after recent amendments to the Act the Bureau is reviewing its guidelines and will update them (Competition Bureau, 2019). For a multi-sided platform the Bureau may define a market on one side but accounts for interdependent demand and feedback effects across sides; network effects of platforms that match buyers and sellers can make entry harder; a refusal to supply can be explicit or constructive, a prohibitive price being the constructive form, and the input must be competitively significant and not feasibly obtained elsewhere (Competition Bureau, 2019). The page says nothing on self-preferencing, and no finding is made against any platform.

The Commission's Gatekeepers Portal, read on October 15, 2026, reports that seven undertakings are designated gatekeepers for 23 core platform services (European Commission, n.d.). The undertakings are counted and never named, and the Regulation under which they are designated is a rule of another jurisdiction. Regulation (EU) 2022/1925, articles 3, 5 and 6, read as published in the Official Journal through the Publications Office on October 15, 2026, sets the threshold for a gatekeeper as met in each of the last three financial years, with the same core platform service provided in at least three Member States (art. 3(2)(a)); provides that business users may offer the same products through third-party online intermediation services or through their own direct online sales channel at prices or conditions different from those of the gatekeeper's service (art. 5(3)); provides that third-party applications and application stores may be installed (art. 6(4)); provides that business users get free access to the data that their use provides or produces, personal data only with the end user's consent (art. 6(10)); requires fair, reasonable and non-discriminatory conditions of access to application stores (art. 6(12)); and requires that termination conditions not be disproportionate (art. 6(13)). It is printed as what the European Union requires of the designated services and as a yardstick for reading a platform's terms, never as a right or a duty of a business in Québec or Canada.

The table below sets six provisions of the Competition Act beside what each says in this book's words and the book that holds it. Read it as a map of doors rather than as a summary of the law: each row names a provision, gives one sentence of what it provides, and sends the question to Book H4, where the provision is read at its text.

Table 6.4 — Six provisions of the Competition Act, called to Book H4

The door to competition law is a lawyer's, and the case never opens it. Nothing in the case is a conclusion of abuse, and no clause of any platform is called abusive here. A question about a platform that is believed to have refused to deal, imposed an exclusive term or acted anti-competitively is a question for a lawyer, who reads the provisions with the facts and judges whether the door is the right one. Book H4 holds the law, and this book holds the practice of the complementor.

QUÉBEC & CANADA NOTE Competition is held by Book H4, and this book explains the law as published and is not legal advice

This book explains the law as published and is not legal advice. The Canadian point of this section is competition: the Competition Act, ss. 75(1), 77(1), 78(1), 79(1), 79(3.1) and 103.1(1), current to September 21, 2026, is read at its text and called to Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements), and section 79(1) has two alternative paths, a practice of anti-competitive acts, or conduct that substantially prevents or lessens competition and is not the result of superior competitive performance. The European Union's regulations are another jurisdiction's rules and a yardstick only, never a right or a duty of a business in Québec or Canada. This book recommends no vendor, no platform and no adviser, and it refers a business with a competition question to Book H4 and to a lawyer. Nothing here concludes that any platform abuses a dominant position, refuses to deal unlawfully or imposes an abusive clause; only the Tribunal or a court decides.

THE RULE Section 79(1) of the Competition Act has two alternative paths, and the three elements of the guidelines of 2019 predate them (Competition Bureau, 2019)

Section 79(1) of the Competition Act, current to September 21, 2026, lets the Tribunal make an order where persons substantially or completely control a class or species of business, on either of two alternative paths: a practice of anti-competitive acts, or conduct that has the effect of preventing or lessening competition substantially and is not the result of superior competitive performance. The abuse of dominance enforcement guidelines of the competition regulator, dated March 7, 2019 and modified on the page on June 27, 2024, say at the top of the page that after recent amendments to the Act the Bureau is reviewing its guidelines and will update them, and the three cumulative elements they set out predate the amendments (Competition Bureau, 2019). The three elements are therefore never printed as the current test. Book H4 holds the law, and this callout concludes nothing about any platform.

6.10 The Case's Dependence Register and Ceiling

The register is the instrument of this chapter, and the case's register is written on day 365, posed by this book. It lists each platform on which Hydrosentinelle inc. depends, what is exposed, the notice its terms give and the way out. The ceiling that goes with it, also posed, is that no single platform brings more than 40 percent of the new buildings of any quarter, and that no alert path runs through any platform. The register is kept by Karim Haddad, the head of sales and operations, and the technical exits are checked by Laurence Bergeron, the president, product and engineering.

The readings of day 365 are these, and every one of them is posed by this book and illustrative. The company closes the year with 940 buildings, after 190 new and 70 lost. The listing received 52 inquiries, and 11 accounts with 34 buildings signed after an inquiry, which is 17.9 percent of the new buildings of the year and 22.0 percent in the busiest quarter, 9 of 41, under the ceiling of 40 percent; nothing says that the listing caused these signatures. Nine accounts enabled the integration for 176 buildings. The first platform was down for more than six hours on 2 occasions, and no alert was late, because the alert path does not run through it. The first platform announced that its annual fee would rise from $3,000 to $3,600 with 60 days' notice, and the weekly watch read it the week it arrived. One update of the mobile application was rejected by a store's review and fixed in 3 days. Four integrators use the company's own interface, 1 key was rotated and 0 integrator was removed.

Figure 6.1 shows the case's dependence register on day 365 and the ceiling it keeps. It is drawn as a register of three rows and four columns, the platform, what is exposed, the notice its terms give and the way out, for the first property-management system, the two mobile app stores and the company's own interface; below the register, a gauge shows the ceiling, no single platform bringing more than 40 percent of the new buildings of any quarter, with the busiest quarter read at 22.0 percent, and a line states that the alert path runs through no platform.

Figure 6.1 — The dependence register. Each platform with what is exposed, the notice its terms give and the way out; the busiest quarter read 22.0 percent against a ceiling of 40 percent, and nothing is credited (posed).

The table below gives the register itself, row by row, in the four columns of the figure. Read it as the page a colleague could follow: the first column names the platform by its function, the second says what is exposed, the third says what notice the terms give, and the fourth says what the business does if the platform fails or ends. Every cell is posed by this book.

Table 6.5 — The case's dependence register on day 365, posed by this book

In La Machine, as of the application copy of September 7, 2026, the pages that touch this chapter are Control center → Tools (inventory) (/outils), an inventory of tools with a measured version and a date, and Account → Profile → Privacy (account/privacy), which exports the account's own data. It holds no register of dependence on platforms, no measure of exposure and no watch of a platform's terms; check it in your installation (La Machine, 2026). The case does not use La Machine (Books G8, I8 and L5), and this book is valid with any tool.

CASE IN POINT Hydrosentinelle inc. keeps a dependence register and a ceiling of 40 percent on the new buildings any one platform brings

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. The register of Hydrosentinelle inc. on day 365 has three rows, the first property-management system, the two mobile app stores and the company's own interface, each with what is exposed, the notice its terms give and a way out, as Table 6.5 sets out. The ceiling is 40 percent of the new buildings of any quarter, and the busiest quarter read 22.0 percent. Karim Haddad keeps the register and its ceiling, and Laurence Bergeron checks the technical exits. Every figure is posed by this book, and nothing is credited to the listing, the integration or the interface.

DO THE MATH Shares of the year's new buildings, a quarter against a ceiling: the register in numbers

Illustrative figures; the case is fictional. Step 1 — 34 of the 190 new buildings of the year are 17.9 percent, rounded to one decimal. Step 2 — in the busiest quarter, 9 of 41 new buildings are 22.0 percent. Step 3 — 22.0 percent is under the ceiling of 40 percent, so the quarter passes the ceiling the company set in advance. Step 4 — 820 buildings plus 190 new minus 70 lost are 940 buildings at day 365. Step 5 — the annual fee announced from $3,000 to $3,600 came with 60 days' notice, and every count here is posed by this book and illustrative, with nothing credited to the listing, the integration or the interface. The shares are shares of new buildings and not of revenue, and each share is rounded to one decimal.

IN LA MACHINE La Machine's inventory of tools measures a version and not a dependence, and its account page exports the account's own data

In the application copy read on October 15, 2026, La Machine holds no register of dependence on platforms, no measure of exposure and no watch of a platform's terms. Control center → Tools (inventory) (/outils) lists tools with a version that is measured, a location and a date, and it measures no exposure, no revenue and no share of customers. Account → Profile → Privacy (account/privacy) exports the account's own data as a file and deletes the account after a typed confirmation phrase, which is an example of leaving a platform with one's data, on the user's side; it exports none of the data of a contact held in the customer relationship management system, and Book H2 (Privacy and Personal Information) holds personal information. A business should check it in its own installation. The case does not use La Machine, and La Machine is described and never sold.

Costly Mistakes

• Treating a notice that was not found as a promise that the terms will hold. A page that gives no notice period for changes says only that no notice period was found there, and a plan built on today's fee is a plan built on a term that may move.
• Measuring exposure on revenue alone. A platform can be small on revenue and large on operations, and a business that counts only the money will miss the platform whose failure stops its service.
• Setting the ceiling after the exposure exists. A ceiling written once the platform already brings most of the new business is not a ceiling; it is a description of what has already happened.
• Running a critical path through a platform. An alert, a payment or a promise that depends on a platform's availability is a promise the business cannot keep on the day the platform is down.
• Reading the entry studies as a forecast. Each of them is one platform and one period, and they point in different directions by setting; a complementor reads its own platform's incentives rather than predicting an entry.
• Diversifying by spreading rather than by order. Serving several platforms at once can cost quality, as one video game study reports in its one industry, so the second route is built before the first one is load-bearing.
• Taking a competition question to the wrong door. Whether a platform's conduct is unlawful is a question for the Tribunal or a court, and the question goes to Book H4 and to a lawyer rather than being decided by the business.

Key Takeaways

• Dependence on a platform builds one convenience at a time, and the power in the arrangement sits with the owner of the platform because the owner sets the terms and may change them; the asymmetry is intrinsic to the arrangement rather than a fault of a particular platform, as a conceptual analysis drawing on power-dependence theory reports, with no measured effect (Cutolo & Kenney, 2021, abstract only).
• A platform changes its terms with a notice, with a notice shorter than the business needs, or with no notice the business can find, and each platform's term is a contract of the day it was read; the notice that four terms give is set out in Table 6.2, and the 15 days of the European Union are a rule of another jurisdiction and a yardstick only (Regulation (EU) 2019/1150, art. 3).
• A fee moves in four ways — a threshold, a region and a kind of transaction, the life of an account, and a decision of the platform — and each is a term of the day it was read, never a market rate and never a term of the business's own, as the pages of one app store (Apple, n.d.), the other store (Google, n.d.) and one commerce platform (Shopify, n.d.) show.
• Exposure is measured on four things, revenue, customers, data and operations, and the ceiling is set in advance and read every quarter; the case's ceiling, posed by this book, is 40 percent of the new buildings of any quarter, with no alert path through any platform.
• The platform owner may become a competitor, and whether it does depends on the setting: the entry studies are one platform and one period each and point in different directions, so a complementor reads its own platform's incentives and writes in the register the products the owner could one day sell (Zhu, 2019, abstract only).
• Competition law is the right door for some questions and it is a lawyer's door: the Competition Act, ss. 75(1), 77(1), 78(1), 79(1), 79(3.1) and 103.1(1), current to September 21, 2026, is called to Book H4, section 79(1) has two alternative paths, and the three elements of the guidelines of 2019 predate the amendments (Competition Bureau, 2019).

Your Action Plan

1. Write the register of dependence and set the ceiling. List each platform the business depends on, write what is exposed for each on revenue, customers, data and operations, write the notice its terms give with the day the page was read, and write the way out in a sentence a colleague could follow. Deliverable: a register of one page per platform, with a ceiling set in advance. Verification: every row names a platform by its function, an exposure, a dated notice and a way out, and the ceiling is written before the exposure is measured.
2. Read the terms of each platform on the day you sign and every week after. Read the fee page, the distribution agreement and the program page of each platform, write the term and the day in the register, and note where no notice period was found. Deliverable: a dated reading of each platform's terms, with the notice each gives or the absence of one. Verification: each platform's terms carry a date of reading, and the weekly watch of Chapter 8 has run for four consecutive weeks.
3. Keep every critical path outside any platform. Name the paths that must not stop — above all the alert path — and confirm for each that it runs through no platform, with a written fallback for the day a platform is down. Deliverable: a list of critical paths with the fallback for each. Verification: each critical path has a fallback that a colleague could follow without the platform, and the fallback has been tested once.
4. Score a second route before the first one is load-bearing. Put the second candidate on the grid of Chapter 3, score it, and write the order in which the routes would be built if the first platform's terms moved past what the business can carry. Deliverable: a scored second candidate and a written order of routes. Verification: the second candidate has a score and a verdict, and the order is written before the first route is load-bearing.
5. Decide in advance what you will do when a fee moves or an account is limited. Write, for each platform, the level of fee the business cannot carry and the step it takes if the fee crosses it, and write who answers within a day when a removal or a suspension notice arrives. Deliverable: a written threshold and a named person for each platform. Verification: each platform has a written threshold and a named person, and the person has read the way out.

In La Machine

In the application copy read on October 15, 2026, the pages that touch this chapter are Control center → Tools (inventory) (/outils), an inventory of tools with a version that is measured, a location and a date, and Account → Profile → Privacy (account/privacy), which exports the account's own data as a file and deletes the account after a typed confirmation phrase (La Machine, 2026). The inventory is a model for a list of what a business runs, and the account page is an example of leaving a platform with one's own data, on the user's side. A business should check both in its own installation, and the case does not use La Machine (Books G8, I8 and L5).

What a business keeps outside the product is the register itself. La Machine holds no register of dependence on platforms, no measure of exposure on revenue, customers, data or operations, and no watch of a platform's terms; the inventory measures a version and not a dependence. The register, the ceiling, the dated reading of each platform's terms and the way out for each dependence live in a spreadsheet, a document or a tool the business chooses by function, and this book is valid with any tool. La Machine is described and never sold.

Self-Check

1. How does dependence on a platform build, and why does the power in the arrangement sit with the owner of the platform?
2. What are the three ways a platform changes its terms, and what notice does each of the four sources of section 6.2 give?
3. In what four ways does a fee move, and what does a business do about a fee that moves?
4. What are the four exposures, and why is the ceiling set in advance rather than after the exposure exists?
5. When is competition law the right door, and to whom does a question about a platform's conduct go?

Answers. 1. Dependence builds one convenience at a time, by small decisions that each look reasonable on the day they are taken, until the business cannot say what it would do without the platform; the power sits with the owner because the owner sets the terms and may change them, and the abstract of one conceptual analysis reports that this asymmetry is intrinsic to the economics and architecture of digital platforms, with no measured effect (Cutolo & Kenney, 2021, abstract only). 2. A platform changes its terms with a notice, with a notice shorter than the business needs, or with no notice the business can find; the guidelines of one app store gave no notice period (Apple, 2026), the other store's agreement gave at least 30 days after posting except a change required by law (Google, 2025), the European Union requires at least 15 days for the services it covers (Regulation (EU) 2019/1150, art. 3), a rule of another jurisdiction and a yardstick only, and the case's own term is an annual fee that rises with 60 days' notice, posed by this book. 3. A fee moves with a threshold, with a region and a kind of transaction, with the life of an account, and with a decision of the platform; a business reads the page on the day it signs, writes the term and the day in the register, reads the page again every week, and decides in advance what it will do if the fee crosses a level it cannot carry. 4. The four exposures are revenue, customers, data and operations; the ceiling is set in advance because a ceiling written once the platform already brings most of the new business is a description of what has happened rather than a limit on what may happen, and the case's ceiling, posed by this book, is 40 percent of the new buildings of any quarter with no alert path through any platform. 5. Competition law is the right door for a question of refusal to deal, exclusive dealing or abuse of dominance, and it is a lawyer's door: the Competition Act, ss. 75(1), 77(1), 78(1), 79(1), 79(3.1) and 103.1(1), current to September 21, 2026, is called to Book H4, section 79(1) has two alternative paths, and the three elements of the guidelines of 2019 predate the amendments (Competition Bureau, 2019); a question about a platform's conduct goes to Book H4 and to a lawyer, and only the Tribunal or a court decides it, because this book draws no conclusion about any platform.

Chapter References

Apple. (2026). App Store Review Guidelines (last updated June 8, 2026). Apple Developer. Retrieved October 15, 2026, from https://developer.apple.com/app-store/review/guidelines/

Apple. (n.d.). App Store Small Business Program. Apple Developer. Retrieved October 15, 2026, from https://developer.apple.com/app-store/small-business-program/

Cennamo, C., Ozalp, H., & Kretschmer, T. (2018). Platform architecture and quality trade-offs of multihoming complements. Information Systems Research, 29(2), 461–478. https://doi.org/10.1287/isre.2018.0779

Civil Code of Québec, CQLR c CCQ-1991, arts. 1379, 1435, 1436 and 1437 (Québec). LégisQuébec, up to date to August 12, 2026 — read October 15, 2026. https://www.legisquebec.gouv.qc.ca/en/document/cs/CCQ-1991

Competition Act, R.S.C. 1985, c. C-34, ss. 75(1), 77(1), 78(1), 79(1) to (3.1) and 103.1(1) (Canada). Justice Laws Website, current to September 21, 2026 (last amended March 26, 2026) — read October 15, 2026. https://laws-lois.justice.gc.ca/eng/acts/C-34/

Competition Bureau. (2019). Abuse of dominance enforcement guidelines. Government of Canada. (Enforcement guidelines dated March 7, 2019; page modified June 27, 2024.) Retrieved October 15, 2026, from https://competition-bureau.canada.ca/en/how-we-foster-competition/education-and-outreach/abuse-dominance-enforcement-guidelines

Cutolo, D., & Kenney, M. (2021). Platform-dependent entrepreneurs: Power asymmetries, risks, and strategies in the platform economy. Academy of Management Perspectives, 35(4), 584–605. https://doi.org/10.5465/amp.2019.0103

European Commission. (n.d.). Gatekeepers Portal [Digital Markets Act]. Retrieved October 15, 2026, from https://digital-markets-act.ec.europa.eu/gatekeepers-portal_en

Foerderer, J., Kude, T., Mithas, S., & Heinzl, A. (2018). Does platform owner's entry crowd out innovation? Evidence from Google Photos. Information Systems Research, 29(2), 444–460. https://doi.org/10.1287/isre.2018.0787

Gawer, A., & Henderson, R. (2007). Platform owner entry and innovation in complementary markets: Evidence from Intel. Journal of Economics & Management Strategy, 16(1), 1–34. https://doi.org/10.1111/j.1530-9134.2007.00130.x

Google. (2025). Google Play Developer Distribution Agreement (effective September 15, 2025). Retrieved October 15, 2026, from https://play.google/developer-distribution-agreement.html

Google. (n.d.). Service fees. Play Console Help. Retrieved October 15, 2026, from https://support.google.com/googleplay/android-developer/answer/112622?hl=en

Huang, P., Ceccagnoli, M., Forman, C., & Wu, D. J. (2013). Appropriability mechanisms and the platform partnership decision: Evidence from enterprise software. Management Science, 59(1), 102–121. https://doi.org/10.1287/mnsc.1120.1618

Kapacinskaite, A., & Mostajabi, A. (2024). Competing with the platform: Complementor positioning and cross-platform response to entry. Strategic Management Journal, 45(12), 2577–2607. https://doi.org/10.1002/smj.3643

Kapoor, R., & Agarwal, S. (2017). Sustaining superior performance in business ecosystems: Evidence from application software developers in the iOS and Android smartphone ecosystems. Organization Science, 28(3), 531–551. https://doi.org/10.1287/orsc.2017.1122

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /outils and account/privacy.

Li, Z., & Agarwal, A. (2017). Platform integration and demand spillovers in complementary markets: Evidence from Facebook's integration of Instagram. Management Science, 63(10), 3438–3458. https://doi.org/10.1287/mnsc.2016.2502

Regulation (EU) 2019/1150 of the European Parliament and of the Council of 20 June 2019 on promoting fairness and transparency for business users of online intermediation services, OJ L 186, 11.7.2019, p. 57, arts. 1, 3, 4, 8, 9 and 11 (European Union). Read October 15, 2026 through the Publications Office of the European Union (EUR-Lex answered 202 with an empty body). https://eur-lex.europa.eu/eli/reg/2019/1150/oj

Regulation (EU) 2022/1925 of the European Parliament and of the Council of 14 September 2022 on contestable and fair markets in the digital sector and amending Directives (EU) 2019/1937 and (EU) 2020/1828 (Digital Markets Act), OJ L 265, 12.10.2022, p. 1, arts. 3, 5 and 6 (European Union). Read October 15, 2026 through the Publications Office of the European Union. https://eur-lex.europa.eu/eli/reg/2022/1925/oj

Shopify. (n.d.). Revenue share [App distribution]. Shopify Dev Docs. Retrieved October 15, 2026, from https://shopify.dev/docs/apps/launch/distribution/revenue-share

Wen, W., & Zhu, F. (2019). Threat of platform-owner entry and complementor responses: Evidence from the mobile app market. Strategic Management Journal, 40(9), 1336–1367. https://doi.org/10.1002/smj.3031

Zhu, F. (2019). Friends or foes? Examining platform owners' entry into complementors' spaces. Journal of Economics & Management Strategy, 28(1), 23–28. https://doi.org/10.1111/jems.12303

Zhu, F., & Liu, Q. (2018). Competing with complementors: An empirical look at Amazon.com. Strategic Management Journal, 39(10), 2618–2642. https://doi.org/10.1002/smj.2932

Chapter 7 — Data, Identity and Integration Architecture

An integration is a promise about data, and the promise is kept by identity, signatures and the right to leave: this chapter says who owns the data that cross an integration, how access is delegated and limited to what a job needs, how a customer's staff sign in and how users are provisioned and removed across systems, how a webhook is signed, retried and made idempotent, how the contract between two systems is described and versioned, what personal information travels with an integration, which logs and limits a small firm keeps and how it leaves with its data, and what a reference architecture for a small firm looks like, then applies all of it to the alert event and its work order at Hydrosentinelle inc., where 1,240 events were relayed and 0 duplicate work orders were opened on day 365, posed by this book.

What You'll Be Able to Do

• Name the three kinds of data that cross an integration and say who owns each, who may use it and who may keep a copy.
• Design a delegated access that gives an integrator the narrowest rights its job needs, with a way to take those rights back.
• Decide whether to accept a customer's sign-in, and keep sign-in and provisioning apart, because one does not do the work of the other.
• Specify an event that carries an identifier, a timestamp and a signature, is retried when a delivery fails, and never opens a second record when it arrives twice.
• Describe the contract between two systems in a versioned description, and say what a change that adds a field and a change that removes one do to a consumer.
• Plan the logs, the limits and the exit that let a small firm answer a customer, protect a service and leave with its data.

Why It Matters

An integration is where two companies touch each other, and what touches is data. The moment a business sends an alert to a customer's system, reads a customer's buildings or lets an integrator read its own records, three sets of data are in play at once: the business's own, the customer's and the personal information of the people who live in or work in the buildings. Who owns each set, who may use it, who may keep a copy and for how long are questions that a contract and the law answer, and not questions that the place where the data happen to sit answers. A business that assumes that the data are its own because its servers hold them, or that the data are the customer's because the customer's system displays them, has not answered the question; the business has only postponed it to the day the relationship ends.

On this book's own reasoning, the failures of this layer are quiet. A field is added to an event because the field is available, and personal information starts to travel on a path that nobody designed for it. A delivery fails, the sender retries, and the receiver opens a second work order for the same leak. A member of a customer's staff leaves, and the account stays open in a service that nobody remembers to check. A key is shared between two integrators, and one of them has to be removed.

The case makes the stakes concrete. Hydrosentinelle inc. sends one signed event for each alert to the first property-management system, where the event opens one work order, and the alert itself goes directly by text message and by email and runs through no platform at all. Every figure of the case is posed by this book, nothing in the figures is measured, and nothing is credited to the integration or to the interface. What the case illustrates is a design decision: the path that must never fail was kept outside every platform, and the path that may fail was built to be signed, retried and harmless when it repeats.

In This Chapter

Section 7.1 asks who owns the data that cross an integration and sets the four questions to answer before any data cross. Section 7.2 covers delegated access and scoped permissions, and the accesses of the case's public interface. Section 7.3 covers single sign-on for a customer's staff. Section 7.4 covers provisioning and removing users across systems. Section 7.5 covers webhooks that are signed, retried and idempotent. Section 7.6 covers the contract between two systems, its schemas and its versions. Section 7.7 covers the personal information that travels with an integration. Section 7.8 covers logs, limits and the right to leave with your data. Section 7.9 sets out a reference architecture for a small firm, layer by layer. Section 7.10 returns to the case's alert event and its work order, and to the two paths of one alert.

7.1 Who Owns the Data That Crosses an Integration

Three kinds of data cross an integration, and they do not have the same owner. The first is the company's own data: the readings of its sensors, the alerts its service raises, the records of its devices and the identifiers it gives them. The second is the customer's data: the buildings, the units, the work orders and the staff accounts that live in the customer's own system, which the customer's organization decides about. The third is personal information about people: tenants, occupants, staff and contractors, whose names, unit labels, times and locations may be enough to identify a person when they are read together. A single event can carry all three at once, which is why the question of ownership is asked before the event is designed and not after it is live.

Who owns a set of data, who may use it and who may keep a copy are settled by the contract between the two companies and by the law that applies to each of them, and not by where the data sit. The contracts that settle those questions are Book H1's (Contracts and Commercial Agreements) and a lawyer's, and the intellectual property of an interface and of its terms of use is Book H5's (Intellectual Property). This chapter does not draft a clause and does not read one; it says which questions a contract has to answer.

Four questions are worth asking before any data cross, and they are this book's own checklist and not a rule of law. The first question is what crosses: which fields, in which direction, at which moment, and which of them are personal information. The second is who decides that it crosses: which party turns the flow on, which party can turn it off, and what notice the other party gets. The third is who may keep a copy and for how long: whether the receiving system stores the event, whether the sending system logs it, and what happens to each copy when the integration ends. The fourth is what happens to the copies when the integration ends: which copies are deleted, which are kept for a legal or accounting reason, and by what date.

The personal information that crosses an integration is called to the book that holds it. The Act respecting the protection of personal information in the private sector, CQLR c P-39.1, up to date to August 12, 2026 and read on October 15, 2026, asks in section 3.3 for a privacy impact assessment for any project to acquire, develop or overhaul an information system involving personal information, with the person in charge consulted from the outset, and requires the system to allow computerized information collected from a person to be communicated to that person in a structured, commonly used technological format; the mechanics of that provision are Book H2's (Privacy and Personal Information), and this chapter states the provision and refers to the book that holds it. Whether a given integration triggers that assessment, and what the assessment must contain, is a question for Book H2 and an adviser, and this book decides nothing about it.

The data of the case that cross an integration are two, and both are posed by this book. The first is the alert event that the company sends to the first property-management system, which carries the building, the unit label, the sensor's location, the time and the severity, and no tenant's name. The second is the read access that the public interface of version 1 gives to an approved integrator, which reaches buildings, sensors and alerts and nothing else. The event is designed to carry the least that the receiver's job requires.

The table below sets seven neighbors of this chapter beside what each holds and what this chapter holds, so that a reader can see where the boundary runs before the architecture is described. Nothing of those neighbors is rewritten here, and this chapter is the architecture of the data, the identity and the event layer of an integration between companies. Read the third column as the part of the work that this chapter owns.

Table 7.1 — The neighbors of this chapter and what each holds

DEFINITION Data owner, delegated access, identity provider, webhook and idempotency, as this book uses the words

These are this book's working words, and no source read defines them in this sense. A data owner is the party that a contract and the law, and not the place where the data sit, name as the one who decides what is done with a set of data. Delegated access is the right of an application to act for a person or on its own behalf with limited rights and without that person's password. An identity provider is the service that confirms who a person is so that other services can accept the sign-in. A webhook is a message that one system sends to another when something happens. Idempotency means that a repeated delivery has the same effect as one. The framework of 2012 and the specification of the identity layer are cited in their sections, and the case's figures are posed by this book.

KEY CONCEPT Every integration is a promise about data, and the promise is kept by identity, signatures and the right to leave

An integration moves data between two companies, so the contract says who owns the data and who may keep a copy, identity limits who may read or write and can take that right back, a signature and an identifier make a delivery dependable even when it is retried, and the right to leave with the data is planned while the relationship is still good. This is the book's reasoning and never a finding: no source read measures what an integration returns, how many integrations a small firm keeps, how often a delivery fails or what a security practice costs. The case's figures are the case's own and are posed by this book: version 1 of the public interface, a limit of 120 requests a minute for each integrator, 1,240 events relayed and 0 duplicate work orders on day 365. Nothing in that sentence is measured, and nothing is credited to the integration or to the interface.

7.2 Delegated Access and Scoped Permissions

Delegated access lets one application act for a person or on its own behalf with limited rights and without that person's password, and it is one way an integration reaches another company's data. The alternative, a shared password or a key copied into a configuration file, gives the same rights to everyone who holds the copy. Delegated access is not a security guarantee by itself; it is a framework for limiting what an application may do and for ending that permission.

The framework is the one of 2012. The text of RFC 6749, read at the RFC Editor on October 15, 2026, establishes that the framework lets a third-party application obtain limited access to an HTTP service, either on behalf of a resource owner through an approval interaction or on its own behalf (Hardt, 2012). It is a Standards Track document, and the RFC Editor's catalog lists it as updated by RFC 9700 among others, with RFC 8252 and RFC 8996 also listed. The framework says nothing about security practice beyond its own text, and a business that reads it as a complete security answer has read more into it than it says.

The practice that updates it is a best current practice, and it is a practice and never a rule of law. The text of RFC 9700, read on October 15, 2026, establishes that redirection addresses are compared by exact string, except the port numbers of localhost redirection addresses of native apps; that public clients must use proof key for code exchange; that the implicit grant should not be used; that access tokens should be restricted to the minimum privileges and to a specific resource server; and that the resource owner password credentials grant must not be used (Lodderstedt et al., 2025). The proof key answers an attack that the text of RFC 7636, read on October 15, 2026 for its abstract and for its use in RFC 9700, describes: public clients using the authorization code grant are exposed to the interception of the code, and the specification describes the attack and a mitigation by a proof key (Sakimura et al., 2015).

The principle that a small firm applies is least privilege, and it is this book's own reasoning and not a standard. Give an integrator only what its job needs, for as long as the job needs it, and keep a way to take the right back. An integrator that reads buildings and alerts does not need to write work orders; an integrator that receives one event does not need to read the whole building list; a partner that tests in a sandbox does not need production credentials. The notions of authentication and of a secret as integration concepts are Book K8's (No-Code, Low-Code and Integrations, chapter 2 of Book K8), and this chapter cites them rather than retelling them.

The case's public interface, version 1, was described on day 60 and lists read access and two events and nothing else, and every grant in the table below is posed by this book. Two integrators were approved on days 75 and 88 under written terms of use, and four use the interface on day 365; 1 key was rotated and 0 integrator was removed. The table sets five accesses of version 1 beside what each lets a party do and the grant the case makes, so that a reader can see how narrow an interface can be and still be useful. Read the third column as the case's own design and never as a model for another business.

Table 7.2 — The accesses of the case's public interface, version 1 (posed)

THE RULE A public client uses a proof key for code exchange, and an access token is limited to the minimum privileges

The text of RFC 9700, read on October 15, 2026, establishes that public clients must use proof key for code exchange, that access tokens should be restricted to the minimum privileges and to a specific resource server, that the implicit grant should not be used, and that redirection addresses are compared by exact string, except the port numbers of localhost redirection addresses of native apps (Lodderstedt et al., 2025). It is a best current practice that updates the framework of 2012, and it is never a rule of law. Adapted by this book for a small firm that opens an interface, the rule is this: each integrator receives its own credentials and the narrowest access its job needs, and the business keeps a way to end that access. The rule is the book's own for the case and a legal duty of nobody. The case grants read access and two events to each approved integrator, posed by this book.

WHAT CHANGED In 2025 a best current practice for delegated access was published, and the framework of 2012 is updated by it

The dated change comes from the two texts read on October 15, 2026. The framework of 2012 lets a third-party application obtain limited access to an HTTP service, either on behalf of a resource owner through an approval interaction or on its own behalf (Hardt, 2012). The best current practice of 2025, RFC 9700, updates it among other updates, with the requirement that public clients use proof key for code exchange and the advice against the implicit grant (Lodderstedt et al., 2025). The change is dated by the documents themselves, 2012 and 2025, and the practice is a practice that changes and never a rule of law. The dates of sources are never dates of the case: Hydrosentinelle inc. is counted in days, and no calendar year and no calendar month is given to an event of the business.

7.3 Single Sign-On for a Customer's Staff

Single sign-on lets the staff of a customer use the sign-in of their own organization instead of keeping a separate password for each service. The cost of accepting it is easy to underestimate, because accepting a customer's sign-in is a decision about identity that a business makes once for each product and each kind of customer, and it changes what the business has to maintain.

The identity layer that does the work is a final specification of a foundation, read on October 15, 2026 at its first part. The specification establishes that it is a simple identity layer on top of the authorization framework that lets a client verify the identity of an end user from an authorization server's authentication and obtain basic profile information; a client asks for it with the openid scope, and the result is an ID Token, a JSON Web Token carrying claims about the authentication such as the issuer, the subject and the time (Sakimura et al., 2023). The specification makes no choice between identity providers, and this section names none.

What the specification means for a small firm is narrower than it sounds. Accepting a customer's sign-in means that the business trusts another organization's service to say who a person is, and that the business reads a small set of claims about that person rather than managing a password. It does not mean that the business knows which of the customer's staff should see which building, and it does not mean that a person who leaves the customer's organization loses access to the business's service; that is the subject of the next section, and the two functions are separate. A business that treats single sign-on as the whole of identity management will discover the difference on the day a customer asks why a former employee can still sign in.

Whether to accept a customer's sign-in is a decision made once for each product and each kind of customer, and it is read at its price in effort on the grid of Chapter 3 and never promised in advance.

The case's plan contains no single-sign-on work, and that is posed by this book. The public interface of version 1 uses client credentials for each approved integrator and not a user's sign-in, because the parties that use the interface are integrators and not the customer's staff. The staff of the largest customer sign in to the company's own service and to the customer's own property-management system separately.

One caution belongs in this section. A plans page can list single sign-on among the features of some plans while the application copy read has no screen for it, and a buyer checks the screen before relying on it. In the application copy of La Machine read on October 15, 2026, the plans page lists interface access and single sign-on among the features of some organization plans, and neither has a screen and no server code implements either (La Machine, 2026). The lesson is general and blames no one: a feature on a page is a claim, and a screen is a fact.

7.4 Provisioning and Removing Users Across Systems

Provisioning is creating, changing and removing the accounts of a customer's staff in a service from the customer's own directory, and it is a different function from sign-in. Sign-in answers who a person is; provisioning answers which accounts exist and what each may do. A business can accept a customer's sign-in and still create every account by hand, and a business can provision accounts automatically while keeping its own passwords. The two may be asked for together, and they are built separately.

The protocol that carries provisioning across domains is read as published. The text of RFC 7644, read on October 15, 2026, establishes that it is an HTTP-based protocol to manage identities across domains, such as enterprise-to-cloud services, meant to reduce the cost and complexity of user management with a common user schema, an extension model and a service protocol (Hunt et al., 2015). It is a Standards Track document, and the RFC Editor's catalog now notes updates by RFC 9865 and RFC 9967, which were not read. This section states nothing beyond that, and it names no product that implements the protocol.

The moment that matters most in provisioning is the removal. A person who leaves a customer's organization should lose access the same day in every system that holds an account for that person, and a rule of the book's own, not a legal duty, is that the removal is checked rather than assumed. The same holds for an integrator's key: when a relationship ends, the key is revoked rather than left in a configuration file, and the revocation is written down with its date.

The table below sets three moments in the life of an account beside what must change in each system and what to check, so that a reader can see the whole of a small provisioning routine in three rows. It comes from the book's reasoning and from no source's finding, and the leaver row is the one that costs the most when it is forgotten. Read the third column as the check that a second person can perform.

Table 7.3 — Joiner, mover and leaver across two systems

In the case, the users of the public interface are integrators and not staff, and that is posed by this book. Two integrators were approved on days 75 and 88 under written terms of use, and four use the interface on day 365; an integrator can be removed and a key rotated, and on day 365, 1 key was rotated and 0 integrator was removed. The company's own staff accounts and the customer's staff accounts live in systems that this chapter does not describe, and the case says nothing about them. What the case does show is the shape of the rule: the party that holds a key is a party that can be removed, and the removal is a written act with a date.

A business that sells to organizations decides early which of the two functions it will support and which it will decline, because a customer's security questionnaire asks about both; the answer is read at its price in effort on the grid of Chapter 3, and the security review that follows is Chapter 4's. This chapter's part is to keep the two functions apart in the design.

7.5 Webhooks: Signed, Retried and Idempotent

A webhook is a message that one system sends to another when something happens, and three properties make it dependable: a signature that proves who sent it, a retry that covers a failed delivery, and an identifier that makes a repeated delivery harmless. The notions of a webhook and of polling as integration concepts are Book K8's (No-Code, Low-Code and Integrations, chapter 2 of Book K8), and this chapter cites them rather than retelling them.

The community specification that describes the shape of a signed delivery is a community text and not a standards body's. The specification, version 1.0.0, read on October 15, 2026, establishes three headers, an identifier unchanged across retries, a timestamp and a signature list that allows key rotation; the signed content is the identifier, the timestamp and the body joined by full stops, with HMAC-SHA256 or an asymmetric signature; the identifier serves as an idempotency key; a consumer rejects a timestamp outside a tolerance, and the specification gives no value for that tolerance; retries span several days with exponential backoff, and an example schedule reaches about three days; a consumer answers 2xx for success and 410 to stop deliveries (Standard Webhooks, n.d.). It is a community specification, and it imposes no requirement of law on any business.

The reason a retry needs an identifier is in the text of the HTTP specification. The text of RFC 9110, section 9.2.2 read on October 15, 2026, establishes that a method is idempotent if several identical requests have the same intended effect on the server as one; that PUT, DELETE and the safe methods are idempotent; and that a client should not automatically retry a non-idempotent request unless it knows the semantics are idempotent or can detect that the original was never applied (Fielding et al., 2022). The text says nothing about webhook practice, and the practice of keying a receiver on the identifier comes from the community specification and from the book's reasoning.

The case's design follows that shape, and every part of it is posed by this book. The events are signed with HMAC-SHA256 over the identifier, the timestamp and the body, and a repeated delivery carries the same identifier and never opens a second work order. The table below sets five elements of a signed delivery beside what the community specification says and what a receiver does, so that a reader can see the division of labor between the sender and the receiver. The specification is a community text, it gives no tolerance value, and the case's design is posed by this book and is never a claim that the case follows the specification.

Table 7.4 — What a signed delivery carries and what the receiver does

WATCH OUT Sending more data than the integration needs, and treating a retried delivery as a new event, are two traps

Two traps catch an integration, and each has a question that catches it. The first is sending more data than the integration needs: a field is added because it is there, and personal information starts to travel on a path that nobody designed for it. The question is which field the receiver's job requires, and whether the event can carry less; the case's event carries no tenant's name, posed by this book. The second is treating a retried delivery as a new event: the receiver acts twice on the same message and opens a second work order for the same leak. The question is which identifier the receiver keeps, and what the receiver does when it sees the same one again; the case's events carry an identifier and a repeated delivery never opens a second work order, posed by this book. The book's reasoning is illustrative, and no frequency of either trap in any business is printed.

METHOD Designing the data flow of one integration in five steps

First, list the data that must cross, field by field, and keep only what the receiver's job requires. Second, decide who owns each set of data and who may keep a copy, with the contract that says so. Third, choose the access, whether read, event or write, limit it to the minimum, and give each integrator its own credentials. Fourth, give each event an identifier, a timestamp and a signature, and write what the receiver does when it sees a repeated identifier. Fifth, write the limit, the version and the way out, then test in a sandbox before any customer data cross. This is the book's reasoning drawn from the sources of the chapter and not a tested procedure. The case follows these steps for its first integration, posed by this book, and no step promises a result.

7.6 Contracts Between Systems: Schemas and Versions

A contract between two systems is the list of what one may send, what the other will accept and what happens when either changes, and it is written down rather than remembered. The list has two parts: the schema, which says which fields an event or a response carries and what each means, and the version, which says which of those fields a consumer may rely on and for how long. A business that keeps the contract in the head of the person who built the integration has a contract that leaves when that person is busy.

The description specification that makes such a contract readable is read at its latest page. The specification, version 3.2.1 of September 10, 2026, read on October 15, 2026, establishes that it is a standard, programming-language-agnostic description of HTTP interfaces that lets people and computers discover what a service can do without its source code, other documentation or traffic inspection, and that the description has a field for the webhooks a consumer may receive (OpenAPI Initiative, 2026). This section prints no more of it, and it names no tool that renders it; the tools that render and test such a description are Chapter 10's (section 10.4).

The distinction that matters most in practice is between a change that adds and a change that removes. A change that adds an optional field leaves an existing consumer working, because the consumer reads the fields it knows and ignores the rest. A change that removes a field, renames a field or changes what a field means breaks a consumer, and the break may be silent: a consumer that reads a missing field as empty may open a work order with no location. The book's reasoning is that the two kinds of change are treated differently, and that the difference is written into the terms of use rather than left to a conversation.

A new version runs beside the old one for a notice period that the terms of use state, and the period is the firm's own and no source read gives a norm for it. A small firm that opens an interface should write the period down before the first integrator is approved, because a period invented after a change is a period that the integrator did not agree to. The terms of use of the case's public interface were drafted by the outside lawyer, and the period they state is the case's own and is not printed here.

The case's contract is small and it is posed by this book. The event carries the building, the unit label, the sensor's location, the time and the severity, and no tenant's name; version 1 lists two events and read access and nothing else; and the description of the interface was written by day 60 under Laurence Bergeron. A consumer of the case's event can rely on those five fields and on the identifier, the timestamp and the signature that every delivery carries, and a change to any of them is a change to the contract. The company's own record of the contract is the description itself, kept with the terms of use, and the version number is the name of the promise.

One habit keeps a contract honest, and it is this book's own: the description is the source of truth, so that a field added in code and not in the description is a field that no consumer may rely on. It is not a legal duty, and it does not replace the terms of use that a lawyer drafts.

7.7 Personal Information That Travels With an Integration

An integration carries personal information when an event, a log or an export names a person or can identify one, and the first design choice is to send less. A unit label with a time and a location may identify a person when it is read beside a building's tenant list, even though the event itself carries no name; a log that keeps the whole body of every delivery keeps whatever the body carried; an export that a customer requests may hold more than the customer needs. The question is not whether a field is a name, but whether the set of fields, read together, points at a person.

The provisions of the Québec private-sector Act that an integration meets are called to Book H2 in one sentence, with their jurisdiction and their date. The Act respecting the protection of personal information in the private sector, CQLR c P-39.1, up to date to August 12, 2026 and read on October 15, 2026, asks in section 3.3 for a privacy impact assessment for any project to acquire, develop or overhaul an information system involving personal information, and requires the system to allow computerized information collected from a person to be communicated to that person in a structured, commonly used technological format. Section 17 asks, before personal information is communicated outside Québec, for an assessment and a written agreement. Section 18.3 lets information be communicated without consent to a mandatary or a contractor if necessary, with the mandate in writing and the protection measures specified. Section 27 gives access and communication in a structured format, a right that covers only computerized information collected from the applicant and not information created or inferred using personal information concerning the applicant. The mechanics of all four are Book H2's (Privacy and Personal Information), and this chapter states the provisions and refers to the book that holds them.

The table below sets four provisions of the Québec Act beside what the text says and the place where an integration meets each, so that a reader can see where the law touches a design. The Act is called to Book H2 and is never rewritten here, the third column is the book's reasoning, and nothing in the table says whether the reader's own integration complies. Read the third column as a place to look and not as an answer.

Table 7.5 — The provisions of the Québec Act that an integration meets

The case's event carries no tenant's name, and the privacy impact assessment was completed on day 86 under Laurence Bergeron, both posed by this book. Whether a unit label with a time identifies a person is a question for Book H2 and an adviser, and this book decides nothing about it; the case does not say where any data are stored, and this chapter invents no location. Book H2 holds personal information, this book explains published rules and recommends no vendor, and a lawyer or a privacy adviser reads the integration.

QUÉBEC & CANADA NOTE Personal information that travels with an integration is a question for Book H2, and this book is not legal advice

The Canadian point of this section is the Québec private-sector Act. The Act respecting the protection of personal information in the private sector, CQLR c P-39.1, ss. 3.3, 17, 18.3 and 27, Québec, up to date to August 12, 2026 and read on October 15, 2026, is called to Book H2 in one sentence: it asks for a privacy impact assessment for a project to acquire, develop or overhaul an information system involving personal information, it asks for an assessment and a written agreement before personal information is communicated outside Québec, it allows a communication to a mandatary or a contractor under a written mandate with specified protection measures, and it gives access and communication in a structured format for computerized information collected from the person and not for information created or inferred. This book explains the law as published and is not legal advice. This book explains published rules and recommends no vendor. A reader with a question about an integration's own data flow should read Book H2 and ask a lawyer or a privacy adviser. The case's event carries no tenant's name and its privacy impact assessment was completed on day 86, posed by this book, and nothing here says whether the reader's own integration complies.

7.8 Logs, Limits and the Right to Leave With Your Data

A log of deliveries lets a firm answer a customer who asks whether an alert event arrived, and it is the smallest record that does the job. The useful columns are the identifier, the attempt, the answer and the time, and the useful discipline is to keep as little personal information as the event itself carries. A log that keeps the whole body of every delivery keeps whatever the body carried, and a log that keeps only the identifier and the answer can still answer the customer's question. The governance of data inside a business, including who may read a log and how long it is kept, is Book J8's (Data Management and Business Intelligence), and this chapter cites it rather than retelling it.

A limit protects the service, and the status that reports it is defined without a rule for counting. The text of RFC 6585, section 4 read on October 15, 2026, establishes that status 429 means too many requests in a given time, that the response should explain the condition and may carry a Retry-After header, and that the specification does not define how a server counts requests and prints no particular limit (Nottingham & Fielding, 2012). The case's limit of 120 requests a minute for each integrator is therefore posed by this book, and it is neither a norm nor a market figure; a business that opens an interface chooses its own limit and writes it in the terms of use.

The right to leave is planned while the relationship is still good, and it has three parts. The first is an export in a structured format, so that the data leave in a form another system can read. The second is a list of what is kept and for how long, so that a copy kept for an accounting reason is distinguished from a copy kept by habit. The third is a date after which the copies are deleted, so that the end of the relationship has an end. A firm that depends on a platform or serves a customer plans its exit before it is asked for one, and the exposure that the exit reduces is Chapter 6's.

The right to a structured format is narrower than it sounds, and the text says so. Section 27 of the Act respecting the protection of personal information in the private sector, up to date to August 12, 2026 and read on October 15, 2026, gives access and communication in a structured, commonly used technological format only for computerized information collected from the person, and not for information created or inferred using personal information concerning the person; the provision is called to Book H2, and this chapter states it and refers to the book that holds it. A business that promises more than the provision gives has promised something it may not be able to deliver.

One page of La Machine is worth naming here because it is an example of leaving on the user's side. In the application copy read on October 15, 2026, Account → Profile → Privacy (account/privacy) exports the account's own data as a file and deletes the account after a typed confirmation phrase (La Machine, 2026). It is an example of leaving a platform with one's data, and it exports none of the data of a contact held in a customer relationship management system. What a platform lets a business take out when it leaves is a term to read, and Chapter 6 sets the register in which that term is written.

TOOLS OF THE TRADE What any layer that signs, retries and logs deliveries must offer, whatever it is called

Nine functions carry this layer, and a business should look for them rather than for a product. The first is a signature on every delivery that the receiver can check. The second is a stable identifier for each event that is unchanged across retries. The third is a timestamp and a way to refuse one that is too old. The fourth is retries with a growing delay and a stop when the receiver says to stop. The fifth is a log of each attempt with its answer and its time. The sixth is a way to rotate a key without stopping deliveries. The seventh is a limit for each integrator and an answer that explains the condition. The eighth is a sandbox that sends test events. The ninth is an export of the log in a form another tool can read. No brand name belongs on this list and no price; the requirement is the function.

7.9 A Reference Architecture for a Small Firm

A reference architecture is a way of holding seven small layers in mind, and it is this book's suggestion and not a standard. The first layer is the alert path, which runs through no platform and carries the message that must arrive, and the six that follow are the event layer, the interface layer, the identity layer, the record of integrations, the log layer and the exit layer. Each layer is small, and the whole is smaller than a platform.

The identity layer follows the framework of 2012 and the practice already read in section 7.2: the framework lets a third-party application obtain limited access to an HTTP service, either on behalf of a resource owner through an approval interaction or on its own behalf (Hardt, 2012), and the practice restricts an access token to the minimum privileges and to a specific resource server (Lodderstedt et al., 2025). Security, backups and continuity are Book K3's (Cybersecurity, Backups and Business Continuity), and the choice of a stack is Book K1's (The SME Technology Stack); this chapter cites both and retells neither.

The table below sets seven layers beside what each does and the case's own layer, so that a reader can see the whole architecture in one place. No tool is named and none is chosen for the case, and the layers are the book's suggestion and not a standard. Read the third column as the case's design, posed by this book, and never as a model that another business should copy.

Table 7.6 — A reference architecture for a small firm, layer by layer

The pages of La Machine that touch this chapter are worth naming one by one, with their limits. In the application copy read on October 15, 2026, Control center → n8n (/n8n) shows a self-hosted workflow engine whose workflow definitions are versioned files published by a script, never clicks on a screen, and it is the publisher's own engine and never an integration offered to a reader's customers (La Machine, 2026). Control center → Hermes (/hermes) shows a local agent gateway whose agent routes are signed with HMAC-SHA256 over the raw body and carry a request identifier, so that a duplicate is recognized and a genuine retry is not dropped; it is an example of how one installation signs its own calls and never a webhook offered to a customer. Control center → Audit log (/journal) traces what happened to a record, never why, and it is never a log of the calls of a reader's integration. Support → Plans & Pricing (plans) lists interface access and single sign-on among the features of some organization plans, and in the application copy read neither has a screen and no server code implements either. Account → Profile → Privacy (account/privacy) exports the account's own data as a file.

What a business needs elsewhere is the rest of the architecture. La Machine offers no documented public interface, no interface description, no developer portal and no sandbox; no page where a user creates, rotates or revokes an interface key; no webhook that a user can configure and sign for a customer; no single sign-on and no provisioning of users between systems; and no rate limiter. Those layers are chosen by function, and Chapter 10 holds the tool tables that describe the functions. La Machine is one worked example of a business platform, described and never sold, and the case does not use it; a reader should check it in an installation.

WHO DOES THIS Laurence Bergeron designs the event, the outside integration developer builds it, and the largest customer's operations manager receives the work order

The roles below are the case's, posed by this book. Laurence Bergeron, the president, product and engineering, designs the alert event and its work order, the public interface and its first version, answers the security questionnaire and holds the privacy impact assessment, and writes the acceptance criterion. The outside integration developer builds the first integration under a fixed fee posed by this book. The outside lawyer drafts the terms of use of the public interface. The operations manager of the largest customer receives the work orders. Karim Haddad, the head of sales and operations, holds the partner terms and the relationship with the first platform. The integrators are approved users of the public interface and are a group. In general, one person owns each integration and a second person can rotate its keys, which is the book's suggestion and is not in the case. In a solo business the owner holds every role and asks an outside developer for the build; in a larger business a security lead reads each integration. No hour and no amount is promised to a reader.

IN LA MACHINE The workflow engine and the gateway sign their own calls, the plans page lists interface access without a screen, and the audit log traces a record and not an integration

In the application copy read on October 15, 2026, Control center → n8n (/n8n) shows a self-hosted workflow engine whose definitions are versioned files (La Machine, 2026). Control center → Hermes (/hermes) shows an agent gateway whose routes are signed with HMAC-SHA256 over the raw body and carry a request identifier, an example of how one installation signs its own calls and never a webhook offered to a customer. Control center → Audit log (/journal) traces what happened to a record, never why, and it is never a log of a reader's integration. Support → Plans & Pricing (plans) lists interface access and single sign-on although the copy read has no screen for either. Account → Profile → Privacy (account/privacy) exports the account's own data. La Machine offers no documented public interface, no interface key a user manages, no configurable webhook and no single sign-on; a reader should check it in an installation. La Machine is described and never sold, and the case does not use it.

7.10 The Case's Alert Event and Its Work Order

One alert has two paths, and the case's design keeps them apart. A sensor reports to the gateway, and the gateway reports to the company's monitoring service. From there the alert path goes directly by text message and by email to the people of the building, and it runs through no platform at all. The second path sends a signed event to the customer's property-management system, where the event opens one work order, and a failed delivery is retried. The first path is the one that must arrive; the second is a convenience that may fail without silencing an alert. Book A7 (Pricing Strategy and Revenue Models) prints that the sensors report a leak within minutes, and Book G8 (Business Insurance and Risk Financing) prints that a cellular gateway that can fail is a hazard; this book poses that the alert path never runs through a platform.

The event itself is small and it is posed by this book. It carries the building, the unit label, the sensor's location, the time and the severity, and no tenant's name. Each event has an identifier, and a repeated delivery never opens a second work order. The events are signed with HMAC-SHA256 over the identifier, the timestamp and the body. The build was a fixed fee of $12,000 paid to the outside integration developer, a provider of the bench of Book I8 (Freelancers, Agencies and Outsourcing), posed by this book, with the acceptance criterion written by Laurence Bergeron; the first platform's partner program asks an annual fee of $3,000, also posed, and no share of the subscriptions, which the company keeps invoicing. The pilot went live on the largest customer's fourteen buildings on day 52, the security questionnaire was submitted on day 58, and the public interface was described on day 60.

Figure 7.1 draws the two paths of one alert in the case: the direct alert path and the signed event that opens one work order.

Figure 7.1 — One alert, two paths. The alert goes directly by text message and email; a signed event opens one work order, retried when it fails and never duplicated: 1,240 events, 0 duplicates on day 365 (posed).

Every figure of day 365 is the case's own and is posed by this book: nothing is measured, and nothing is credited to the integration. The community specification read in section 7.5 is the text that the design resembles, and this chapter makes no claim that the case follows it.

DO THE MATH The alert events of day 365, line by line

Illustrative figures; the case is fictional. Step 1 — 1,231 alert events were relayed on the first attempt, posed by this book. Step 2 — 9 alert events were relayed after retries, posed by this book. Step 3 — 1,231 plus 9 is 1,240 alert events relayed. Step 4 — 0 duplicate work orders were opened, since the identifier of each event makes a repeated delivery harmless. Step 5 — the first platform was down for more than six hours on 2 occasions and no alert was late, because the alert path does not run through it. The counts are posed by this book, they are the case's and not a norm, nothing is measured, nothing is credited to the integration, and the sum is exact and no ratio is computed.

CASE IN POINT Hydrosentinelle inc. sends one signed event for each alert and keeps the alert path outside every platform

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. Laurence Bergeron designs the alert event and its work order, the outside integration developer builds the first integration under a fixed fee of $12,000, posed by this book, and the operations manager of the largest customer receives the work orders. Each event carries an identifier and a signature, a repeated delivery never opens a second work order, and the alert goes directly by text message and by email. On day 365, 1,240 events were relayed with 0 duplicate work orders, and the first platform was down for more than six hours on 2 occasions without a late alert. All of it is posed by this book, illustrative and not a forecast, and no result of the business is credited to the integration or to the interface.

Chapter 8 puts the watch of terms and fees, the monthly reading of integration health and the quarterly review with a platform's partner manager on the calendar, and it is the chapter that keeps an integration in order after the design is done.

Costly Mistakes

• Assuming that the data are yours because your servers hold them. Who owns a set of data, who may use it and who may keep a copy are settled by the contract and by the law, and not by the place where the data happen to sit.
• Adding a field because it is available. A field added to an event because it is there is how personal information starts to travel on a path that nobody designed for it, and the receiver's job is the test of what the event needs.
• Treating a retried delivery as a new event. A receiver that acts twice on the same message opens a second work order for the same leak, and the identifier is what makes a repeated delivery harmless.
• Sharing one key between two integrators. A shared key gives the same rights to everyone who holds it and gives no way to remove one holder without disturbing the others.
• Believing that single sign-on removes a leaver's access everywhere. Sign-in and provisioning are two functions, and a person who leaves the customer's organization keeps an account until the account is removed.
• Keeping a copy after the contract ends because no date was written. An export kept by habit is a copy that no one has decided to keep, and the exit layer is where the date of deletion belongs.
• Reading a feature on a plans page as a fact. A plans page can list interface access or single sign-on while the application copy read has no screen for either, and a buyer checks the screen before relying on it.

Key Takeaways

• Three kinds of data cross an integration — the company's own, the customer's and personal information about people — and who owns each, who may use it and who may keep a copy are settled by the contract and by the law, not by where the data sit.
• Delegated access lets an application act for a person or on its own behalf with limited rights and without that person's password; the framework of 2012 establishes that shape, the best current practice of 2025 updates it, and the practice is a practice and never a rule of law.
• Sign-in and provisioning are two functions: a customer's staff may sign in through their own organization while every account is still created by hand, and the removal of a leaver's access is the moment that costs the most when it is forgotten.
• A dependable delivery carries an identifier, a timestamp and a signature, is retried when it fails, and never opens a second record when it arrives twice; the community specification that describes the shape gives no tolerance value for the timestamp and imposes no requirement of law.
• The contract between two systems is a description and a version: a change that adds an optional field leaves a consumer working, a change that removes or renames a field breaks one, and a new version runs beside the old one for a notice period the terms of use state.
• The right to leave is planned while the relationship is good, with an export in a structured format, a list of what is kept and for how long, and a date after which the copies are deleted; the case's alert path runs through no platform, and every figure of the case is posed by this book.

Your Action Plan

1. List the data that cross each integration, field by field. Write, for every integration the business runs or plans, the fields that cross in each direction, which of them are personal information, and which party decides that the flow is on. Deliverable: a one-page data map for each integration. Verification: every field has a reason in the receiver's job, and no field is there because it was available.
2. Answer the four ownership questions in writing. For each integration, write what crosses, who decides that it crosses, who may keep a copy and for how long, and what happens to the copies when the integration ends. Deliverable: four written answers per integration, kept with the contract. Verification: a lawyer or the person who holds the contract has read the answers, and no answer is left to memory.
3. Give each integrator its own credentials and the narrowest access its job needs. Replace any shared key with credentials issued to one party, write down what each credential may do, and keep a written way to rotate a key and to remove an integrator. Deliverable: a list of credentials, their rights and their removal procedure. Verification: one key has been rotated and one removal has been rehearsed, and the list names the person who performs each act.
4. Specify the event, its identifier and its retry rule. Write the fields of each event, the identifier that is unchanged across retries, the timestamp and the signature, and what the receiver does when it sees a repeated identifier. Deliverable: a written event specification with its version number. Verification: a test delivery has been sent twice with the same identifier and the receiver opened one record.
5. Write the log, the limit and the exit before the first customer data cross. Decide which columns the delivery log keeps, what limit each integrator has and what the answer says when the limit is reached, and write the export, the list of what is kept and the date of deletion. Deliverable: a log specification, a limit and a written exit. Verification: a customer's question about whether an event arrived can be answered from the log alone, and the exit names a date.

In La Machine

In the application copy read on October 15, 2026, the pages that touch this chapter are Control center → n8n (/n8n), Control center → Hermes (/hermes), Control center → Audit log (/journal), Support → Plans & Pricing (plans) and Account → Profile → Privacy (account/privacy) (La Machine, 2026). The engine and the gateway are the publisher's own and sign or run its own calls, the audit log traces what happened to a record and not an integration, the plans page lists interface access and single sign-on among the features of some plans although neither has a screen in the copy read, and the account page exports the account's own data as a file and deletes the account after a typed confirmation phrase, an example of leaving a platform with one's data on the user's side.

What a business needs elsewhere is the rest of the layer this chapter describes. La Machine offers no documented public interface, no interface description, no developer portal and no sandbox; no page where a user creates, rotates or revokes an interface key; no webhook that a user can configure and sign for a customer; no single sign-on and no provisioning of users between systems; and no rate limiter. A layer that signs, retries and logs deliveries, a way to issue and revoke interface keys, single sign-on and provisioning are chosen by function, and Chapter 10 holds the tool tables that describe those functions. La Machine is one worked example of a business platform, described and never sold, and the case does not use it; a reader should check it in an installation.

Self-Check

1. What are the three kinds of data that cross an integration, and what settles who owns each?
2. What does delegated access let an application do, and what does the best current practice of 2025 require of a public client?
3. Why are sign-in and provisioning two different functions, and which moment of an account's life matters most?
4. What three properties make a webhook dependable, and what does the identifier do when a delivery repeats?
5. What does the right to leave with your data contain, and what does section 27 of the Québec private-sector Act cover, given that the structured format reaches only computerized information collected from the person and not information created or inferred?

Answers. 1. The three kinds are the company's own data, such as its sensor readings and alerts; the customer's data, such as its buildings, units, work orders and staff accounts; and personal information about tenants, occupants, staff and contractors; who owns each, who may use it and who may keep a copy are settled by the contract and by the law, and not by where the data sit, and the contracts are Book H1's (Contracts and Commercial Agreements) and a lawyer's. 2. Delegated access lets an application act for a person or on its own behalf with limited rights and without that person's password (Hardt, 2012); the best current practice of 2025 establishes that public clients must use proof key for code exchange and that access tokens should be restricted to the minimum privileges and to a specific resource server (Lodderstedt et al., 2025). 3. Sign-in answers who a person is, and provisioning answers which accounts exist and what each may do, so a business can accept a customer's sign-in and still create every account by hand; the removal of a leaver's access is the moment that matters most, because a forgotten account is invisible while a missing account is reported by the person who needs it. 4. A signature that proves who sent the delivery, a retry that covers a failed delivery and an identifier that makes a repeated delivery harmless; the identifier is unchanged across retries and serves as an idempotency key, so a receiver that sees the same identifier again treats the delivery as already handled and opens no second record (Standard Webhooks, n.d.). 5. The right to leave contains an export in a structured format, a list of what is kept and for how long, and a date after which the copies are deleted; section 27 of the Act respecting the protection of personal information in the private sector, up to date to August 12, 2026, covers only computerized information collected from the person and not information created or inferred, and the provision is called to Book H2 (Privacy and Personal Information).

Chapter References

Act respecting the protection of personal information in the private sector, CQLR c P-39.1, ss. 3.3, 17, 18.3 and 27 (Québec). LégisQuébec, up to date to August 12, 2026 — read October 15, 2026. https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1

Fielding, R., Nottingham, M., & Reschke, J. (Eds.). (2022, June). HTTP semantics (RFC 9110; STD 97). RFC Editor. https://doi.org/10.17487/RFC9110

Hardt, D. (Ed.). (2012, October). The OAuth 2.0 authorization framework (RFC 6749). RFC Editor. https://doi.org/10.17487/RFC6749

Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., & Mortimore, C. (2015, September). System for Cross-domain Identity Management: Protocol (RFC 7644). RFC Editor. https://doi.org/10.17487/RFC7644

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /n8n, /hermes, /journal, plans and account/privacy.

Lodderstedt, T., Bradley, J., Labunets, A., & Fett, D. (2025, January). Best current practice for OAuth 2.0 security (RFC 9700; BCP 240). RFC Editor. https://doi.org/10.17487/RFC9700

Nottingham, M., & Fielding, R. (2012, April). Additional HTTP status codes (RFC 6585). RFC Editor. https://doi.org/10.17487/RFC6585

OpenAPI Initiative. (2026, September 10). OpenAPI Specification v3.2.1. The Linux Foundation. https://spec.openapis.org/oas/v3.2.1.html

Sakimura, N., Bradley, J., & Agarwal, N. (2015, September). Proof Key for Code Exchange by OAuth public clients (RFC 7636; N. Sakimura, Ed.). RFC Editor. https://doi.org/10.17487/RFC7636

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., & Mortimore, C. (2023, December 15). OpenID Connect Core 1.0 incorporating errata set 2. OpenID Foundation. https://openid.net/specs/openid-connect-core-1_0.html

Standard Webhooks. (n.d.). Standard Webhooks specification (Version 1.0.0). Retrieved October 15, 2026, from https://github.com/standard-webhooks/standard-webhooks/blob/main/spec/standard-webhooks.md

Chapter 8 — Typical Tasks, Cadence and Workflows

Platform work is a routine of short reviews and not a rescue, so this chapter puts the decisions of the earlier chapters on the calendar — a weekly watch of terms, fees and policies, a monthly integration health reading, a quarterly review with each platform partner and a quarterly review of the public interface and its integrators, a yearly reset of the integration roadmap and the upkeep of the first integration — sets each task in the format of the application's task table in two tables of six columns at most, shows the routine in three sizes of business, reads what to automate and what to leave to a person, names what breaks a platform routine, and applies all of it to the routine of Hydrosentinelle inc., 106 hours a year plus the annual fee, posed by this book.

What You'll Be Able to Do

• Describe the four rhythms of a platform routine — each week, each month, each quarter and once a year — plus the upkeep of an integration, and say what each one keeps alive.
• Write each task of the routine in the ten-question task format of Book N2 (Piloting Tasks, Executions and Projects, section 2.1), with a person, a trigger, an input, an output and an observable end.
• Hold a weekly watch of the pages where each platform publishes its terms, its fees and its policies, and write each change with its date and an owner.
• Read a monthly integration health reading made of counts and dates, and end it with an owner and a day for each reading that calls for action.
• Run a quarterly review with a platform's partner manager on the company's own agenda, and a quarterly review of the company's own interface and its integrators.
• Decide what can be automated — the collection of the pages and the counts — and what stays with a person, and name the ways a platform routine breaks.

Why It Matters

On this book's own reasoning, platform work fails quietly, by being postponed. The pages where a platform publishes its terms are read on the day the business joins and then not again; a fee page is opened when an invoice looks different; a delivery log is looked at when a customer says an alert never arrived; the roadmap is rewritten when somebody asks why the company built the integration it built. Every one of those decisions is reasonable on the day it is taken, and together they produce a business that reacts to its platforms instead of watching them. A rescue is a recall of attention because a platform changed a term, a fee moved, an integration stopped delivering or a store rejected an update. A routine is the opposite arrangement, and it is smaller than it sounds.

The reason a routine matters more than a method is that a method without a day has no owner. The earlier chapters of this book decided which platforms sit around the customers, how a platform's incentives are read before joining, how deep an integration should go, what a partner program asks and gives, when to open one's own interface, how dependence builds and how it is measured, and who owns the data that crosses an integration. None of those decisions survives on its own. What converts a decision into a habit is a small number of short reviews with fixed days, and the reviews are unglamorous: half an hour a week with the pages, an hour a month with the counts, two hours a quarter with the people who hold the relationship on the platform's side, and three hours a year with the roadmap.

The cost of the routine is worth stating plainly. The routine this chapter adds to Hydrosentinelle inc., a fictional business created for this encyclopedia, takes 106 hours a year — Karim Haddad 37 and Laurence Bergeron 69 — which is $6,360 at Book F9's illustrative rate of $60 an hour for each founder, plus the annual fee of $3,000 that the first platform's partner program asks, and every one of those figures is posed by this book and illustrative. It sits beside work that other books already own and that this chapter never recounts: the routine of a partner program seen from the vendor who runs it, which is Book F9's (Building and Running a Partner Program), and the routine of listings on a marketplace, which is Book F5's (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces).

In This Chapter

Section 8.1 explains why platform work is a routine of short reviews rather than a rescue, sets out the four rhythms and the upkeep with the seven lines of the routine and their hours, and gives the working words this chapter uses. Section 8.2 covers the weekly watch of terms, fees and policies. Section 8.3 covers the monthly integration health reading. Section 8.4 covers the quarterly review with each platform partner and the quarterly review of the public interface and its integrators. Section 8.5 covers the integration roadmap and its yearly reset. Section 8.6 sets the routine in the ten-question task format of Book N2 (Piloting Tasks, Executions and Projects, section 2.1), in two tables of six columns at most. Section 8.7 distributes the same tasks across three sizes of business. Section 8.8 separates what can be automated from what stays with a person. Section 8.9 names what breaks a platform routine and what to do when a task is missed.

8.1 Platform Work as a Routine

A rescue is a recall of attention because a platform changed a term, a fee moved, an integration stopped delivering or a store rejected an update; a routine is the small set of reviews that runs all year whether or not anything has gone wrong, so that fewer changes are read late. The difference between the two is not effort but arrangement. A rescue spends attention after the fact, when the change has already reached an invoice, a customer or a review queue, and it spends it in a hurry. A routine spends a little attention in advance, on a day that is already set, and it spends it on a page that has not changed yet.

The routine of this chapter has four rhythms and one upkeep. Each week, one person reads the pages where each platform publishes its terms, its fees and its policies, and writes what changed with its date. Each month, one person reads a few counts and dates of each integration and of the company's own interface, and decides what calls for action. Each quarter, the company sits down with the people who hold the relationship on the platform's side, and separately reviews its own interface and the integrators approved on it. Once a year, the company rereads the map of the platforms around its customers, rescores its candidate integrations and rewrites its roadmap. And the upkeep of the integration already built — its versions and the renewal of its security review — runs on a clock that belongs to the platform rather than to the company, which is exactly why it needs a line of its own.

What each rhythm keeps is different, and that is why the routine is not one meeting held four times. The weekly watch keeps the terms and the fees visible, so that a change is read the week it arrives rather than the quarter it is invoiced. The monthly reading keeps the integrations read, so that a delivery that has started to retry is seen before a customer notices. The quarterly review keeps the relationships in view, so that the company's own agenda is written before the meeting rather than after it. The yearly reset keeps the roadmap renewed, so that a candidate that scored below the line last year is scored again on this year's numbers. The upkeep keeps the built integration current, so that a version notice does not become an outage.

Two neighboring routines are cited here and counted nowhere in this chapter. The routine of a partner program seen from the vendor who runs it is Book F9's (Building and Running a Partner Program), and the routine of listings on a marketplace is Book F5's (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces). Neither is recounted here, and no hour of either is added to the hours below.

The cadences below are this book's own method, and no source read measures how often a platform changes its terms, how long a watch takes, what a review returns or how many reviews a small firm should hold. The hours of the case are posed by this book, illustrative, and never a norm, a benchmark or a target for any reader. This chapter decides nothing that the earlier chapters decided. Chapter 4 owns the partner agreement and the signals of a listing, Chapter 5 the interface of the company and its ecosystem, Chapter 6 the notice a business gets, the measure of exposure and the register of dependence with its ceiling, and Chapter 7 the data, the identity and the events. Chapter 9 owns the help, Chapter 10 the tools and Chapter 11 the plan. This chapter answers one question: what does a small firm do each week, each month, each quarter and each year to keep its integrations and its platform relationships in order, who does it, how long does it take, and what can be automated without the decision being automated?

Figure 8.1 lays out the case's platform routine by rhythm, with its hours a year.

Figure 8.1 — The routine by rhythm. A weekly watch, a monthly health reading, two quarterly reviews, a yearly reset and the upkeep of the integration, 106 hours a year (posed).

The table below sets seven lines of the routine beside who does each, the hours each time, the times a year and the hours a year. It is posed by this book, it is never a norm, and it does not count the routines of Books F9 and F5 again. Read it as the skeleton of a cadence rather than as a description of any real business: the columns are the same for a solo owner and for a business of forty people, and what changes with size is who fills each cell, which is the subject of section 8.7.

Table 8.1 — The routine of the case, with its hours (posed)

The seven lines add up to 106 hours a year, Karim Haddad 37 and Laurence Bergeron 69, plus the annual fee of $3,000 that the first platform's partner program asks, posed by this book; the hours are valued at Book F9's illustrative rate of $60 an hour for each founder, which is $6,360, and never a pay. The routine starts when the day-90 gate of the plan of Chapter 11 has set the routine as plan tasks with a verification criterion, and the plan itself is Chapter 11's.

DEFINITION Watch, health reading, review and reset, as this book uses the words

These are this book's working words, and no source read defines them in this sense. A watch is the weekly look at the pages where a platform publishes its terms, its fees and its policies, written with its date. A health reading is the monthly look at the counts and dates of an integration's deliveries, retries, duplicates and keys. A review is a meeting set in advance with a platform's partner manager or with the integrators of the company's own interface, ended by an owner and a day for each decision. A reset is the yearly rescoring of the integration roadmap. A watch is not a protection against a change of terms, a health reading is not a score, a review is not a negotiation of the written terms, and a reset is not a promise to a platform or to a customer. The words are this book's own, and the hours of the case are posed by this book.

DO THE MATH The 106 hours a year of the routine, line by line

Illustrative figures; the case is fictional. Step 1 — The weekly watch takes 0.5 hour and is held 52 times, so 0.5 multiplied by 52 gives 26 hours a year. Step 2 — The monthly health reading takes 1 hour and is held 12 times, so 1 multiplied by 12 gives 12 hours a year. Step 3 — The quarterly review with the first platform's partner manager takes 2 hours and is held 4 times, which gives 8 hours a year, and the quarterly review of the public interface and its integrators takes 1.5 hours and is held 4 times, which gives 6 hours a year. Step 4 — The yearly reset takes 3 hours for Karim Haddad and 3 hours for Laurence Bergeron, and the upkeep of the first integration takes 48 hours. Step 5 — The lines add 26, 12, 8, 6, 3, 3 and 48, which gives 106 hours a year, Karim Haddad 37 and Laurence Bergeron 69, which is $6,360 at Book F9's rate of $60 an hour, plus the annual fee of $3,000. The hours are posed by this book, are the case's and not a norm, and are valued at Book F9's illustrative rate and not at a pay.

8.2 The Weekly Watch of Terms, Fees and Policies

Once a week one person reads the pages where each platform publishes its terms, its fees and its policies, and writes what changed with its date. The watch is the shortest line of the routine and the one that keeps every other line honest, because a change read the week it arrives is a change the company can still decide about.

What is watched is a short and fixed list for each platform. It is the agreement of the program the company has joined, the page that publishes the fees, the guidelines of the store that lists the mobile application, any notice of change the platform posts, and the version notices of the interface the company uses. The list is written down once, in the register, and it is read in the same order every week. A page that is not on the list is not watched, and a page that never changes the company's choices is dropped at the quarterly reading of the register.

What the watch writes is a dated line in the register for each change, or the words "no change". The line carries the page, the date it was read, what changed and, where a notice period is stated, the period the platform's own terms give. The words "no change" are not a formality: a register that shows a line for every week is a register that can be read later to see when a change first appeared, and a register with gaps cannot. A platform's term is that platform's term on the day it was read, and it is never a market rate and never stable; the pages themselves are read in Chapters 4 and 6, and this chapter only schedules their reading.

What happens when something changes is the part that turns a watch into work. Each change leaves the watch with an owner and a day. Where the change touches a notice period, the period is read against the terms read in Chapter 6, so that the company knows how long it has. Where the change touches a contract the company has signed, the question goes to a lawyer, because what a change in a platform's written terms means for a business that joined under them is a question for Book H1 (Contracts and Commercial Agreements) and a lawyer, and this book decides nothing about it. Where the change touches a fee, the register records the new figure as the platform's own term on the day read, and the company decides what to do with it in the quarterly review of section 8.4.

In the case, Karim Haddad, the head of sales and operations, holds the watch. It takes 0.5 hour each time, is held 52 times a year, and is 26 hours a year, all posed by this book. On day 365 the first platform announced that its annual fee would rise from $3,000 to $3,600 with 60 days' notice, and the watch read it the week it arrived, posed by this book; nothing is credited to the watch, and the rise is the case's own posed figure and never a real platform's term. The watch prevents nothing: it lets the company read a change the week it arrives, and a change that arrives between two weeks is read on the next one.

THE RULE A change in a platform's terms is read the week it arrives, written with its date and given an owner

The rule is this book's own for the case, drawn from its reasoning and not from a source: the weekly watch reads the pages of each platform, writes each change with its date in the register and gives it an owner and a day. A platform's term is that platform's term on the day it was read, never a market rate and never stable. What a change means for a contract the company has signed is Book H1's (Contracts and Commercial Agreements) and a lawyer's, and whether a term bears on competition is Book H4's (Consumer Protection, Advertising Law, Competition and Language Requirements). The rule is neither a standard nor a legal duty, and it is not advice about any reader's own agreement. The case's weekly watch takes 0.5 hour each time and read the announced rise of the annual fee from $3,000 to $3,600 the week it arrived, posed by this book. No figure beyond the case's is printed here.

METHOD Setting up the weekly watch of one platform in five steps

First, list the pages where the platform publishes its terms, its fees and its policies, and write them in the register. Second, name who reads them, who is the backup and on which day of the week. Third, read each page and write what changed with its date, or write "no change". Fourth, give every change an owner and a day, and read the notice period of the change against the terms read in Chapter 6. Fifth, after a quarter read the register against what was decided and drop a page that never changes the company's choices. This is the book's reasoning and not a tested procedure, and no source read measures how long a watch takes. The case follows these steps with a weekly watch of 0.5 hour, posed by this book, and the register is the same one that carries the dependence ceiling of Chapter 6.

WHAT CHANGED The application copy was read on October 15, 2026, and the weekly watch reads each platform's pages again

The dated reading is this: the application code was read at its copy of September 7, 2026, on October 15, 2026 (La Machine, 2026). In that copy the weekly watch can be written as a recurring plan task with a required "Done when" criterion that the Mark as done button does not verify, and La Machine reads no page of a platform and warns of no change of terms. The terms of each platform are read in Chapters 4 and 6 as that platform's terms on the day read, October 15, 2026, and this chapter only schedules their reading. None of these dates is a date of the case, which is counted in days, and the fee rise that the watch read on day 365 belongs to section 8.2 and never to this box. A reader reads each page again on the reader's own date, and nothing is credited to the watch.

8.3 The Monthly Integration Health Reading

Once a month one person reads a few counts and dates of each integration and of the company's own interface, and decides what calls for action. The reading is the instrument that turns a month of deliveries into a decision, and it is made of counts and dates and never of a score.

What is read is short and fixed. It is the deliveries of the month and the retries among them, because a delivery that needed a second attempt is a delivery that was nearly lost. It is the duplicates, because a repeated delivery that opens a second work order is a defect the company can see in a count. It is the age of each key, because a key that has never been rotated is a key nobody has looked at. It is the list of approved integrators, because an integrator that no longer uses the interface is an access that should be removed. And it is the review status of the mobile application in each store, because a review queue is a date the company cannot control and should watch. The robustness of the connections between tools is Book K8's (No-Code, Low-Code and Integrations), and this chapter cites it rather than restating it.

The reading looks at counts and dates and never at a score. A count of retries is not a grade, and a month with nothing to report is not a guarantee. The difference matters because a score invites the work to bend toward the number, while a count says only that something happened a certain number of times and that somebody should look. Each reading that calls for action leaves the reading with an owner and a day, written down; a reading that calls for nothing leaves with nothing, and the reading can be short.

In the case, Laurence Bergeron, the president, holds the reading. It takes 1 hour each time, is held 12 times a year, and is 12 hours a year, all posed by this book. The readings of day 365 are posed by this book: 1,240 alert events relayed, 1,231 on the first attempt and 9 after retries, with 0 duplicate work orders; 1 key rotated and 0 integrator removed; one update of the mobile application rejected by a store's review and fixed in 3 days; and the first platform down for more than six hours on 2 occasions, without a late alert, because the alert path does not run through it. None of those figures is a target, and none is credited to the reading.

The reading also checks the counts themselves. A count that was not taken for a month is a count with a gap, and the gap is written into the reading rather than smoothed over. A count whose definition changed during the month is read with the change noted, because a count that changes its definition cannot be compared with itself. And a reading that stays past its threshold across several months is a reading the monthly meeting has not resolved, which is a question for the quarterly review of section 8.4.

WATCH OUT Reading a count as a score and skipping a quiet week are two traps

Two traps catch a platform routine, and each has a question that catches it. The first is reading a count as a score: a number of retries becomes a grade, and the work bends toward the number rather than toward the flow. The question is what action does this reading call for, and who owns it. The second is skipping a quiet week of the watch: nothing seemed to change, the register has no line, and a notice is read late. The question is whether the register shows a line for every week, even the words "no change". This book's reasoning is illustrative, and no frequency of either trap in any business is printed, because no source read measures one. In the case, the register shows a line for every week and the health reading is made of counts and dates, posed by this book, and neither is a guarantee that a change will be read on the day it is posted.

8.4 The Quarterly Review With Each Platform Partner

Once a quarter the company sits down with the people who hold the relationship on the platform's side and reads the relationship against its own register. The review is the line of the routine where the company's own agenda matters most, because the person on the other side of the table is a role at the platform and works for the platform.

The company's agenda is written before the meeting, and it is written from the register. It carries the register against its ceiling of 40 percent of the new buildings of any quarter, which is the case's own ceiling and posed by this book. It carries the inquiries that came from the listing, read as inquiries and never as sales. It carries the notices of change read in the weekly watch, with their dates and their notice periods. It carries the open questions the company has, and the date of the next renewal. A review that opens with the platform's own slide deck is a review that has given away its agenda, and the remedy is a written agenda sent before the meeting.

What the review ends with is an owner and a day for each decision. A decision that lives in the memory of the people who attended will be taken again next quarter on the same item. The format of a meeting is Book I7's (Communication, Meetings and Decision-Making), and this chapter takes from it only the two rules a quarterly review needs: an agenda written in advance, and a written end. Book L4 (Strategic Partnerships, Alliances and Joint Ventures) holds the alliance that two businesses negotiate, and this book keeps adhesion to terms that are not negotiated.

The second quarterly review is the company's own. It reads the public interface and the integrators approved on it, and it decides for each integrator whether to keep, rotate or remove. It reads the list of integrators and keys, their requests against the limit of 120 requests a minute that the interface's first version sets, and their questions. The limit and the version are the case's own and posed by this book. The review ends with an updated list, and each integrator on it carries a date of approval and the age of its key.

In the case, Karim Haddad holds the review with the first platform's partner manager, 2 hours each time, 4 times a year, and 8 hours a year, and Laurence Bergeron holds the quarterly review of the public interface and its integrators, 1.5 hours each time, 4 times a year, and 6 hours a year, all posed by this book. On day 365, the busiest quarter holds 22.0 percent of the new buildings after an inquiry from the listing, against the ceiling of 40 percent, posed by this book, and nothing says that the listing caused those signatures; the accounts came after an inquiry, and an inquiry is not a cause.

QUÉBEC & CANADA NOTE A review with a platform's partner manager is not a new contract, and a record that names a person is a question for Book H2

The Canadian point of this section is the difference between what is said in a review and what is written in the terms. What a platform's partner manager says in a review does not by itself change the written terms the company joined under, and whether a promise made in a review binds the platform is a question for Book H1 (Contracts and Commercial Agreements) and a lawyer, never decided by this book. Whether a term bears on competition is Book H4's (Consumer Protection, Advertising Law, Competition and Language Requirements). The minutes of a review name people, and whether a record that names a person is personal information is Book H2's (Privacy and Personal Information). This book explains published rules and recommends no vendor, and it sends the reader to Book H1, Book H4, Book H2 and an adviser. Nothing here says whether the reader's own agreement, clause or record complies, and no conclusion is drawn about any real platform's terms.

8.5 The Integration Roadmap and Its Yearly Reset

Once a year the company rereads the map of the platforms around its customers, rescores its candidate integrations on the grid it uses, and rewrites its roadmap. The reset is the line of the routine that keeps the company from building the same integration twice or from queueing a candidate forever.

The map is Chapter 2's (section 2.10), and this chapter cites it rather than redrawing it. The grid is Chapter 3's (section 3.8), with its six criteria and their weights, and the rule of the case's grid is that a candidate scoring 70 or more is built now, a candidate from 55 to 70 is queued, and a candidate below 55 is not built now. The case's three candidates scored 77, 68 and 44 at the plan, posed by this book, and the reset scores them again on this year's numbers rather than on last year's. A candidate that rises to 70 or more moves from the queue to the build list, and a candidate that falls below 70 moves back, and neither movement is a verdict on the platform.

What the reset produces is a roadmap with each candidate in one of the three states, and a written reason for each state. The reason matters more than the state, because the reason is what a reader of the roadmap will need a year later. The reset also reads the register of dependence, which is Chapter 6's, and it reads the readings of the year, so that a candidate is scored on what the company has learned rather than on what it hoped. The roadmap is never read as a promise to a platform or to a customer: it is the company's own list, and a platform is never told that a build is coming.

The upkeep of the integration already built is the largest line of the routine, and it is the one that is easiest to forget because it runs on the platform's clock. It covers the versions of the interface the company uses, the tests that have to be rerun when a version moves, and the renewal of the security review that the partner program asks. In the case, Karim Haddad and Laurence Bergeron hold the reset, 3 hours each, once a year, and Laurence Bergeron holds the upkeep, 48 hours once a year, all posed by this book. The upkeep is 48 of the routine's 106 hours, the largest single line, and that line is the case's own and posed by this book.

The reset is also where the company decides whether to leave a platform. Leaving is Chapter 6's subject, and this chapter only schedules the decision: the reset reads the register, the ceiling and the way out of each platform, and it writes one decision for each platform the company depends on. A decision to leave is a decision with a date, and a decision to stay is a decision with a reason.

KEY CONCEPT A routine keeps control only when each line has an owner, a day and a written output

This is the book's reasoning and never a finding. A watch, a reading and a review keep a business in control of its platforms only if each one has a person who holds it, a day on which it is held and an output that can be seen in the register. A reminder only prompts the person who set it, and a task marked done proves nothing until a second person reads the criterion. The routine of the case takes 106 hours a year, posed by this book and never a norm, and nothing is credited to it: no sale, no signature and no growth of the business is attributed to the watch, the reading, the reviews, the reset or the upkeep. No source read measures a cadence of platform work, and the figures of the case are these: 106 hours a year, Karim Haddad 37 and Laurence Bergeron 69, plus the annual fee of $3,000. A routine that rests on the owner's attention fades when the attention moves; a routine that rests on a day and a person does not.

8.6 The Task Table

The routine of this chapter is written in the ten-question format of Book N2 (Piloting Tasks, Executions and Projects, section 2.1), which asks for a task, an objective, a trigger, a frequency, a level of automation, an input, an output, a verification criterion, a role and a tool. The table is split in two, because a table of ten columns does not read aloud, and each of the two opens with the Task column.

The table below sets six tasks beside their objective, their trigger, their frequency, their level of automation and their input. It is the first of two tables, and the second continues the same six tasks in the same order. Read the automation column as a statement about what a tool may carry and never as a statement about what a tool may decide: the highest level any line reaches is a collection of pages or a count drawn from a log, with the reading left to a person.

Table 8.2 — The tasks of the routine: objective, trigger, frequency, automation and input

The table below continues the same six tasks in the same order with their output, their verification criterion, their role and their tools. The verification criteria are observable, and the tools are named by function and never by product; no tool is chosen for the case. Read the criterion column as the part of the row that matters most, because a task whose criterion cannot be checked by a second person is a task that will be marked done without being done.

Table 8.3 — The tasks of the routine: output, verification, role and tools

The ten questions that these criteria rest on are Book N2's (Piloting Tasks, Executions and Projects, section 2.1), and this chapter cites them rather than rewriting them.

8.7 Sharing Platform Work in Three Sizes of Business

The routine does not change with the size of the business, but the number of people who play its roles does. The three sizes below are a way of distributing the same tasks and no claim about how businesses of that size actually work. The first and the third columns are this book's suggestion and are not part of the case.

The table below sets the five lines of the routine beside who does the work in a solo business, in the case's business and in an established business. The case's business is Hydrosentinelle inc., and every cell in that column is posed by this book. Read the table as a distribution of responsibility: the tasks are identical in every row, and what changes is how many people carry them. No hour is promised to a reader.

Table 8.4 — The routine in three sizes of business

Three rules hold in every size, and they are the part of this section worth keeping when the table is forgotten. The first is that whoever holds each line has a named backup, because a line whose holder is away is a line that does not run. The second is that a reading leaves with an owner and a day, because a reading that leaves with nothing will be taken again next month on the same item. The third is that a task marked done is always read by a second person, because the box being ticked and the criterion being met are two different facts.

The solo business is the size at which the routine has no second reader. The practice that saves it is writing the output down and filing it: an owner who keeps twelve monthly readings in one place has a trend, and a trend is a second reader of a kind. On this book's suggestion, the solo owner can replace the quarterly review with a trusted adviser's reading of the register and keeps the weekly watch and the monthly reading, because those are the lines that see a change and a defect first.

In an established business, this book's suggestion is that one person can hold the routine, and the risk to watch is that the routine grows a report for each of its lines. The remedy is to retire a line for each line added and to read the routine itself at the yearly reset. Every line still ends in an observable state, and every line still has a person.

WHO DOES THIS Karim Haddad holds the watch and the platform reviews, and Laurence Bergeron holds the health reading and the interface review

The roles below are the case's, posed by this book. Karim Haddad, the head of sales and operations, holds the weekly watch, the quarterly review with the first platform's partner manager and, with Laurence Bergeron, the yearly reset. Laurence Bergeron, the president, holds the monthly health reading, the quarterly review of the public interface and its integrators and the upkeep of the first integration. The first platform's partner manager is a role at the platform and works for the platform, and the integrators are a group. In general, one person holds each line with a named backup, and that is this book's suggestion and not part of the case. In a solo business the owner holds every line and a trusted adviser reads the register each quarter. In a larger business a partnerships manager holds the platform reviews and a developer holds the health reading. No hour and no amount is promised to a reader.

8.8 Automating the Watch Without Automating the Decision

The routine has parts that a tool can carry and parts that only a person can carry, and the line between them is worth drawing carefully because it is easy to cross by accident.

What can be automated is the collection and the prompting. A reminder can reach the person who set it at a set day or on a recurrence. A recurring task can carry a required observable end, a short procedure and a next due date. A notice can tell a person that a page has changed, without saying what the change means. A first list of the changes found on a set of pages can be drawn together for a person to read. A count of deliveries, retries and duplicates can be drawn from a delivery log rather than counted by hand. An AI assistant may draft a first summary of what changed on a page, and the person who holds the watch corrects and approves it; a reading is never the work of an assistant. The case uses no assistant. None of those is a decision, and each of them saves time that the routine would otherwise spend on gathering.

What stays with a person is everything that decides. Reading the change stays with a person, because a page says what it says and the meaning of the change for this company is a judgment. Choosing what the change means for the company stays with a person, because the same change means different things to two businesses. Deciding to keep, renegotiate or leave a platform stays with a person, because that decision moves customers and revenue. And every decision that moves a customer's promise stays with a person, because a promise is not a count. Automation as a method is Book J7's (Business Process Automation), and workflows with human approval are Book N3's (Workflows, Automation and Human Approval), and this chapter cites each rather than restating it.

The pages of La Machine are worth naming one by one, with their limits, because a business that builds a routine on a page should know what the page does. In the application copy read on October 15, 2026, Control center → Plan tasks (/taches) holds recurring or one-off tasks with a "Done when" criterion that is required when the task is created, and the weekly watch, the monthly reading and the quarterly review can live there as tasks with an observable criterion; the Mark as done button does not check the "Done when" criterion, so a task marked done does not prove that the criterion was met (La Machine, 2026). Control center → Workflows (/registre) shows one line for each workflow or agent route, with its code, type, trigger, entry point and state; only the state can be changed on the screen, and there is no column for an owner, so it can serve as a model for a register of integrations and it is not the reader's register. Control center → Tools (inventory) (/outils) lists tools with a version that is measured, a location and a date, and it measures no exposure, no revenue and no share of customers, so it can serve as a model for an inventory of the dominant offers a business depends on and it is not a register of dependence. Check it in your installation.

TOOLS OF THE TRADE What any watch, reminder and register function must offer, whatever it is called

Nine functions carry a platform routine, and a business should look for them rather than for a product. The first is a reminder that reaches the person who set it, at a set day or on a recurrence. The second is a recurring task with a required observable end, a short procedure and a next due date. The third is a way to record a page read, with its date and what changed. The fourth is a notice when a page changes, without a claim about what the change means. The fifth is a register with a column for the owner, the notice period and the way out of each platform. The sixth is a view of what falls due this week. The seventh is a way to name a backup for each line. The eighth is a way to attach a note to a task, because the reason a line was missed is a fact worth keeping. The ninth is an export in a form another tool can read. No brand name belongs on this list and no price; the requirement is the function.

IN LA MACHINE A recurring review can be a plan task, a register of workflows can model a register of integrations, and nothing watches a platform

In the application copy read on October 15, 2026, Control center → Plan tasks (/taches) holds a recurring review as a task with a required "Done when" criterion, and the Mark as done button does not verify that criterion (La Machine, 2026). Control center → Workflows (/registre) shows one line for each workflow or agent route with its state and no column for an owner, a model for a register of integrations and not the reader's register. Control center → Tools (inventory) (/outils) lists tools with a measured version and measures no exposure, no revenue and no share of customers. La Machine does not read a platform's page, does not warn of a change in a platform's terms and keeps no register of dependence or exposure, so the reading stays with a person. Check it in your installation. La Machine is described and never sold, and the case does not use it.

8.9 What Breaks a Platform Routine

A platform routine breaks in several ways, and none of them is dramatic. The first is that the person who holds the weekly watch goes away and no backup is named. The pages are not read, the register shows no line, and a change is read a quarter late. The remedy is a named backup and a written procedure for the watch, which is the same remedy any process whose holder might be away receives.

The second break is a week skipped with nothing written. A quiet week feels like a week that can be skipped, and a register with a gap cannot be read later to see when a change first appeared. The remedy is the words "no change", written on the day, because a line that says nothing changed is a line. The third break is a notice read late, after its period has run. The remedy is the owner and the day that every change leaves the watch with, and the reading of the notice period against the terms read in Chapter 6.

The fourth break is a register with no owner for a platform. A platform that nobody holds is a platform whose pages are read by whoever remembers, and the remedy is one name and one backup for each platform in the register. The fifth break is a reading past its ceiling that is not written. The ceiling of 40 percent of the new buildings of any quarter is the case's own and posed by this book, and a quarter that passes it without a written line is a quarter the company cannot act on. The remedy is the written line, with an owner and a day.

The sixth break is the annual upkeep forgotten until the security review lapses. The upkeep runs on the platform's clock rather than the company's, and a renewal date that lives only in a memory is a renewal date that will be missed. The remedy is a dated entry in the same register, read at the quarterly review. The seventh break is a review held and its decisions not written. A decision that lives in the memory of the people who attended will be taken again next quarter on the same item, and the remedy is one decision per open item, with a person and a date.

The eighth break is a task marked done with nobody checking the criterion. The box is ticked, the register has no line, and the routine appears to run while nothing happens. The remedy is the second reader: a task marked done is read by a person other than the one who marked it, and the criterion is checked against the output rather than against the intention. The ninth break is the partner manager's agenda replacing the company's. The partner manager is a role at the platform and works for the platform, so a review that opens with the platform's own list is a review the company has handed over. The remedy is the written agenda of section 8.4.

No study read measures what breaks a routine, and none is cited for one; the causes above are this book's reasoning and illustrative, with no frequency of any cause in any business. When a task is missed, the remedy is small and it is written down. The task is done on the next working day rather than folded into the next cycle. The miss is written down with its reason, because a miss that is not recorded is a miss that will be repeated. The cause is found and read as a fact about the system rather than a person's fault. And where the miss belongs to the plan of Chapter 11, the gate is read again 7 days later, and nothing new starts until it passes.

In the case, on day 365 the weekly watch read the announced rise of the annual fee the week it arrived, one update of the mobile application was rejected by a store's review and fixed in 3 days, and the first platform was down for more than six hours on 2 occasions without a late alert, all posed by this book. Nothing is measured and no result is credited to the routine. Chapter 9 reads who helps with this work and when to get help.

CASE IN POINT Hydrosentinelle inc. runs six lines of routine and reads a rise of a fee the week it arrives

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. The weekly watch, the monthly health reading, the two quarterly reviews, the yearly reset and the upkeep of the first integration take 106 hours a year, Karim Haddad 37 and Laurence Bergeron 69, plus the annual fee of $3,000, all posed by this book. On day 365 the weekly watch read the announced rise of the annual fee the week it arrived, one update of the mobile application was rejected by a store's review and fixed in 3 days, and the first platform was down for more than six hours on 2 occasions without a late alert, all posed by this book. The routine is illustrative and not a forecast, and nothing is credited to it.

Costly Mistakes

• Treating platform work as a rescue rather than a routine. A term read when an invoice looks different is a term read after the decision it required has already been made by default.
• Skipping a quiet week of the watch. A register with a gap cannot be read later to see when a change first appeared, and the words "no change" are the line that keeps the register whole.
• Reading a count as a score. A number of retries is not a grade, and a reading that becomes a target invites the work to bend toward the number instead of toward the flow.
• Letting the partner manager's agenda replace the company's. The partner manager is a role at the platform and works for the platform, so a review without a written agenda is a review given away.
• Leaving a platform with no owner in the register. A platform nobody holds is a platform whose pages are read by whoever remembers, and its notice period is discovered after it has run.
• Forgetting the annual upkeep until the security review lapses. The upkeep runs on the platform's clock rather than the company's, and a renewal date kept only in a memory will be missed.
• Marking a task done without a second reader. The box being ticked and the criterion being met are two different facts, and a routine that confuses them appears to run while nothing happens.

Key Takeaways

• Platform work is a routine of short reviews and a rescue is a break in the work: the routine is the small set of reviews that runs all year whether or not anything has gone wrong, so that fewer changes are read late.
• The routine has four rhythms and one upkeep — a weekly watch of terms, fees and policies, a monthly integration health reading, a quarterly review with each platform partner and a quarterly review of the company's own interface and its integrators, a yearly reset of the roadmap, and the upkeep of the integration already built.
• The seven lines take 106 hours a year, Karim Haddad 37 and Laurence Bergeron 69, which is $6,360 at Book F9's illustrative rate of $60 an hour, plus the annual fee of $3,000, and every one of those figures is posed by this book and illustrative; the routines of Book F9 (Building and Running a Partner Program) and Book F5 (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces) keep their own cadence and are not counted again.
• Each task is written in the ten-question format of Book N2 (Piloting Tasks, Executions and Projects, section 2.1), with a person, a trigger, an input, an output and an observable end, and the criterion is the part of the row that matters most.
• A tool can collect the pages and draw the counts, and a person decides: reading the change, choosing what it means for the company, deciding to keep, renegotiate or leave a platform, and every decision that moves a customer's promise stay with a person, and a task marked done proves that a box was ticked and nothing more.
• A routine breaks in several ways — no backup for the watch, a week skipped with nothing written, a notice read late, a platform with no owner, a reading past its ceiling not written, the upkeep forgotten, a review whose decisions are not written, a task marked done unchecked, and the partner manager's agenda replacing the company's — and every remedy is a decision taken before the break.

Your Action Plan

1. List the recurring platform tasks and give each one a rhythm. Write the seven lines of the routine in the ten-question format of Book N2 (Piloting Tasks, Executions and Projects, section 2.1), with a person, a trigger, an input, an output and an observable end for each. Deliverable: a written routine of five to seven lines. Verification: every line names a person, a trigger and a criterion a second person could check.
2. Cost the routine in hours a year and read it against the hours of the same people. Multiply the hours each time by the times a year for each line, add the lines, and write the total beside the hours the same people have for the work. Deliverable: a table of hours a year by line and by person. Verification: no person's year asks more than the hours the business has agreed for that role.
3. Set up the weekly watch with its pages, its day and its backup. List the pages where each platform publishes its terms, its fees and its policies, name who reads them and on which day, and write the first dated line in the register, even if it says "no change". Deliverable: a register with a page list, a day, a name and a backup. Verification: the register shows a line for every week of the first quarter.
4. Hold the first monthly reading and the first quarterly review, and write the owners and days down. Read the counts and dates of each integration and of the company's own interface, write the company's agenda before the review with the platform's partner manager, and end both with an owner and a day for each decision. Deliverable: a written page of counts and dates, and written minutes with an owner and a day for each decision. Verification: every open item carries an owner and a day, and the minutes are filed with the register.
5. Decide what happens when a line is missed. Write the rule for a missed line — done on the next working day, written down with its reason, the cause found, and the gate read again 7 days later where the miss belongs to the plan of Chapter 11. Deliverable: a written rule for a missed line. Verification: at least one miss has been recorded and read under the rule within the first quarter of the routine.

In La Machine

In the application copy read on October 15, 2026, a recurring review can live in Control center → Plan tasks (/taches) as a task with a required "Done when" criterion, and the Mark as done button does not verify that criterion, so a second person reads a task marked done (La Machine, 2026). Control center → Workflows (/registre) shows one line for each workflow or agent route with its state and no column for an owner, and it can serve as a model for a register of integrations, though it is not the reader's register. Control center → Tools (inventory) (/outils) lists tools with a version that is measured, a location and a date, and it measures no exposure, no revenue and no share of customers. Check it in your installation.

What a business needs elsewhere is the rest of the routine. La Machine does not read a platform's page, does not warn of a change in a platform's terms and keeps no register of dependence or exposure, so the reading stays with a person. A business also needs a place for the register of dependence with an owner for each platform, a way to be told when a page changes, and a place for the minutes of a review, each chosen by function among the tools of Chapter 10. La Machine is one worked example of a business platform, described and never sold, and the case does not use it.

Self-Check

1. What is the difference between a rescue and a routine in platform work, and what are the four rhythms and the upkeep of the routine?
2. What does the weekly watch read, what does it write, and what happens when something changes?
3. What does the monthly integration health reading look at, and why is a count not a score?
4. What does the quarterly review with a platform's partner manager read, and why is the company's agenda written before the meeting?
5. What are the ways a platform routine breaks, and what is the remedy for each?

Answers. 1. A rescue is a recall of attention because a platform changed a term, a fee moved, an integration stopped delivering or a store rejected an update, and a routine is the small set of reviews that runs all year whether or not anything has gone wrong; the four rhythms are each week, each month, each quarter and once a year, and the upkeep of the integration already built runs on the platform's clock rather than the company's. 2. The weekly watch reads the agreement of the program, the page that publishes the fees, the guidelines of the store that lists the mobile application, any notice of change and the version notices of the interface the company uses, and it writes a dated line in the register for each change or the words "no change"; when something changes, the change leaves the watch with an owner and a day, its notice period is read against the terms read in Chapter 6, and a question that touches a contract goes to a lawyer, because what a change means for a contract is Book H1's (Contracts and Commercial Agreements) and a lawyer's. 3. The monthly reading looks at the deliveries of the month and the retries among them, the duplicates, the age of each key, the list of approved integrators and the review status of the mobile application in each store; a count is not a score because a count says only that something happened a certain number of times and that somebody should look, while a score invites the work to bend toward the number. 4. The quarterly review reads the register against its ceiling of 40 percent of the new buildings of any quarter, the inquiries that came from the listing, the notices of change read in the weekly watch, the open questions and the next renewal, and it ends with an owner and a day for each decision; the company's agenda is written before the meeting because the partner manager is a role at the platform and works for the platform. 5. The breaks are a watch without a backup, a week skipped with nothing written, a notice read late, a platform with no owner in the register, a reading past its ceiling not written, the annual upkeep forgotten until the security review lapses, a review whose decisions are not written, a task marked done with nobody checking the criterion, and the partner manager's agenda replacing the company's; the remedies are a named backup, the words "no change" written on the day, an owner and a day for every change, one name and one backup for each platform, the written line with an owner and a day, a dated entry for the renewal read at the quarterly review, one decision per open item written down, a second reader for every task marked done, and a written agenda sent before the meeting.

Chapter References

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /taches, /registre and /outils.

Chapter 9 — Expertise, Roles and When to Get Help

Platform work needs a few roles done well and a few kinds of outside help engaged at the right moment, so this chapter says which roles stand behind platform work, who holds each one in a small firm, when a firm asks for help from outside, in what form, and how it reads the proposal it receives.

What You'll Be Able to Do

• Name the seven roles behind a small firm's platform work and the eighth role that sits outside the firm, the platform's partner manager, who works for the platform.
• Decide which decisions stay with the owner as the first platform strategist and which may be handed to a helper for a named job.
• Assign one named person, with a backup, to each platform relationship, and write the company's own agenda before each review.
• Choose the form of an outside engagement — a fixed fee for a scope, a day rate, an hourly rate or a mandate priced by scope — and write the acceptance criterion before the work starts.
• Read an integration agency's proposal against the company's own written need, and tell an outcome claim from a deliverable.
• Know when to ask a lawyer, a security and privacy adviser or a publicly funded advisory program for help, and what each of them does and does not decide.

Why It Matters

Platform work looks like a technical job and is in fact a set of roles. Somebody has to read the terms of each platform, somebody has to hold the relationship with each platform, somebody has to build and keep the connection, somebody has to answer a security questionnaire, somebody has to read a partner agreement before it is accepted, and somebody has to decide where the company plugs in at all. In a small firm those roles may fall on the same two people, and the failure to guard against is not that a role is done badly but that a role is never named. A platform relationship with no holder is a relationship that is read when something goes wrong, and a security questionnaire with no owner is a questionnaire that is answered late.

Outside help buys a skill or a reading, and it never buys a decision. A developer builds, a lawyer reads, an adviser examines and an agency prepares, and none of them decides where the company plugs in, how far it opens its own interface or what ceiling of dependence it holds. That division is the whole of this chapter. No source read measures what outside help returns, what it costs, how many small firms engage a developer, a lawyer or an agency, or how long an engagement lasts, and none is cited for one. Pay is described here by its form — a fixed fee for a scope, a day rate, an hourly rate, a mandate priced by scope — and never by an amount, except the case's posed fixed fee and the outside lawyer's hours at Book F9's illustrative rate.

The case is Hydrosentinelle inc., the company of Book A5 (Financing a Business), a fictional company in Sherbrooke that designs and sells connected water-leak detectors for commercial and rental buildings. Its two founders hold the platform work between them, the plan engages two outside helpers for named jobs, five kinds of help are named and not engaged, and no one is hired, all posed by this book. The plan takes 99 hours and engages $22,140, posed by this book, and nothing in the case is credited to any help. The chapter is not legal, competition or privacy advice, and it recommends no vendor, no platform, no agency and no adviser.

In This Chapter

Section 9.1 sets out the roles behind platform work and who holds each in the case. Section 9.2 reads the owner as the first platform strategist. Section 9.3 covers who manages the relationship with each platform. Section 9.4 covers the integration developer and the forms of an outside engagement. Section 9.5 covers security, privacy and compliance help. Section 9.6 covers legal help on platform terms and on dominance. Section 9.7 covers integration agencies and platform consultants. Section 9.8 covers publicly funded help for technology firms. Section 9.9 reads an integration agency's proposal against the company's own written need.

9.1 The Roles Behind Platform Work

Platform work is a set of roles, and a small firm may hold several of them in the same two people. Seven roles stand behind a small firm's platform work, and an eighth sits outside the firm.

The first role is the owner as the first platform strategist. In a small firm nobody else holds the decision of where to plug in, how far to open the firm's own interface and what ceiling of dependence to hold, and section 9.2 reads that role in full. The second role is the holder of each platform relationship: one named person who reads the platform's terms, answers its partner program, keeps the register line of that platform and holds the quarterly review of Chapter 8. The third role is the integration developer, the person who builds and maintains the connection, who may be a founder, an employee, a freelancer or an agency. The fourth role is security, privacy and compliance help, an adviser who reads an integration against practices of the kind a security text sets out and against the rules that apply to personal information. The fifth role is legal help on platform terms and on dominance, a lawyer who reads a partner agreement before it is accepted and drafts the terms of use of the company's own interface. The sixth role is the integration agency or platform consultant, a provider that builds integrations, prepares a listing, answers a security review or advises on a platform strategy. The seventh role is publicly funded help, an advisory program that a technology firm may ask for advice.

The eighth role sits outside the firm. The platform's partner manager is a role at the platform and works for the platform, so the company brings its own agenda to every review and never treats the partner manager as a member of its own team. That is the book's reasoning and not a finding, and no source read measures how a platform's partner manager behaves or what a platform's partner program asks of a firm beyond the terms of the day it was read.

The roles of a partner program seen from the vendor who runs it are Book F9's (Building and Running a Partner Program, chapter 12 of Book F9), and this chapter cites that book rather than repeating it. Roles and delegation are Book I2's (Organizational Design, Roles, Delegation and Accountability), and this chapter takes from that book only the idea that a role is a set of tasks that one person holds. Hiring is Book I3's (Recruiting, Hiring and Onboarding), and the case hires no one: the two founders hold the platform work and two outside helpers are engaged for named jobs.

Figure 9.1 sorts the roles behind the case's platform work into the founders, the outside help the plan engages, and the help named but not engaged.

Figure 9.1 — Who does the platform work. Two founders, an outside integration developer on a posed fixed fee and an outside lawyer for 5 hours; five kinds of help named and not engaged; no hire.

The table below sets eight roles beside what each holds and who holds it in the case; the case is posed by this book, and the platform's partner manager works for the platform. Read it row by row: the first column names the role, the second says what the role holds, and the third says who holds it in Hydrosentinelle inc.

Table 9.1 — The roles behind platform work and who holds each in the case (posed)

Two things about the table are worth keeping when the rows are forgotten. The first is that the eighth role is not a role of the company: the partner manager works for the platform, and a company that treats the partner manager as its own account manager has handed a decision to the other side of the table. The second is that the first seven roles can be held by two people, and that holding several roles in one person is possible in a small firm; what causes trouble is leaving a role unnamed, because an unnamed role is read only when something has already gone wrong.

DEFINITION Role, platform relationship, outside help and acceptance criterion, as this book uses the words

These are this book's working words, and no source read defines them in this sense. A role is a set of tasks that one person holds, whether the person is a founder, an employee or an outside helper. A platform relationship is the whole of a company's dealings with one platform, held by one named person. Outside help is a skill or a reading that the company buys for a named job and a period. An acceptance criterion is the written condition that a deliverable must meet before it is accepted. A role is not a job title, and a small firm may hold several roles in one person. A platform relationship is not a friendship with a partner manager, and the partner manager works for the platform. Outside help is not a transfer of a decision, and the company keeps the decision it bought the help for. An acceptance criterion is not a wish, and a deliverable that does not meet it is not accepted. The words are this book's own, and the case's figures are posed by this book.

KEY CONCEPT Outside help buys a skill or a reading, and the decision stays with the company

Outside help buys a skill or a reading, and the decision stays with the company. A developer builds, a lawyer reads, an adviser examines and an agency prepares, and none of them decides where the company plugs in, how far it opens its own interface or what ceiling of dependence it holds. The company writes the need, the acceptance criterion and the decision, and reads what it receives. This is the book's reasoning and never a finding: no source read measures what outside help returns, what it costs, how many small firms engage a developer, a lawyer or an agency, or how long an engagement lasts, and none is cited for one. The case's figures are the case's own, posed by this book: two helpers engaged for named jobs, an outside integration developer on a fixed fee of $12,000 and an outside lawyer for 5 hours at Book F9's illustrative rate of $300 an hour, and no hire. A helper who is given a decision has been given something the company cannot buy back cheaply, and a helper who is given a named job and an acceptance criterion can be read against both.

9.2 The Owner as the First Platform Strategist

In a small firm the owner is the first platform strategist, and no outside helper holds that role. The owner decides where the company plugs in, how far it opens its own interface and what ceiling of dependence it holds, and those three decisions are the ones an outside helper is least able to take, because each of them turns on what the company is willing to risk rather than on what a platform offers.

The owner reads four things personally before any help is engaged. The first is the terms of each platform the company depends on, read on the day they are read and not only through somebody else's summary, because a term is a contract of the day and a summary of a term is not the term. The second is the map of the systems the customers already run, because the map decides which platform matters and which platform is merely loud. The third is the register of dependence with its ceiling, because a ceiling set after a platform has grown is a ceiling that has already been passed. The fourth is the alert path, because a critical path that runs through a platform is a critical path the company does not control, and the case's alert path runs through no platform at all.

None of those four readings is technical, and none of them can be delegated without the owner losing the thread that ties them together. A helper can read a partner agreement and report on it; a helper can build an integration and test it; a helper can examine a data flow and describe it. What a helper cannot do is decide that the company will accept a term, that the company will open an interface, or that the company will hold a ceiling of dependence at a given level. Those are decisions about the business, and they belong to the person who carries the consequences.

In the case, Laurence Bergeron, the president, holds the product and the engineering, the public interface and its first version, the security questionnaire and the privacy impact assessment, the monthly health reading and the upkeep of the integration. Karim Haddad, the head of sales and operations, holds the map of the platforms around the customers, the reading of each platform's terms, the partner program application and the listing, the dependence register and its ceiling, the weekly watch and the quarterly review with the platform's partner manager. The two founders hold the strategy together, and every figure of the case is posed by this book.

The plan of ninety days takes 99 hours: Karim Haddad 42 hours, Laurence Bergeron 52 hours and the outside lawyer 5 hours, posed by this book. The two founders' hours carry the strategy and the work around it, and the outside lawyer's hours are the hours of a reading. That proportion is the point of this section: the strategy is held inside the firm, and the reading is bought.

The owner's role does not shrink when the company grows; some of its readings may be shared. In a larger business a partnerships manager may hold the platform relationships and an operations manager may hold the routine, and the owner still holds the three decisions. In a solo business the owner holds every role and engages a developer and a lawyer for named jobs, which is the arrangement the case uses with two founders instead of one.

WHO DOES THIS Two founders hold the platform work, two outside helpers are engaged for named jobs, and no one is hired

The roles below are the case's, posed by this book. Laurence Bergeron, the president, holds product and engineering, the public interface and its first version, the security questionnaire and the privacy impact assessment. Karim Haddad, the head of sales and operations, holds the reading of each platform's terms, the listing, the dependence register and its ceiling, and the partner reviews. The outside integration developer builds the first integration under a fixed fee posed by this book. The outside lawyer reads the first platform's partner terms and drafts the terms of use of the public interface, for 5 hours at Book F9's illustrative rate. The first platform's partner manager is a role at the platform and works for the platform. No one is hired. In general, one person holds each platform relationship with a named backup, and that is this book's suggestion and not part of the case. In a solo business the owner holds every role and engages a developer and a lawyer for named jobs. In a larger business a partnerships manager holds the relationships. No hour and no amount is promised to a reader.

9.3 Who Manages the Relationship With Each Platform

One named person holds each platform relationship, with a named backup, and writes the company's own agenda before each review. The reason is simple and it is not a matter of courtesy: the platform's partner manager is a role at the platform and works for the platform, so a review with no agenda of the company's own is a review conducted on the platform's terms.

The holder of a relationship does four things. The holder reads the platform's terms, on the day they are read, and keeps the reading with its date. The holder answers the platform's partner program, which means the application and the renewal, and sees that the security questionnaire is answered by the person who can answer it. The holder keeps the register line of that platform, so that the exposure of the company to that platform is written in one place with its ceiling. And the holder holds the quarterly review of Chapter 8, which is the moment when the company's agenda meets the platform's.

The holder also writes down what the holder may decide alone and what goes to the owner. A holder who may answer a questionnaire alone is a holder who can keep a program alive; a holder who may sign a new term alone is a holder who has been given a decision the owner should keep. The line between the two is worth writing once, in a sentence, because a line that lives in memory is a line that moves.

In the case, Karim Haddad holds the relationship with the first platform, and the first platform's partner manager is a role and never a person of the case, posed by this book. The quarterly review with the partner manager takes 2 hours each time and is held 4 times a year, which is 8 hours a year, posed by this book. The weekly watch of the terms, fees and policies of each platform takes 0.5 hour each time and is held 52 times a year, which is 26 hours a year, posed by this book. Those two recurring lines of the routine of Chapter 8 are held by one person, Karim Haddad.

An assistant can prompt the holder and cannot hold the relationship. In the application copy of September 7, 2026, read on October 15, 2026, Control center → AI Agents (/agents-ia) reads tasks and can create a plan task after a click; it reads no platform's terms, watches no integration and negotiates nothing (La Machine, 2026). The relationship is held by a person, and the assistant only prompts; a business should check it in its own installation.

METHOD Choosing who holds each platform relationship in five steps

First, list the platforms the business depends on, from the register of Chapter 6, and write each one on its own line. Second, name one person for each platform and one backup, because a relationship whose holder is away is a relationship that is not held. Third, write for each platform the company's agenda for the next review, before the platform's partner manager sets one, so that the review opens on the company's questions. Fourth, write what the holder may decide alone and what goes to the owner, such as signing a new term or accepting a change of fee. Fifth, after a quarter read the register against what was decided, and change the holder if the line is not kept. This is the book's reasoning and not a tested procedure, and no source read measures how a platform relationship is best held. The case follows these steps with Karim Haddad as the holder of the first platform, posed by this book.

IN LA MACHINE The assistant reads tasks and can create a plan task after a click, and it reads no platform's terms

In the application copy of September 7, 2026, read on October 15, 2026, Control center → AI Agents (/agents-ia) reads tasks and can create a plan task after a click (La Machine, 2026). It reads no platform's terms, watches no integration and negotiates nothing, so each role of this chapter is held by a person and the assistant only prompts. A business that wants the weekly watch of terms written as a task can ask for a plan task with an observable end; the reading of the terms, the agenda and the review stay with the holder, because the assistant holds no agenda for a review. A business should check it in its own installation. La Machine is described and never sold, and the case does not use it.

9.4 The Integration Developer

The person who builds and maintains an integration may be a founder, an employee, a freelancer or an agency, and the company writes the acceptance criterion in every case. The reason is that the acceptance criterion is the part of the engagement that the company writes itself and can check from the first day to the last: a scope can be argued about, a fee can be renegotiated, and a deliverable either meets the written condition or does not.

The forms of fee for outside integration work are four, and each is described by its form and never by an amount. A fixed fee for a scope buys a named deliverable for a price agreed before the work starts, and it puts the risk of the estimate on the provider. A day rate buys a provider's day, and it suits work whose scope cannot be written in advance. An hourly rate buys a provider's hour, and it suits a small piece of work or a reading. A mandate priced by scope buys a result defined by the company, with the provider proposing the price for it. None of the four is better than another in general; each fits a different kind of job, and the company chooses the form that matches how well it can write the scope.

Buying outside work, its bench of providers and its control are Book I8's (Freelancers, Agencies and Outsourcing), and this chapter cites that book rather than repeating it. The developers of automation are Book K8's (No-Code, Low-Code and Integrations, chapter 10 of Book K8), and this chapter cites that book for the building of a connection rather than describing it again. Whether an engagement is a service contract or employment is a question for Book H7 (Employment Law Essentials (Québec and Canada)) and a lawyer, and this book decides nothing about it. Who owns what the developer writes is a question for the contract and for Book H5 (Intellectual Property), and the company should have that question answered before the work starts rather than after.

In the case, the outside integration developer is a provider of the bench of Book I8 and builds the first integration under a fixed fee of $12,000, posed by this book, with the acceptance criterion written by Laurence Bergeron. The criterion is written by the company and not by the provider, and the deliverable is read against it. The case engages no other developer, and no one is hired.

The table below sets four forms of fee beside what each buys and what to write down; it is the book's reasoning, illustrative and not a finding, and no amount is printed in it. Read it as a way of matching a form to a job: the first column names the form, the second says what the form buys, and the third says what the company should write down before the work starts.

Table 9.2 — The forms of fee for outside integration work

The case uses the first row. The fixed fee of $12,000 is posed by this book, and it is the only amount the case pays a developer.

TOOLS OF THE TRADE What any workspace shared with an outside developer must offer, whatever it is called

Eight functions carry a shared build, and a business should look for them rather than for a product. The first is a place for the written need and the acceptance criterion, so that both sides read the same sentence. The second is a list of tasks with a status that both sides can read, so that the state of the work is visible without a meeting. The third is a sandbox where the build can be tested without customer data. The fourth is access that is given to a named person and that can be removed the same day, because an account that outlives an engagement is an account nobody watches. The fifth is a trace of what was changed and by whom, so that a change can be read after the fact. The sixth is a place for the handover documents and for the keys that must be rotated at the end. The seventh is an export of everything in a form another tool can read, so that the company is not locked into the workspace. The eighth is a way to record the acceptance criterion as met or not met, with a date. No brand name belongs on this list and no price; the requirement is the function.

9.5 Security, Privacy and Compliance Help

An adviser reads an integration against practices of the kind that a security text sets out, and the reading is a practice and never a rule of law. The text read for this book is the best current practice for the security of the authorization framework, read on October 15, 2026, and what it sets out is specific enough to be read against a build: public clients must use proof key for code exchange; the implicit grant should not be used; access tokens should be restricted to the minimum privileges and to a specific resource server; and the resource owner password credentials grant must not be used (Lodderstedt et al., 2025). Those are the text's own requirements and recommendations, read at the level of the text read, and they are a practice that a security adviser reads an interface against, never a rule of law and never a statement about the reader's own build.

Security, backups and continuity are Book K3's (Cybersecurity, Backups and Business Continuity), and this chapter cites that book rather than repeating it. What this section adds is the shape of the engagement: an adviser is engaged for a named reading, on a named interface or a named data flow, and the reading is written down so that the company can act on it.

The rules that apply to personal information are a separate question, and they are called to the book that holds them. The Act respecting the protection of personal information in the private sector (CQLR c P-39.1, ss. 3.3 and 18.3, Québec, up to date to August 12, 2026, read on October 15, 2026) asks, in section 3.3, for a privacy impact assessment for any project to acquire, develop or overhaul an information system involving personal information, with the person in charge consulted from the outset, and it asks, in section 18.3, that information may be communicated without consent to a mandatary or a contractor if necessary, with the mandate in writing and the protection measures specified; Book H2 (Privacy and Personal Information) holds the mechanics of that Act, and this book applies neither section to the reader's own project.

In the case, Laurence Bergeron answers the security questionnaire of the first platform's partner program, submitted on day 58, and completes the privacy impact assessment on day 86, both posed by this book. A security and privacy adviser is named and not engaged, posed by this book. Nothing in the case is credited to any adviser.

QUÉBEC & CANADA NOTE A privacy impact assessment and a written mandate to an outside developer are questions for Book H2

The Canadian point of this section is the shape of the rules on personal information. The Act respecting the protection of personal information in the private sector (CQLR c P-39.1, ss. 3.3 and 18.3, Québec, up to date to August 12, 2026, read on October 15, 2026) asks, in section 3.3, for a privacy impact assessment for any project to acquire, develop or overhaul an information system involving personal information, with the person in charge consulted from the outset, and it asks, in section 18.3, that information may be communicated without consent to a mandatary or a contractor if necessary, with the mandate in writing and the protection measures specified; Book H2 (Privacy and Personal Information) holds the mechanics of that Act. This book explains published rules and recommends no vendor, and a business with a question about its own project or its own mandate should ask a privacy adviser or a lawyer. The case completes its privacy impact assessment on day 86, posed by this book. Nothing here says whether the reader's own project or mandate complies.

9.6 Legal Help on Platform Terms and Dominance

A lawyer reads the partner agreement before it is accepted and drafts the terms of use of the company's own interface, and the decision stays with the company. The reading comes first because a partner agreement that the company cannot negotiate may be a contract of adhesion, a notion that Book H1 holds, and the moment at which the company can decide is before it accepts.

Contracts and contracts of adhesion are Book H1's (Contracts and Commercial Agreements), and this chapter calls that book rather than reading a clause again. What this section adds is the timing: the reading happens before the acceptance, and the reading is written down with its date, so that a later change of terms can be read against what was read.

Whether a term bears on competition is a separate question, and it is called to the book that holds it. The Competition Act (R.S.C. 1985, c. C-34, ss. 75(1), 77(1), 78(1), 79(1) and 103.1(1), Canada, current to September 21, 2026, read on October 15, 2026) provides, in section 75(1), that the Tribunal may order a supplier to accept a person as a customer, among other conditions; in section 77(1), it defines exclusive dealing, market restriction and tied selling; in section 78(1), it defines an anti-competitive act; in section 79(1), where persons substantially or completely control a class or species of business, the Tribunal may make an order on either of two alternative paths, a practice of anti-competitive acts or conduct that has the effect of preventing or lessening competition substantially and is not the result of superior competitive performance; and in section 103.1(1), any person may apply to the Tribunal for leave to bring an application under sections 75, 77 or 79, among others; Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements) holds the mechanics of that Act, and this book applies none of those sections to a real platform.

The page of the competition regulator read for this book dates its guidelines March 7, 2019, and the page was modified June 27, 2024; a notice at the top says that after recent amendments to the Act the Bureau is reviewing its guidelines and will update them; the guidelines set out three cumulative elements, which predate the amendments, so that the current section 79(1) has two alternative paths and the three elements are never printed as the current test (Competition Bureau, 2019). For a multi-sided platform the page says that the Bureau may define a market on one side but accounts for interdependent demand and feedback effects across sides, and that network effects of platforms that match buyers and sellers can make entry harder; a refusal to supply can be explicit or constructive, and the input must be competitively significant and not feasibly obtained elsewhere. The page says nothing on self-preferencing and makes no finding against a named platform. Only the Tribunal or a court decides whether a platform abuses a dominant position, and this book concludes nothing.

In the case, the outside lawyer reads the first platform's partner terms, read by day 21, and the decision is written on day 28, and the outside lawyer drafts the terms of use of the public interface, 5 hours in all at Book F9's illustrative rate of $300 an hour, posed by this book. A competition lawyer is named and not engaged, posed by this book.

THE RULE A lawyer reads the partner terms before the company accepts them, and the decision stays with the company

This is the book's own rule for the case, drawn from its reasoning and not from a source. Before the company accepts the partner terms of a platform, a lawyer reads them, and contracts of adhesion are Book H1's (Contracts and Commercial Agreements). Whether a term bears on competition is Book H4's (Consumer Protection, Advertising Law, Competition and Language Requirements), and only the Tribunal or a court decides whether a platform abuses a dominant position. The decision to accept stays with the company, and a lawyer's reading informs that decision without taking it. The rule is neither a standard nor a legal duty, and it says nothing about whether the reader's own agreement complies. The case's outside lawyer reads the first platform's partner terms by day 21, 5 hours in all at Book F9's illustrative rate of $300 an hour, posed by this book. No figure beyond the case's is printed here.

WHAT CHANGED In 2019 the competition regulator wrote its guidelines on abuse of dominance, and the current section 79(1) now has two alternative paths

The dated change comes from the page of the competition regulator read in full on October 15, 2026: the guidelines are dated March 7, 2019, and the page was modified June 27, 2024; a notice at the top says that after recent amendments to the Act the Bureau is reviewing its guidelines and will update them; the guidelines set out three cumulative elements, which predate the amendments, so that section 79(1) of the Competition Act (current to September 21, 2026) now has two alternative paths, and the three elements are never printed as the current test (Competition Bureau, 2019). The Act is called to Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements), and a lawyer reads the Act and not the guidelines alone. The dates of sources are never dates of the case, which is counted in days.

9.7 Integration Agencies and Platform Consultants

An integration agency or a platform consultant is a provider that does four kinds of work: it builds integrations, it prepares a listing, it answers a security review, and it advises on a platform strategy. Each of those is a job with a deliverable, and each of them can be bought for a named scope.

What such a provider does not do is decide for the company or promise a result. A provider that builds an integration does not decide where the company plugs in; a provider that prepares a listing does not decide what the company sells; a provider that answers a security review does not decide what the company will accept in its own interface; and a provider that advises on a platform strategy offers a reading that the owner tests against the company's own map, register and ceiling. No outcome claim of any provider is printed in this book, and no agency, no consultant and no platform is named, ranked or recommended.

The forms of the fee are the same four as for a developer, described by form and never by an amount: a fixed fee for a scope, a day rate, an hourly rate, or a mandate priced by scope. Buying outside work from an agency, its bench of providers and its control are Book I8's (Freelancers, Agencies and Outsourcing), and this chapter cites that book rather than repeating it.

When to ask is the book's reasoning and a suggestion, never a rule. A company asks when a build exceeds the hours the founders have, when a review needs a skill the firm does not hold, or when a platform strategy is one the owner cannot test alone. None of those three conditions is measurable in general, and no source read measures how many small firms engage an agency or what an engagement returns. The company that asks writes the need first, and reads what it receives against the need.

In the case, an integration agency is named and not engaged, posed by this book. The first integration is built by the outside integration developer on a fixed fee, and the platform strategy is held by the two founders. Naming a kind of help without engaging it is not the same as engaging it, and the case's figure keeps the two apart.

WATCH OUT Choosing help by its label and signing an open-ended mandate are two traps

Two traps catch a company that buys outside help, and each has a question that catches it. The first is choosing help by its label: a title or a brand stands in for the skill that the job needs, and the company engages a provider whose work resembles the job only in name. The question is what has this person built or read that resembles the job, and what is the acceptance criterion. The second is signing an open-ended mandate: a fee with no scope runs on, the deliverable is never accepted, and the engagement ends when somebody loses patience rather than when the work is done. The question is what is the scope, the form of the fee and the day on which the engagement ends. This is the book's reasoning and it is illustrative; no frequency of either trap in any business is printed, and no source read measures it. The case engages two helpers for named jobs, a fixed fee for the build and 5 hours for the lawyer, posed by this book.

9.8 Publicly Funded Help for Technology Firms

A publicly funded advisory program is a source of advice that a technology firm may ask about, and it is never a promise of funding. The page read for this book says that the program offers financial assistance, advisory services and connections to business and research expertise in Canada, for innovative small or medium-sized businesses (National Research Council Canada, 2023). That is the page's own description of its program, read on October 15, 2026, and the page was modified December 20, 2023.

What the page read does not give matters as much as what it gives. The page read gives no eligibility criteria, and it names no funding of an integration. A company that reads the page and concludes that a program will pay for an integration has read more than the page says. The page describes a program; whether a given business qualifies, and what a given program will fund, are questions for the program and for the book that holds public programs.

Book G7 (Grants, Subsidies and Public Programs) holds public programs and their applications, and this chapter calls that book rather than describing an application. What this section adds is the place of publicly funded help in the set of roles: it is a seventh role, it is a source of advice and connections, and it is not a substitute for the owner's own reading of a platform's terms or for a lawyer's reading of a partner agreement.

Asking about a program is not the same as applying to it, and applying to a program is not the same as being funded by it. The company keeps its own plan and its own decisions either way, and nothing in the case is credited to any program.

In the case, a publicly funded advisory program is named and not engaged, posed by this book, and the case applies for nothing in this book. The plan of ninety days is carried by the two founders and two outside helpers, and the case's figures are posed by this book.

9.9 Reading an Integration Agency's Proposal

A proposal is the agency's own offer, and it is read against the company's written need. The order matters: the need is written first, in the company's own words, and the proposal is read against it; a proposal read before the need is written sets the need, because a company that has not written what it wants may accept what it is offered.

Reading a proposal is not the same as judging a provider. The book prints no rating of any agency, no outcome claim of any provider, and no amount for outside help other than the case's posed fixed fee and the outside lawyer's hours at Book F9's illustrative rate. What the reading produces is a set of answers to questions the company has written down, and a decision about whether the answers match the need.

Buying outside work and its control are Book I8's (Freelancers, Agencies and Outsourcing), and this chapter cites that book rather than repeating it. What this section adds is the reading itself, in the form of seven questions that a company puts to a proposal before it answers.

The table below sets seven questions beside what to read in a proposal and what to check against the company's own need; it is a reading guide and never a rating of any provider, and no amount is printed in it. Read it as a list of questions to answer in writing: the first column names the question, the second says what to read in the proposal, and the third says what to check against the company's own written need.

Table 9.3 — Seven questions to put to an integration agency's proposal

The case reads the proposal of its outside integration developer against the acceptance criterion that Laurence Bergeron writes, and the fixed fee of $12,000 is posed by this book. The criterion is written by the company, the deliverable is read against it.

DO THE MATH The outside lawyer's hours, the founders' hours and what the plan engages, line by line

Illustrative figures; the case is fictional. Step 1 — The outside lawyer works 5 hours, 2 in days 1 to 30, none in days 31 to 60 and 3 in days 61 to 90, at Book F9's illustrative rate of $300 an hour, which is $1,500. Step 2 — Karim Haddad works 42 hours at $60 an hour, which is $2,520. Step 3 — Laurence Bergeron works 52 hours at $60 an hour, which is $3,120. Step 4 — The plan takes 99 hours, and the three amounts add up to $7,140. Step 5 — With the developer's fixed fee of $12,000 and the first annual fee of $3,000, the plan engages $22,140. The hours and the two fees are posed by this book, the rates are illustrative and not a pay, nothing is credited to any help, and the sums are exact.

CASE IN POINT Hydrosentinelle inc. engages two outside helpers for named jobs and hires no one

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. Laurence Bergeron and Karim Haddad hold the platform work between them. The outside integration developer builds the first integration under a fixed fee of $12,000, posed by this book, with the acceptance criterion written by Laurence Bergeron. The outside lawyer reads the first platform's partner terms and drafts the terms of use of the public interface, for 5 hours at Book F9's illustrative rate. A security and privacy adviser, an integration agency, a competition lawyer and a publicly funded advisory program are named and not engaged. No one is hired. The plan takes 99 hours and engages $22,140, all posed by this book, illustrative and not a forecast, and nothing in the case is credited to any help.

Chapter 10 reads the tools by function, and this chapter names none.

Costly Mistakes

• Leaving a platform relationship without a named holder. A relationship with no holder is read when something has gone wrong, and the terms of a platform are read best on the day they are read rather than after a change has arrived.
• Treating the platform's partner manager as a member of the company's own team. The partner manager is a role at the platform and works for the platform, so a review conducted without the company's own agenda is a review conducted on the platform's terms.
• Handing a decision to a helper along with the job. A developer builds, a lawyer reads and an adviser examines, and a company that lets a helper decide where it plugs in or how far it opens its interface has given away the decision it bought the help for.
• Engaging outside help without a written acceptance criterion. A deliverable that is not read against a written condition is a deliverable that is accepted because the work took a long time rather than because it meets the need.
• Choosing help by its label rather than by the job. A title or a brand stands in for the skill the job needs, and the question that catches it is what has this person built or read that resembles the job.
• Signing an open-ended mandate. A fee with no scope runs on, the deliverable is never accepted, and the engagement ends when somebody loses patience rather than when the work is done.
• Reading a public program's page as a promise of funding. The page read describes a program and gives no eligibility criteria and no funding of an integration, and whether a given business qualifies is a question for the program and for Book G7 (Grants, Subsidies and Public Programs).

Key Takeaways

• Seven roles stand behind a small firm's platform work — the owner as the first platform strategist, the holder of each platform relationship, the integration developer, security, privacy and compliance help, legal help on platform terms and dominance, the integration agency or consultant, and publicly funded help — and an eighth role sits outside the firm, the platform's partner manager, who works for the platform.
• The owner holds the three decisions that no helper can take: where the company plugs in, how far it opens its own interface, and what ceiling of dependence it holds; the four readings the owner does before any help is engaged are the terms of each platform, the map of the customers' systems, the register with its ceiling, and the alert path that runs through no platform.
• One named person holds each platform relationship, with a named backup, writes the company's own agenda before each review, and knows what may be decided alone and what goes to the owner.
• Outside help buys a skill or a reading and never a decision; the forms of the fee are a fixed fee for a scope, a day rate, an hourly rate and a mandate priced by scope, described by form and never by an amount, and the company writes the acceptance criterion in every case.
• A lawyer reads a partner agreement before it is accepted and drafts the terms of use of the company's own interface; contracts of adhesion are Book H1's, competition law is Book H4's, and only the Tribunal or a court decides whether a platform abuses a dominant position.
• A proposal is the agency's own offer and is read against the company's written need, with seven questions — the scope, the deliverables and the acceptance criterion, the form of the fee, who owns the code and the data, the access given and how it is removed, the handover and the way out, and the outcome claims — and no outcome claim of any provider is printed in this book.

Your Action Plan

1. List the roles behind your platform work and name who holds each one. Write the seven roles and the eighth role that sits outside the firm, and put a name beside each one, with a backup for every role that touches a platform. Deliverable: a written list of roles with a holder and a backup for each. Verification: every role has a holder, every platform relationship has a backup, and the platform's partner manager is written as a role at the platform rather than as a member of the team.
2. Write the company's own agenda before the next review with a platform. Put the questions the company wants answered at the top of the review, and write what the holder may decide alone and what goes to the owner. Deliverable: a one-page agenda with the company's questions and the line between the holder's decisions and the owner's. Verification: the agenda is written before the platform sets one, and the line between the two kinds of decision is written in a sentence.
3. Write the acceptance criterion before engaging any outside helper. Put the need, the deliverable and the condition for acceptance in writing, and choose the form of the fee that matches how well the scope can be written. Deliverable: a written need with an acceptance criterion and a chosen form of fee. Verification: the criterion can be read by a second person, and the form of the fee is named without an amount.
4. Read any proposal against the seven questions before answering it. Go through the scope, the deliverables and the acceptance criterion, the form of the fee, who owns the code and the data, the access given and how it is removed, the handover and the way out, and the outcome claims. Deliverable: the seven questions answered in writing for each proposal received. Verification: every question has an answer, and any outcome claim is marked as a claim rather than as a deliverable.
5. Decide which kinds of help you will name and not engage, and write down why. Put the security and privacy adviser, the integration agency, the competition lawyer and the publicly funded advisory program on a list with the condition under which each would be engaged. Deliverable: a written list of named help with the condition for engaging each. Verification: each kind of help has a condition, and none of them is described as engaged when it is not.

In La Machine

In the application copy of September 7, 2026, read on October 15, 2026, Control center → AI Agents (/agents-ia) is the one page that touches this chapter's subject: it reads tasks and can create a plan task after a click (La Machine, 2026). That is the whole of what the platform offers here, and a business should check it in its own installation.

What a business needs elsewhere is every role of this chapter. La Machine names no partner manager, keeps no register of the roles of a platform relationship, reads no platform's terms, watches no integration and negotiates nothing, so each role is held by a person and the assistant only prompts. A person holds each platform relationship with a backup, a developer is engaged for a named build with a written acceptance criterion, a lawyer reads the partner terms before they are accepted, and an adviser is engaged for a named reading — each chosen by function and not by brand, and each read against the company's own written need. The case does not use La Machine, and the page above is one worked example of a business platform, described and never sold.

Self-Check

1. What are the seven roles behind a small firm's platform work, and which role sits outside the firm?
2. What are the four readings the owner does before any outside help is engaged, and why does the owner hold them?
3. Why does one named person hold each platform relationship, and what does the holder write before each review?
4. What are the four forms of fee for outside integration work, and what does the company write in every case?
5. What does a lawyer do about platform terms and dominance, and what does a lawyer not decide?

Answers. 1. The seven roles are the owner as the first platform strategist, the holder of each platform relationship, the integration developer, security, privacy and compliance help, legal help on platform terms and dominance, the integration agency or consultant, and publicly funded help; the eighth role sits outside the firm, the platform's partner manager, who is a role at the platform and works for the platform. 2. The four readings are the terms of each platform the company depends on, the map of the systems the customers already run, the register of dependence with its ceiling, and the alert path, which runs through no platform; the owner holds them because each turns on what the company is willing to risk rather than on what a platform offers, and a helper cannot decide that. 3. One named person holds each platform relationship, with a named backup, because a relationship with no holder is read only when something has gone wrong, and the platform's partner manager works for the platform; the holder writes the company's own agenda before each review, and writes what the holder may decide alone and what goes to the owner. 4. The four forms are a fixed fee for a scope, a day rate, an hourly rate and a mandate priced by scope, each described by form and never by an amount; the company writes the acceptance criterion in every case, because it is the part of the engagement the company writes itself and can check from the first day to the last. 5. A lawyer reads the partner agreement before it is accepted and drafts the terms of use of the company's own interface, and contracts of adhesion are Book H1's (Contracts and Commercial Agreements); a lawyer does not decide whether a platform abuses a dominant position, because only the Tribunal or a court decides that, and competition law is Book H4's (Consumer Protection, Advertising Law, Competition and Language Requirements).

Chapter References

Act respecting the protection of personal information in the private sector, CQLR c P-39.1, ss. 3.3, 17, 18.3 and 27 (Québec). LégisQuébec, up to date to August 12, 2026 — read October 15, 2026. https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1

Competition Act, R.S.C. 1985, c. C-34, ss. 75(1), 77(1), 78(1), 79(1) to (3.1) and 103.1(1) (Canada). Justice Laws Website, current to September 21, 2026 (last amended March 26, 2026) — read October 15, 2026. https://laws-lois.justice.gc.ca/eng/acts/C-34/

Competition Bureau. (2019). Abuse of dominance enforcement guidelines. Government of Canada. (Enforcement guidelines dated March 7, 2019; page modified June 27, 2024.) Retrieved October 15, 2026, from https://competition-bureau.canada.ca/en/how-we-foster-competition/education-and-outreach/abuse-dominance-enforcement-guidelines

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /agents-ia.

Lodderstedt, T., Bradley, J., Labunets, A., & Fett, D. (2025, January). Best current practice for OAuth 2.0 security (RFC 9700; BCP 240). RFC Editor. https://doi.org/10.17487/RFC9700

National Research Council Canada. (2023, December 20). About the NRC Industrial Research Assistance Program. Retrieved October 15, 2026, from https://nrc.canada.ca/en/support-technology-innovation/about-nrc-industrial-research-assistance-program

Chapter 10 — Tools: Functions and Popular Tools

A tool is a function before it is a product, and the register of integrations is the record to keep whatever tools are bought, so this chapter sorts platform and integration tools by function, gives each function one table of examples read on the day the chapter is written, with the pricing model and no amount, places La Machine among the functions, shows how to choose a tool and read the pricing and contract terms behind it, and applies the rule of free and already-paid first to Hydrosentinelle inc., which chooses no tool for its plan and builds its first integration with an outside developer on a fixed fee posed by this book.

What You'll Be Able to Do

• Name the six functions that platform and integration tools serve, and say for each one what it does and what it misses.
• Read a vendor's page for the function, the pricing model and the terms, without taking a vendor's claim about its own product for a fact.
• Keep a register of integrations that holds the owner, the data, the keys and the way out of each integration, whatever tools are bought.
• Choose a tool by function and by what the business already has and has already paid for, and add one only when a written need remains.
• Separate the identity layer from the provisioning of users, the gateway from the design of access, and the console from the reason a customer signed.
• Say plainly what a tool cannot do, and what a business must design itself before any tool is bought.

Why It Matters

Tools are chosen by name, and the function is quiet. A business sees a name it has heard, a vendor's page that promises to connect systems, and a free tier that costs nothing to try, and what can be missing is the sentence that should come first: what the business needs the tool to do, and what it already owns that does part of it. A spreadsheet, the workflow engine of a core business system the company already runs, and the tools already paid for are the first place to look, and a new tool is added only when a written need remains that none of them meets. That rule is this chapter's own, drawn from its reasoning and from no source.

The second reason is that tools change and the record does not. A business that has written down, for each integration, who owns it, what data cross it, which keys open it and how the business leaves it, can change a tool and keep the integration. A business that has written nothing has its integration inside a product, and when the product changes its pricing model or its owner, the integration goes with it. The register of integrations is the one record that no tool supplies, and the reference architecture of Chapter 7 (section 7.9) names it as one of its layers.

The third reason is cost. The plan of Hydrosentinelle inc. engages $22,140, posed by this book, and none of it buys a tool: the build is a build, the annual fee is a program's fee, and the hours are hours. A business that reads this chapter and buys nothing has lost nothing, and a business that buys one tool for a function it has written down has bought something it can name.

In This Chapter

Section 10.1 sets out what platform and integration tools do by function, with Table 10.1 and Figure 10.1. Section 10.2 covers integration platforms and workflow automation, with Table 10.2. Section 10.3 covers interface management, gateways and developer portals, with Table 10.3. Section 10.4 covers interface design, testing and monitoring, with Table 10.4. Section 10.5 covers identity and access services, with Table 10.5. Section 10.6 covers co-selling and partner account tools, with Table 10.6. Section 10.7 covers marketplace listing and analytics consoles, with Table 10.7. Section 10.8 places La Machine among the functions, with Table 10.8. Section 10.9 covers choosing tools and the pricing and contract terms behind them, with Table 10.9.

10.1 What Platform and Integration Tools Do, by Function

A platform and integration tool is bought for a function, and the function is what a business should name before it reads a single vendor's page. Six functions surround a platform integration. Something moves data between two systems on a trigger, with retries and logs. Something receives the calls to an interface, checks a key, applies a limit and records the calls. Something describes an interface in a standard form, tests it against that description and watches the live interface and its events. Something confirms who a person is and manages the accounts of a customer's staff. Something maps the accounts that a company and a platform share. And something shows a listing, its inquiries, its reviews and its analytics. Around the six sits one record that no tool supplies: the register of integrations.

The register of integrations is the record that a business keeps for each integration, with its owner, its data, its keys and its way out, whatever tools it buys. It is this book's working term and not a product, and no source read defines it in this sense. The reference architecture of Chapter 7 (section 7.9) names it as one of its layers, and this chapter does not redraw that architecture; it says which functions of tooling sit around the register and what each of them sees and misses. A business that mistakes a tool for the register loses the register the day the tool is replaced.

No tool holds the whole integration, and each function sees only part of the work, as Table 10.1 and the key concept below set out. The register of integrations is the record that holds the functions together, and it holds them together because a person writes into it.

The functions come first and the products second. Products are named in the rows of the tool tables of sections 10.2 to 10.7 only, as examples read on the vendor's own page on the day the chapter is written, and none is named in the prose, the callouts, the headings, the figure description, the other tables or the references. A row is an example and never a recommendation, and no source read measures what a tool returns, how many businesses use one or what it costs.

The rule of free and already-paid first is stated here and kept in the rest of the chapter: the spreadsheet, the workflow engine of a core business system the company already runs and the tools already paid for are read first, and a new tool is added only when a written need remains that none of them meets. The rule is this book's own, drawn from no source, and it is neither a standard nor a legal duty.

Figure 10.1 sets six functions of platform and integration tools around one register of integrations, and places La Machine among the six.

Figure 10.1 — Six functions around one register. The register of integrations is the record a business keeps whatever tools it buys; La Machine is described as of the application copy of September 7, 2026, without a public interface or a connector marketplace.

The table below sets six functions and the register of integrations beside what each function does, what each one misses and how the case covers it by function only. Read it as the map of the chapter: the first three columns are the book's reasoning and never a finding, the fourth column is posed by this book, and no product is named in any cell.

Table 10.1 — Six functions around the register of integrations, and how the case covers each

DEFINITION Function, example row, pricing model and register of integrations, as this book uses the words

These are this book's working words, and no source read defines them in this sense. A function is what a tool does for a business, whatever the tool is called. An example row is a tool named in a table of this chapter, read on a vendor's page on the day the chapter is written, as an example of its function and never as a recommendation. A pricing model is the way a vendor charges as its page states it, such as a free tier, a trial, a subscription by seat or by tier, a usage-based plan or a plan on request, and it is printed without an amount. The register of integrations is the one record that a business keeps for each integration, with its owner, its data, its keys and its way out, whatever tools it buys. No figure is printed here.

KEY CONCEPT No tool holds the whole integration, and each function sees only part of the work

This is the book's reasoning and never a finding. An integration platform moves data and misses the design of the company's own interface. An interface gateway holds keys and limits and misses the design of access. A design and monitoring tool describes and watches and misses the decision about what to expose. An identity service confirms who signs in and misses what an integration may read. A co-selling tool shares opportunities and misses the company's agenda. A marketplace console shows the listing and misses why a customer signed. The register of integrations holds them together because a person writes into it. No source read measures what a tool returns, and the case buys no tool: the plan engages $22,140, posed by this book, and none of it buys one.

10.2 Integration Platforms and Workflow Automation

An integration platform moves data between the systems a business already runs, on a trigger, with retries and logs, and it runs workflows that people can read. It does not design the interface that the company opens to others, which is Chapter 5's subject, it does not own the contract between two systems, and it does not decide what an event means: it can carry an alert event from a sensor to a property-management system, and only the company that designed the event can say what the event is for.

The automation platforms and the interface tools of a business that connects its tools are Book K8's (No-Code, Low-Code and Integrations, chapter 11 of Book K8), and this chapter cites that book rather than repeating it. For a complementor, the connection to a customer's system has a trigger, a payload that should carry no more than the integration needs, a retry rule for when the receiving system is down, and a log that a person reads afterward.

In Hydrosentinelle inc., the first integration is built by the outside integration developer, a provider of the bench of Book I8 (Freelancers, Agencies and Outsourcing), under a fixed fee of $12,000 posed by this book, and the integration sends the signed alert event of a building directly to the first property-management system, where it opens one work order. The event carries the building, the unit label, the sensor's location, the time and the severity, and no tenant's name. Each event has an identifier, and a repeated delivery never opens a second work order. The company chooses no integration platform for this build.

A business that does buy an integration platform should read on the vendor's page what the tool connects to, because a connector list is the tool's reach and not the business's need; how a retry is handled and whether a repeated delivery is recognized; where the logs live and how they are exported, because the monthly health reading of Chapter 8 draws its counts from a delivery log; and the pricing model, without an amount.

The table below presents examples of the function of integration platforms and workflow automation, with the situation each row suits, its pricing cell and a note. This chapter is the only place of the book where a product is named, the vendor pages were read on October 15, 2026, and each row is set as of that day.

Table 10.2 — Examples of integration platforms and workflow automation tools

WATCH OUT An integration platform that moves data is not an interface, and a quiet monitor is not a safe integration

Two traps catch a business that buys by name, and each has a question that catches it. The first is taking an integration platform for the interface that the company opens to others: data move between two systems, and nobody has designed what a third party may read. The question is who may call what, with which key and under which limit. The second is taking a quiet monitor for a safe integration: a dashboard shows nothing wrong because it watches only what it was told to watch. The question is which counts the monthly health reading of Chapter 8 draws from the delivery log, and whether a person reads them. This book's reasoning is illustrative, and no frequency of either trap in any business is printed. In Hydrosentinelle inc., the first integration is built by the outside integration developer and the counts are read from the delivery log, posed by this book.

10.3 Interface Management, Gateways and Developer Portals

An interface gateway receives the calls to an interface, checks a key, applies a limit, records the calls and gives outside developers a place to read the documentation and to ask for access. It does not design the interface, because the shape of the resources, the fields of a payload and the events a company publishes are its own design, and Chapter 5 holds the practice of opening an interface small, signed and governed. It does not decide who may have access, which belongs to the company and to the terms of use it writes.

The limit of an interface and the answer a service gives when the limit is reached are Chapter 7's (section 7.8), and the interface tools of a business that connects its tools are Book K8's (No-Code, Low-Code and Integrations, chapter 11 of Book K8); this chapter cites both rather than repeating them. A limit is a number the company sets for each integrator, and a record of the calls is what a person reads when an integrator reports that something is slow or missing.

In Hydrosentinelle inc., the public interface is version 1: read access to buildings, sensors and alerts, two events, client credentials for each approved integrator, a limit of 120 requests a minute for each integrator, a sandbox and written terms of use. Two integrators are approved on day 90 and four on day 365, and the terms of use are drafted by the outside lawyer. The company chooses no gateway and no developer portal for this interface, posed by this book.

A business that does buy a gateway should read on the vendor's page whether it can issue, rotate and revoke a key for each integrator, how a limit is applied and what the service answers when the limit is reached, where the record of the calls is kept and how it is exported, and whether the developer portal is a place where an outside developer reads the documentation and asks for access or only a page that lists the endpoints.

The table below presents examples of the function of interface management, gateways and developer portals, with the situation each row suits, its pricing cell and a note; the vendor pages were read on October 15, 2026, and each row is set as of that day.

Table 10.3 — Examples of interface management, gateway and developer portal tools

TOOLS OF THE TRADE What any interface gateway and developer portal must offer, whatever it is called

Seven functions carry an open interface, and a business should look for them rather than for a product. The first is a key for each integrator that can be issued, rotated and revoked. The second is a limit for each integrator and an answer that explains the condition when the limit is reached. The third is a record of the calls with their answers and their times. The fourth is a place where an outside developer reads the documentation and asks for access. The fifth is a sandbox that sends test events without customer data. The sixth is the version of the interface and a notice period for a change. The seventh is an export of the records in a form another tool can read. No brand name belongs on this list and no price; the requirement is the function.

10.4 Interface Design, Testing and Monitoring

A design, testing and monitoring tool describes an interface in a standard form, tests it against that description, simulates the calls of a sandbox and watches the calls and the events of the live interface. It stops short of the decision: a tool can tell a company that a response does not match the description it wrote, and it cannot tell the company whether the description was the right one, whether the event it publishes is the event a customer needs, or whether a field should be exposed at all. Chapter 5 holds the practice of opening an interface small.

The description specification is worth reading at its own level. The latest page of the specification, read on October 15, 2026, shows version 3.2.1 of September 10, 2026, and the specification is a standard, programming-language-agnostic description of HTTP interfaces that lets people and computers discover what a service can do without its source code, other documentation or traffic inspection; its description has a field for the webhooks a consumer may receive (OpenAPI Initiative, 2026). That is what the page read says, and this section prints no more of it. It names no tool that renders the specification, and it draws no rule from it.

In Hydrosentinelle inc., the interface is described on day 60 and tested in its sandbox, and the health reading of Chapter 8 draws its counts from the delivery log, posed by this book. The company chooses no design, testing or monitoring tool. The interface carries two events, signed with HMAC-SHA256, a hash-based message authentication code, over the identifier, the timestamp and the body, so that a consumer can check that a delivery is genuine, and the identifier lets the consumer recognize a repeated one.

A business that does buy a tool of this function should read on the vendor's page which version of the description specification the tool supports, because a version is never assumed; whether the tool can watch an event as well as a call; and what the monitor watches, because a monitor watches only what it was told to watch and a quiet dashboard is not a safe integration.

The table below presents examples of the function of interface design, testing and monitoring, with the situation each row suits, its pricing cell and a note; the vendor pages were read on October 15, 2026, and each row is set as of that day.

Table 10.4 — Examples of interface design, testing and monitoring tools

WHAT CHANGED The latest page of the interface description specification lists version 3.2.1 of September 10, 2026, so a tool's support for a version is read on its page

The dated change comes from the latest page of the specification, read on October 15, 2026: the page lists version 3.2.1 of September 10, 2026, a standard, programming-language-agnostic description of HTTP interfaces that lets people and computers discover what a service can do without its source code, other documentation or traffic inspection, and its description has a field for the webhooks a consumer may receive (OpenAPI Initiative, 2026). A tool's support for a given version is read on the vendor's own page on the day, never assumed, and this section prints no earlier version, no change between versions and no tool that renders the specification. The dates of sources are never dates of the case, which is counted in days: the interface of Hydrosentinelle inc. is described on day 60, posed by this book.

10.5 Identity and Access Services

An identity and access service does two things that are easily spoken of as one. It confirms who a person is, so that other services accept the sign-in, and it creates, changes and removes the accounts of a customer's staff. The two are separate functions, and a service may offer one without the other. An identity service does not decide what an integration may read, because that is the company's own decision about scopes and permissions, and it does not remove a person's access in a system it does not reach.

The identity layer is worth reading at its own level. The specification read on October 15, 2026, first part, is a final specification of a foundation, and it is a simple identity layer on top of OAuth 2.0 that lets a client verify the identity of an end user from an authorization server's authentication and obtain basic profile information (Sakimura et al., 2023). The specification makes no choice between identity providers, and this section names no product that implements it. The provisioning protocol is a different text: read as published on October 15, 2026, it is an HTTP-based protocol to manage identities across domains, such as enterprise-to-cloud services, with a common user schema, an extension model and a service protocol (Hunt et al., 2015). This section names no product that implements that either.

The two are two functions, and a business should say which one it needs before it reads a vendor's page. A customer's staff signing in to the company's product through the customer's own identity provider is the first; the accounts of that staff being created, changed and removed as people arrive and leave is the second. The practice of both is Chapter 7's (sections 7.3 and 7.4).

In Hydrosentinelle inc., the public interface uses client credentials for each approved integrator, and the plan contains no single-sign-on work, posed by this book. The company chooses no identity service. A business that does buy one should read whether the service offers the identity layer, the provisioning of users, or both; where the accounts and the logs are stored; and what happens to the accounts when the contract ends.

The table below presents examples of the function of identity and access services, with the situation each row suits, its pricing cell and a note; the vendor pages were read on October 15, 2026, and each row is set as of that day.

Table 10.5 — Examples of identity and access services

10.6 Co-Selling and Partner Account Tools

A co-selling and partner account tool maps the accounts that a company and a platform share, shows the opportunities that each side can see and records the actions of a joint sale. The tool shows what each side can see, and it does not give the company the platform's agenda; it also does not make a platform's sales team sell for the company, and no tool does.

Co-selling with a platform's sales team is Chapter 4's (section 4.6), and the tools of a partner program seen from the vendor who runs it are Book F9's (Building and Running a Partner Program, chapter 13 of Book F9); this chapter cites both rather than repeating them. The tool answers one question, which accounts the two sides share, and it answers it before a joint sale rather than after.

In Hydrosentinelle inc., the quarterly review with the first platform's partner manager is held by Karim Haddad, the head of sales and operations, and takes 2 hours, 4 times a year, and the partner program's application and listing are also held by Karim Haddad, posed by this book. The company chooses no co-selling tool and no partner account tool, and the reviews are held by hand.

A business that does buy a tool of this function should read on the vendor's page which systems the tool connects to, what each side must disclose to the other, because a shared view of accounts is a disclosure in both directions and the terms of the platform's partner program govern part of it, and what the tool records after a joint sale.

The table below presents examples of the function of co-selling and partner account tools, with the situation each row suits, its pricing cell and a note; the vendor pages were read on October 15, 2026, and each row is set as of that day.

Table 10.6 — Examples of co-selling and partner account tools

WHO DOES THIS Laurence Bergeron reads what a tool does, Karim Haddad reads the terms behind it, and the case buys no tool

The roles below are the case's, posed by this book. Laurence Bergeron, the president, product and engineering, holds the technical assessment of each candidate and the design of the interface. Karim Haddad, the head of sales and operations, holds the reading of each platform's terms and the partner program. The outside integration developer builds under a fixed fee. The company chooses no tool. In general, and this is the book's suggestion and not part of the model, the person who will use a tool reads what it does, the person who signs reads the contract, and a second person tries the tool first. In a solo business the owner reads both and asks an adviser to read the contract. In a larger business a partnerships manager and a developer each read their part. No hour and no amount is promised to a reader.

10.7 Marketplace Listing and Analytics Consoles

A marketplace listing and analytics console shows the listing, its inquiries, installs, reviews and analytics, and lets a publisher update the listing. It stops at the signal: a console shows that a listing received a number of inquiries and that an application was installed a number of times, and it does not say why a customer signed, because a count is never a cause. A console does not make a listing succeed either: the listing is a page, the reviews are other people's words, and the signatures that follow an inquiry are the customers' decisions.

The article of a business marketplace, last updated July 23, 2026 and read on October 15, 2026, says that for a transactable offer the platform acts as the publisher's agent for billing, payment and collection while the publisher remains the seller and licensor, that a software-as-a-service offer sold this way must use the platform's identity service and its fulfillment interfaces, and that a listing may instead be non-transactable, free or bring your own license (Microsoft, 2026). That is the platform's own terms on the day read and never a market rate, and the fee of that article is read in Chapter 4 and not printed here. The signals of a listing, its reviews, its ratings and its installs, are Chapter 4's (section 4.7), and the management of listings on a marketplace is Book F5's (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces, chapter 11 of Book F5); this chapter cites both rather than repeating them.

In Hydrosentinelle inc., the listing is approved on day 84, and on day 365 the listing received 52 inquiries and 11 accounts with 34 buildings signed after an inquiry, which is 17.9 percent of the 190 new buildings of the year, posed by this book. Nothing says that the listing caused those signatures, and the company credits nothing to it. The company chooses no listing console and no analytics console.

A business that reads a console should read which counts the console shows and which it does not, because a console shows the signals the platform chose to show; whether an inquiry is a person who asked a question or a download that happened without a question, because the two are different facts; and the console's own terms about the data it holds, because a console can hold personal information about the people who asked.

The table below presents examples of the function of marketplace listing and analytics consoles, with the situation each row suits, its pricing cell and a note; the vendor pages were read on October 15, 2026, and each row is set as of that day.

Table 10.7 — Examples of marketplace listing and analytics consoles

QUÉBEC & CANADA NOTE A tool holds personal information, and the language of its interface and of its support is a question for Book H4

The Canadian point of this section is that a tool holds data about people. A marketplace console, an identity service or a log of calls can hold personal information, and where a tool stores that information and who may read it are questions for Book H2 (Privacy and Personal Information) and Book K3 (Cybersecurity, Backups and Business Continuity). The language of the interface and of the support that a Québec business offers its customers is Book H4's (Consumer Protection, Advertising Law, Competition and Language Requirements). This book explains published rules and recommends no vendor, and it tells no reader whether a given tool, contract or data flow complies; that is a question for an adviser. In Hydrosentinelle inc., the company chooses no tool, posed by this book.

10.8 La Machine: Workflows, the Tools Inventory and Plans in Their Place

La Machine is one worked example of a business platform, described and never sold, and it is not an integration platform. In the application copy of September 7, 2026, read on October 15, 2026, Control center → n8n (/n8n) shows a self-hosted workflow engine whose workflow definitions are versioned files published by a script, never clicks on a screen; it is the publisher's own engine and never an integration offered to the reader's customers (La Machine, 2026). Control center → Workflows (/registre) shows one line for each workflow or agent route, with its code, type, trigger, entry point and state; only the state can be changed on the screen and there is no column for an owner, so it can serve as a model for a register of integrations and it is not the reader's register. Control center → Tools (inventory) (/outils) lists tools with a measured version, a location and a date; it can serve as a model for an inventory of the dominant offers a business depends on, and it measures no exposure, no revenue and no share of customers. Control center → AI Agents (/agents-ia) reads tasks and can create a plan task after a click, and it reads no platform's terms, watches no integration and negotiates nothing. Support → Plans & Pricing (plans) lists interface access and single sign-on among the features of some organization plans, and neither has a screen in the copy read. The administration of the platform is Book N12's (Administration, Roles, Compliance and Backups) and the workflows of La Machine are Book N3's (Workflows, Automation and Human Approval); this chapter cites both rather than repeating them.

What is missing is this. There is no documented public interface, no interface description, no developer portal and no sandbox. There is no page where a user creates, rotates or revokes an interface key, and no delegated access by token for a third-party application. There is no webhook that a user can configure and sign for a customer. There is no single sign-on for a customer's staff and no provisioning or removal of users between systems. There is no rate limiter, no connector marketplace in service and no listing on another company's marketplace. There is no register of dependence on platforms and no measure of exposure, no watch of a platform's terms, no tracking of a certification or a security review, and no co-selling with a platform. Check it in your installation.

The tool tables of this chapter are where a business reads the functions La Machine does not carry: integration platforms and workflow automation in Table 10.2, interface management, gateways and developer portals in Table 10.3, interface design, testing and monitoring in Table 10.4, identity and access services in Table 10.5, co-selling and partner account tools in Table 10.6, and marketplace listing and analytics consoles in Table 10.7.

The table below sets the six functions of Table 10.1 and the register of integrations beside what La Machine offers for each and where to do it instead. Read it as one worked example of a business platform, described and never sold, and read every cell as a statement about the application copy of September 7, 2026 and about nothing else.

Table 10.8 — La Machine against the functions of this chapter

IN LA MACHINE A workflow engine, a register, an inventory and an assistant exist, and no interface gateway, portal or identity service does

In the application copy of September 7, 2026, read on October 15, 2026, Control center → n8n (/n8n) shows a self-hosted workflow engine whose definitions are versioned files (La Machine, 2026). Control center → Workflows (/registre) shows a register of workflows with a state and no owner column, a model for a register of integrations. Control center → Tools (inventory) (/outils) lists tools with a measured version and measures no exposure. Control center → AI Agents (/agents-ia) creates a plan task after a click. Support → Plans & Pricing (plans) lists interface access and single sign-on although the copy read has no screen for either. La Machine offers no documented public interface, no developer portal, no interface key a user manages and no single sign-on; check it in your installation. La Machine is described and never sold, and Hydrosentinelle inc. does not use it.

10.9 Choosing Tools, and the Pricing and Contract Terms Behind Them

Choosing a tool starts from the function and from what the business already has and has already paid for, which is the rule of section 10.1. The choice of a technology stack is Book K1's (The SME Technology Stack, chapter 11 of Book K1), and this chapter cites that book rather than repeating it.

Backups and the security of access are Book K3's (Cybersecurity, Backups and Business Continuity), and personal information that a tool holds is Book H2's (Privacy and Personal Information). The contract behind a tool is Book H1's (Contracts and Commercial Agreements), and the language of an interface and of support for a Québec business is Book H4's (Consumer Protection, Advertising Law, Competition and Language Requirements). This chapter cites each of them rather than restating it, and it tells no reader whether a given tool, contract or data flow complies; that is a question for an adviser.

The terms to read on a pricing page and in a contract are set out in Table 10.9, and they are worth reading before a tool is tried rather than after. The pricing model comes first, without an amount: what the vendor charges for and how the charge moves as the business grows. A free tier that excludes the function the business needs is not free, and a contract that renews automatically must be diarized. The amounts are left to the vendor's page and never printed here.

In Hydrosentinelle inc., the company chooses no tool and buys none, posed by this book: the plan engages $22,140, and none of it buys a tool, as the calculation below sets out. The company's nearest record to a register of integrations is its dependence register with its ceiling of 40 percent of the new buildings of any quarter, which lists each platform, the exposure, the notice and the way out, posed by this book.

The table below sets eight questions beside what to read on a vendor's page and what to check in the contract. It is a reading guide and not a rating of any provider, every cell is the book's reasoning and illustrative, and no amount is printed in it.

Table 10.9 — What to read on a vendor's page and in a contract

THE RULE Start with what is free and already paid for, and add a tool only when a written need remains

This is the book's own rule for this chapter, drawn from its reasoning and not from a source. The spreadsheet, the workflow engine of a core business system and the tools the business already pays for are read first, and a new tool is added only when a written need remains that none of them meets. The choice of a technology stack is Book K1's (The SME Technology Stack, chapter 11 of Book K1), and this chapter cites that book rather than repeating it. The rule is neither a standard nor a legal duty, and it never says that a tool is needed or that a tool is not needed; it says that the need is written down before the page is read. Hydrosentinelle inc. chooses no tool and buys none, posed by this book, and no figure beyond the case's is printed here.

METHOD Choosing a platform or integration tool in five steps

First, write the function in one sentence and the need that remains after what the business already has and has already paid for. Second, read the vendor's pricing page and the terms of Table 10.9, and write the date of the reading beside it. Third, try the tool on one integration in a sandbox, with no customer data. Fourth, decide with a written criterion and a person who owns the decision, and note the way out. Fifth, add the tool to the register of integrations, and read it again at the yearly reset of Chapter 8. This is the book's reasoning and not a tested procedure. Hydrosentinelle inc. follows the first and the fourth steps and buys no tool, posed by this book.

DO THE MATH Six functions, six tables of examples and no tool chosen for the case

Illustrative figures; the case is fictional. Step 1 — platform and integration tools serve six functions, from integration platforms to marketplace consoles. Step 2 — each function has one table of examples, Tables 10.2 to 10.7, read on the day the chapter is written. Step 3 — the case chooses 0 tools, posed by this book. Step 4 — the plan engages $22,140, posed by this book, which is $7,140 of hours at Book F9's rates, the developer's fixed fee of $12,000 and the first annual fee of $3,000, both posed by this book. Step 5 — none of the three amounts buys a tool, since the fixed fee pays for a build and the annual fee is the platform program's annual fee. The counts and the amounts are posed by this book, are the case's and not a norm, the amounts are the plan's and not tool prices, and the sums are exact.

CASE IN POINT Hydrosentinelle inc. chooses no tool and builds its first integration with an outside developer on a fixed fee

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. The six functions of this chapter are covered by function only. The first integration is built by the outside integration developer under a fixed fee of $12,000, posed by this book, and it sends the signed alert event of a building to the first property-management system. The public interface is version 1, with client credentials for each approved integrator, a limit of 120 requests a minute for each integrator and a sandbox, posed by this book. The listing is approved on day 84, posed by this book. The register that the company keeps is its dependence register with a ceiling of 40 percent of the new buildings of any quarter, posed by this book. No tool is chosen, priced or bought, and none is named. All of it is illustrative and not a forecast.

Costly Mistakes

• Buying a tool before writing the function. A business that starts from a product name buys a solution to a problem it has not written down, and it may buy a function it already owns.
• Taking an integration platform for the interface the company opens. Data moving between two systems is not an interface; who may call what, with which key and under which limit, is the company's own design.
• Reading a vendor's page as proof of an outcome. A vendor's page is the vendor's own claim about its own product, and no source read measures what a tool returns.
• Treating the identity layer and the provisioning of users as one function. A service may confirm who signs in without creating and removing the accounts of a customer's staff.
• Letting a console's counts stand for a cause. A console shows that a listing received inquiries and that an application was installed; it does not say why a customer signed, and a count is never a cause.
• Letting a tool stand for the register of integrations. A tool holds part of the work; the register holds the owner, the data, the keys and the way out, and it survives the replacement of every tool.
• Signing without reading the term, the renewal and the export. A contract that renews automatically and a tool that will not give the data back are read on the page and in the contract before the tool is tried.

Key Takeaways

• Platform and integration tools serve six functions, from integration platforms to marketplace consoles, and no tool holds the whole integration.
• The register of integrations is the one record a business keeps for each integration, with its owner, its data, its keys and its way out, whatever tools it buys, and the reference architecture of Chapter 7 (section 7.9) names it as one of its layers.
• The functions come first and the products second: products are named in the rows of the tool tables of sections 10.2 to 10.7 only, as examples read on the vendor's page on the day the chapter is written, with the pricing model and no amount, and never as a recommendation.
• The rule of free and already-paid first is this book's own: the spreadsheet, the workflow engine of a core business system and the tools the business already pays for are read first, and a new tool is added only when a written need remains that none of them meets.
• Hydrosentinelle inc. chooses no tool and buys none, posed by this book: the plan engages $22,140, and none of it buys a tool.
• La Machine is one worked example of a business platform, described and never sold: it shows a self-hosted workflow engine, a register of workflows and an inventory of tools with a measured version, and it is not an integration platform.

Your Action Plan

1. Write the function and the need before reading any vendor's page. Name the function in one sentence, then write what remains after the spreadsheet, the workflow engine of a core business system and the tools the business already pays for. Deliverable: one written page with the function and the remaining need. Verification: the need is written in one sentence, and a second person can say whether the tools already owned meet it.
2. Read the pricing model and the terms, and date the reading. Read the eight questions of Table 10.9 on the vendor's page, without an amount, and write the date beside each reading. Deliverable: a written reading of the terms with its date. Verification: every question of Table 10.9 has an answer or the words "not stated on the page".
3. Try the tool on one integration in a sandbox, with no customer data. Run the function on a test integration, with test events and no personal information, and write what the tool did and what it did not do. Deliverable: a written test note. Verification: the test used no customer data and the note names what the tool missed.
4. Decide with a written criterion and a named owner, and note the way out. Write the criterion, name the person who owns the decision, and write how the business leaves the tool if it must. Deliverable: a written decision with an owner and a way out. Verification: the decision names a person, a criterion and a way out, and the way out names the export and the notice.
5. Add the tool to the register of integrations and read it again at the yearly reset. Write the tool into the register beside the integration it serves, with its owner, its data, its keys and its way out. Deliverable: an updated register of integrations. Verification: every integration in the register names a tool or says that none is used, and the register is read once a year.

In La Machine

In the application copy of September 7, 2026, read on October 15, 2026, the pages that touch this chapter are Control center → n8n (/n8n), a self-hosted workflow engine whose definitions are versioned files; Control center → Workflows (/registre), a register of workflows and agent routes with no owner column, which can serve as a model for a register of integrations; Control center → Tools (inventory) (/outils), an inventory of tools with a measured version that measures no exposure; Control center → AI Agents (/agents-ia), which reads tasks and can create a plan task after a click; and Support → Plans & Pricing (plans), which lists interface access and single sign-on among the features of some plans although the copy read has no screen for either (La Machine, 2026). Check it in your installation.

What a business needs elsewhere is the rest of the functions. La Machine is not an integration platform: it offers no documented public interface, no developer portal, no interface key a user manages, no webhook a user configures, no single sign-on, no provisioning of users, no connector marketplace and no listing on another company's marketplace. An interface gateway and a developer portal, a description and a monitoring of the interface, an identity service, a co-selling tool and a marketplace console are each chosen by function in the tables of this chapter, and this book is valid with any tool. Hydrosentinelle inc. does not use La Machine, and the pages above are one worked example of a business platform, described and never sold.

Self-Check

1. What are the six functions that platform and integration tools serve, and what does each of them miss?
2. What is the register of integrations, and why does no tool supply it?
3. What is the rule of free and already-paid first, and where does it come from?
4. Why are the identity layer and the provisioning of users two functions, and what does each of them do?
5. What does a marketplace console show, and what does it never say?

Answers. 1. The six functions are integration platforms and workflow automation, interface management, gateways and developer portals, interface design, testing and monitoring, identity and access services, co-selling and partner account tools, and marketplace listing and analytics consoles; each sees part of the work, and the first misses the design of the company's own interface, the second the design of access, the third the decision about what to expose, the fourth what an integration may read, the fifth the company's own agenda and the sixth why a customer signed. 2. The register of integrations is the one record a business keeps for each integration, with its owner, its data, its keys and its way out, whatever tools it buys; no tool supplies it because each tool holds part of the work and the record is what a person writes into it. 3. The rule is that the spreadsheet, the workflow engine of a core business system and the tools the business already pays for are read first, and a new tool is added only when a written need remains that none of them meets; it is this book's own rule, drawn from its reasoning and from no source. 4. The identity layer lets a client verify the identity of an end user from an authorization server's authentication (Sakimura et al., 2023), and the provisioning protocol manages identities across domains with a common user schema (Hunt et al., 2015); a service may offer one without the other, and the practice of both is Chapter 7's (sections 7.3 and 7.4). 5. A marketplace console shows the listing, its inquiries, installs, reviews and analytics, and it never says why a customer signed: a count is a signal and never a cause, and in Hydrosentinelle inc. nothing is credited to the listing, posed by this book.

Chapter References

Hunt, P., Grizzle, K., Ansari, M., Wahlstroem, E., & Mortimore, C. (2015, September). System for Cross-domain Identity Management: Protocol (RFC 7644). RFC Editor. https://doi.org/10.17487/RFC7644

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /n8n, /registre, /outils, /agents-ia and plans.

Microsoft. (2026). Microsoft Marketplace transact capabilities (last updated July 23, 2026). Microsoft Learn. Retrieved October 15, 2026, from https://learn.microsoft.com/en-us/partner-center/marketplace-offers/marketplace-commercial-transaction-capabilities-and-considerations

OpenAPI Initiative. (2026, September 10). OpenAPI Specification v3.2.1. The Linux Foundation. https://spec.openapis.org/oas/v3.2.1.html

Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., & Mortimore, C. (2023, December 15). OpenID Connect Core 1.0 incorporating errata set 2. OpenID Foundation. https://openid.net/specs/openid-connect-core-1_0.html

Chapter 11 — Practical Advice, Pitfalls and Your Action Plan

Plugging into ecosystems without losing control takes a map, a grid, the terms read, a first integration, a small interface, a listing, a register with a ceiling and a routine, and a plan with gates that records can show, so this chapter says what matters most, names the ten most costly mistakes, lays out the plan in three slices — days 1 to 30 for the map, the grid and the terms, days 31 to 60 for the first integration and the public interface, and days 61 to 90 for the listing, the register and the routine — each ending at a gate on days 30, 60 and 90 with a missed gate read again 7 days later, then reads the few readings that show control kept, how to keep the practice alive and the case on day 365, entirely posed by this book, saying plainly that the plan is the book's own method, that its 99 hours and the $22,140 it engages are posed by this book and that no result is credited to it.

What You'll Be Able to Do

• State the six priorities that carry the whole book — plug into the systems the customers already run, read the terms of each platform on the day of signing, keep every critical path outside any platform, open the company's own interface small, signed and governed, measure dependence against a ceiling set in advance, and keep a small routine without promising a gain that cannot be proved.
• Name the ten most costly mistakes of a complementor, say why each one costs, and point to the chapter or the book that treats it.
• Lay out a plan of ninety days in three slices, with a gate at the end of each, a condition written before day 1, and a rule that a gate which is not met is read again 7 days later while nothing new starts.
• Run a gate in five steps, from reading its condition to writing what the gate showed and what it did not show.
• Read the six readings that show control kept — the share of new buildings that came after an inquiry, the duplicate work orders, the notices of change, the late alerts, the integrators and their keys, and the dates of the last reading of each platform's terms.
• Keep the practice alive after day 90 with the routine of Chapter 8, and say plainly what a plan, a gate and a ceiling can and cannot prove.

Why It Matters

A book about platforms can leave a reader with a great deal of understanding and no order in which to use it. The earlier chapters decided what a platform is, which dominant offer matters to a given customer base, what a partner program asks and gives, when to open one's own interface, how dependence builds and how data and identity cross an integration, and none of those decisions says what to do on the first Monday. What turns them into a business that has plugged into the systems its customers run is a sequence with dates, a person for each task and a record that shows the task was done. That sequence is what this chapter adds, and it adds no rule.

The order of the sequence follows the way the decisions lean on one another. A business should not score candidate integrations before it has drawn the map of the platforms around its customers, because the first criterion of the grid is the reach of each candidate over that base. It should not read a partner agreement before it knows which candidate the agreement belongs to, because the terms of a platform matter in proportion to what the business would put through it. And it cannot set a ceiling on its dependence before it has a register, because a ceiling is a number read against a list.

The cost of the sequence is stated plainly, and so is its limit. The plan takes 99 hours over ninety days, and with the developer's fixed fee and the first annual fee it engages $22,140, all posed by this book, illustrative, never a norm and never a promise. What the plan produces is a set of records: a map, a scored grid, a written decision, a partner agreement read by a lawyer, an integration live in a pilot, a security questionnaire submitted, a first version of a public interface, a listing approved, a privacy impact assessment completed, a dependence register with a ceiling, and a routine set as tasks. Whether those records produce a sale, an install or growth is not something this book can say, because no source read measures it and the case credits nothing to the plan. Dependence remains after the plan; what changes is that it is written down, measured against a ceiling set in advance, and watched.

In This Chapter

Section 11.1 states the six priorities that carry the book and gives the book's own sentence. Section 11.2 names the ten most costly mistakes, sets them beside why each one costs and the chapter that treats it, and adds three pitfalls documented by the code of one worked example of a business platform. Section 11.3 lays out the plan of ninety days in three slices with a gate at the end of each, gives the hours of the plan by slice and by person, and states the rule that a gate is passed by the records its condition names. Section 11.4 covers days 1 to 30, the map, the grid and the terms. Section 11.5 covers days 31 to 60, the first integration and the public interface. Section 11.6 covers days 61 to 90, the listing, the register and the routine. Section 11.7 gives the six readings that show control kept. Section 11.8 says how to keep the practice alive after day 90. Section 11.9 reads the case on day 365, entirely posed by this book, and closes the book.

11.1 What Matters Most

The whole book rests on one sentence, and this chapter begins by stating it plainly because everything that follows is an application of it. A business gains from a platform when it plugs into the systems its customers already run, reads the terms of each platform on the day it signs, opens its own interface small, signed and governed, keeps every critical path — above all its alerts — outside any platform, and measures its dependence against a ceiling it set in advance, without promising a gain that it cannot prove. That sentence is the book's reasoning and never a finding. No source read measures what a plan returns, and the case's figures are the case's own, posed by this book.

The first priority is to plug into the systems the customers already run, and not the loudest platform. The map of Chapter 3 exists for this reason: a business counts where its customers actually run their buildings, their accounts or their work, and it lets that count decide which dominant offer matters. In the case, Hydrosentinelle inc. monitors 820 buildings on day 1, a figure posed by this book, of which 312 run in the first property-management system, 148 in the second and 360 in other systems or none. A platform that holds none of those buildings costs hours and reaches nobody. The count is unglamorous, and it is where the choice starts.

The second priority is to read the terms of each platform on the day of signing. A platform's commission, fee, revenue share, notice period and removal clause are that platform's terms on the day they were read, and they change with notice. A business that signs without reading has accepted terms it has not seen. The reading is not a legal exercise for the owner alone; the case has the outside lawyer read the first platform's partner terms by day 21, and the decision is written on day 28. Whether a given clause is enforceable, and whether a platform's conduct crosses a line, is a question for a lawyer and, for competition law, for Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements); for contracts and contracts of adhesion, for Book H1 (Contracts and Commercial Agreements) and a lawyer.

The third priority is to keep every critical path outside any platform. In the case the critical path is the alert, and the alert goes by text message and by email directly, never through a platform. The work order in the first property-management system and the mobile application are conveniences that may fail without silencing an alert. A business that routes its alert through a platform has handed its most important promise to a company whose terms it does not control.

The fourth priority is to open the company's own interface small, signed and governed. The public interface of the case is version 1: read access to buildings, sensors and alerts, two events, client credentials for each approved integrator, a limit of 120 requests a minute for each integrator, a sandbox and written terms of use. Events are signed with HMAC-SHA256, a hash-based message authentication code, over the identifier, the timestamp and the body. Small means few endpoints and few events; signed means every event carries a signature and an identifier; governed means written terms of use and a way to remove an integrator and rotate a key.

The fifth priority is to measure dependence against a ceiling set in advance. The case's ceiling, posed by this book, is that no single platform brings more than 40 percent of the new buildings of any quarter, and that no alert path runs through any platform. A ceiling set after the fact is not a ceiling; it is a description. The register of Chapter 6 lists each platform, the revenue, customers, data and operations exposed, the notice its terms give and the way out.

The sixth priority is to keep a small routine and to promise no gain that cannot be proved. The routine of Chapter 8 takes 106 hours a year, posed by this book, and it is never added to the 99 hours of the plan. A business that promises a gain from an integration, a listing or an interface is promising something no source read supports, and the case credits nothing to any of them.

DEFINITION Gate, ceiling, register and reading, as this book uses the words

These are this book's working words, and no source read defines them in this sense. A gate is the day on which the conditions of a slice of the plan are read against records, and the case's gates fall on days 30, 60 and 90, posed by this book. A ceiling is the share that a single platform may not pass, set in advance, and the case's is 40 percent of the new buildings of any quarter, posed by this book. A register is the list of the platforms a business depends on, with the exposure, the notice and the way out of each. A reading is a count or a date that a leader reads, never a score and never a feeling. A gate is not a deadline, a ceiling is not a market figure, a register is not an inventory of software, and a reading is not a judgment about a person. The words are this book's own, and the case's figures are the case's own and illustrative.

KEY CONCEPT Plug into the systems customers run, read the terms the day you sign, open small, keep critical paths outside and measure dependence against a ceiling

This is the book's sentence, stated as the book's reasoning and never as a finding. A business gains from a platform when it plugs into the systems its customers already run, reads the terms of each platform on the day it signs, opens its own interface small, signed and governed, keeps every critical path — above all its alerts — outside any platform, and measures its dependence against a ceiling it set in advance, without promising a gain that it cannot prove. No source read measures what a plan returns, what a listing brings or what an interface earns, and the case's figures are the case's own, posed by this book: 99 hours of plan, $22,140 engaged, a ceiling of 40 percent of the new buildings of any quarter, and an alert path that runs through no platform. The sentence is a method and not a promise, and it is valid with any tool. The case credits nothing to the plan, the integration, the listing or the interface.

11.2 The Ten Most Costly Mistakes

This section names ten mistakes of a complementor, says why each one costs and points to the chapter that treats it. The list is the book's reasoning and illustrative; no source read measures how often any mistake is made in any business, and no frequency is printed here. Whether a given clause is enforceable is a question for Book H1 (Contracts and Commercial Agreements) and a lawyer, whether a platform's conduct touches competition law is a question for Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements), and the personal information of the ninth mistake is Book H2's (Privacy and Personal Information).

The table below sets the ten mistakes beside why each one costs and the chapter that treats it. It is the book's reasoning and not a finding, it adds no rule, and it is a checklist and not a ranking: no mistake on it is worse than another in every business.

Table 11.1 — The ten most costly mistakes and where to read them

Three pitfalls are worth adding, and they come from the code of one worked example of a business platform, read as general lessons and without blaming anyone. The first is that a task marked done proves nothing until a second person reads the criterion: Control center → Plan tasks (/taches) holds recurring or one-off tasks with a "Done when" criterion that is required when the task is created, and the Mark as done button does not check that criterion, so the routine of the plan can live there as recurring tasks with an observable criterion and a second reader (La Machine, 2026). The second is that a plans page can list a feature that has no screen, so a buyer checks the screen before relying on it. The third is that an inventory with a measured version says what is installed and never how much a business depends on it: Control center → Tools (inventory) (/outils) lists tools with a measured version, a location and a date, can serve as a model for an inventory of the dominant offers a business depends on, and measures no exposure, no revenue and no share of customers, so the exposure is measured elsewhere (La Machine, 2026).

IN LA MACHINE A task marked done proves nothing, a plans page can list a feature with no screen, and an inventory says what is installed and not how much a business depends on it

In the application copy of September 7, 2026, read on October 15, 2026, Control center → Plan tasks (/taches) holds the routine as recurring tasks with a required "Done when" criterion, and the Mark as done button does not verify that criterion, so a second person reads it (La Machine, 2026). A plans page can list a feature that has no screen, so a buyer checks the screen before relying on it. Control center → Tools (inventory) (/outils) lists tools with a measured version, a location and a date, and measures no exposure, no revenue and no share of customers, so the exposure is measured elsewhere (La Machine, 2026). La Machine keeps no register of dependence on platforms and watches no platform's terms, and it tracks no certification and no security review. Check it in your installation. La Machine is described and never sold, and the case does not use it.

WATCH OUT Starting the second slice before the first gate passes, and reading a met gate as a result, are two traps

Two traps catch a plan of ninety days, and each has a question that catches it. The first is starting the second slice before the first gate passes: the plan runs ahead of its own records, the map is half drawn, the grid is half scored, and the integration is built on a choice that was never written down. The question is which record shows that each part of the condition is met, and does the plan wait 7 days when it is not? The second is reading a met gate as a result: the records exist, and the integration is then called a success. The question is what the gate shows and what it does not show, since the figures of the case are posed by this book and nothing is measured. The book's reasoning is illustrative, and no frequency of either trap in any business is printed. In the case, each gate is read against its records and nothing is credited to the plan, posed by this book.

11.3 Plugging Into Ecosystems Without Losing Control in Ninety Days

The plan of this chapter is the book's own method, posed by this book and illustrative. It is never a norm, never a benchmark and never a promise, and no source read measures how long it takes to plug into an ecosystem, what a plan returns or how many hours a business should give to its platforms. What the plan does is put the decisions of the earlier chapters in an order, give each one a person and a day, and end each slice at a gate whose condition is written before day 1 and read against records.

The plan has three slices of thirty days. The first draws the map, scores the three candidates, has the partner terms read and writes the decision; the second builds the first integration and describes the public interface; the third approves two integrators, gets the listing approved and sets the routine. Table 11.2 gives the condition of each gate.

Each slice ends at a gate, on days 30, 60 and 90. A gate is passed by the records its condition names, and a gate that is not met is read again 7 days later while nothing new starts. The rule is the book's own for the plan, drawn from its reasoning and not from a source, and it is neither a standard nor a legal duty. The routine of Chapter 8 follows day 90 and is never added to the plan: the plan is a one-time sequence of 99 hours, and the routine is 106 hours a year that begins when the plan ends.

Figure 11.1 sets out the plan of ninety days, its three gates and its hours, the routine that follows, and the readings one year later.

Figure 11.1 — Ninety days, three gates. 99 hours and $22,140 engaged, then 106 hours a year of routine; one year later, readings that show control kept, with nothing credited (posed).

The table below sets the three gates beside their day and the condition that passes each. The conditions are written before day 1 and read against records, and a gate that is not met is read again 7 days later while nothing new starts. Read it as the spine of the plan: every task of the three slices exists to make one of these conditions true.

Table 11.2 — The three gates of the ninety days

The table below sets the hours of each slice beside each person. The figures are posed by this book and illustrative, and no hour is a norm. The total of 99 hours, and the $7,140 the hours come to at Book F9's illustrative rates, are given in the sentence after the table.

Table 11.3 — The hours of the plan by slice and by person (posed)

The plan takes 99 hours: 42 hours of Karim Haddad, 52 hours of Laurence Bergeron and 5 hours of the outside lawyer. At Book F9's illustrative rates of $60 an hour for each founder and $300 an hour for the outside lawyer, the hours come to $7,140, and with the developer's fixed fee of $12,000 and the first annual fee of $3,000 the plan engages $22,140, all posed by this book. The rates are an illustrative valuation of time and never a pay, and the two fees are posed by this book and never a market price.

METHOD Running a gate in five steps

First, read the condition of the gate, written before day 1, in the words it was written in. Second, find, for each part of the condition, the record that shows it: the map, the scored grid, the written decision, the lawyer's reading, the pilot's test, the submitted questionnaire, the described interface, the approved listing, the completed assessment, the register with its ceiling, the routine set as tasks. Third, mark each part met or not met, with the day. Fourth, when every part is met, approve the gate and start the next slice, and when a part is missing, name it and read the gate again 7 days later while nothing new starts. Fifth, write what the gate showed and what it did not show, because a gate shows that records exist and never that an integration works. This is the book's reasoning and not a tested procedure, and the case follows these steps at days 30, 60 and 90, posed by this book.

THE RULE A gate is passed by the records its condition names, and a missed gate is read again 7 days later while nothing new starts

The rule is this book's own for the plan, drawn from its reasoning and not from a source. The condition of each gate is written before day 1; a gate is passed only when the records the condition names exist; and a gate that is not met is read again 7 days later while nothing new starts. The rule is neither a standard nor a legal duty, and it promises no result. Its conditions can be written as plan tasks with an observable "Done when" criterion, and the Mark as done button does not verify that criterion, so a second person reads it (La Machine, 2026). The case's gates fall on days 30, 60 and 90, posed by this book, and no figure beyond the case's is printed here. A gate that is met shows that records exist; it never shows that an integration works, that a listing brings customers or that a ceiling has removed a risk.

11.4 Days 1 to 30: The Map, the Grid and the Terms

The first slice builds what the rest of the plan stands on. Nothing is built in these thirty days. What is produced is a map, a scored grid, a written decision, a lawyer's reading of one partner agreement, and a drafted register with a ceiling. The slice takes Karim Haddad 18 hours, Laurence Bergeron 14 hours and the outside lawyer 2 hours, posed by this book.

The map is the count of where the customers actually run their buildings. On day 1, Hydrosentinelle inc. monitors 820 buildings, a figure posed by this book, of which 312 run in the first property-management system, 148 in the second and 360 in other systems or none. The map is drawn by Karim Haddad, the head of sales and operations, and it is the basis of every later choice, because the grid's first criterion is the reach of a candidate over that base. Chapter 2 holds the reading of a platform's incentives, and Chapter 3 holds the map and the grid.

The grid scores each candidate from 1 to 5 on six criteria — reach, value to the customer's own work, effort to build, effort to keep each year, terms and dependence risk, and data and privacy exposure — with weights of 25, 25, 15, 10, 15 and 10, and a total out of 100. The rule is build at 70 or more, queue from 55 to 70, and not now below 55. The three candidates score 77, 68 and 44, all posed by this book: the first property-management system is built now, the second is queued, and the smart-home standard for rental units is not now. The technical assessment of each candidate is made by Laurence Bergeron, the president, product and engineering.

The first platform's partner terms are read by the outside lawyer by day 21. The reading is not a formality: a partner agreement states what the program asks and gives, and its commission, fee, notice period and removal clause are that platform's terms on the day they were read. Whether a given clause is enforceable, and whether a contract of adhesion binds in a given case, is a question for Book H1 (Contracts and Commercial Agreements) and a lawyer, and this book decides neither. The decision is written on day 28 by the two founders: the first candidate is built and the second is queued.

The dependence register is drafted by day 30 with its ceiling. The register lists each platform the business depends on, the revenue, customers, data and operations exposed, the notice its terms give and the way out of each. The ceiling, posed by this book, is that no single platform brings more than 40 percent of the new buildings of any quarter, and that no alert path runs through any platform. Chapter 6 holds the register and the ceiling, and the drafting in this slice is what makes the ceiling a number read against a list rather than an intention.

The table below sets the five tasks of the first slice beside who does them and the day each is due. The hours of the slice are those of its row of Table 11.3, no total of the slice is computed here, and all of it is posed by this book. Read it as the first gate's checklist: each row is a record the gate of day 30 will be read against.

Table 11.4 — Days 1 to 30: the tasks of the first slice

The gate of day 30 is read against the records of its condition: the map, the scored grid, the lawyer's reading, the written decision and the drafted register with its ceiling. If any of the five is missing, the gate is read again 7 days later and nothing new starts. A gate that is met shows that the five records exist; it does not show that the first integration will work, that the customers will use it or that the ceiling will hold.

WHO DOES THIS Karim Haddad and Laurence Bergeron share the three slices, and the outside lawyer works 2 hours in days 1 to 30 and 3 hours in days 61 to 90

The roles below are the case's, posed by this book. Karim Haddad, the head of sales and operations, holds the map, the reading of the terms, the register and the listing, 42 hours in all. Laurence Bergeron, the president, product and engineering, holds the technical assessment of each candidate, the alert event and its work order, the public interface, the security questionnaire and the privacy impact assessment, 52 hours in all. The outside lawyer reads the partner terms and drafts the terms of use of the public interface, 5 hours in all. The outside integration developer builds the first integration under a fixed fee posed by this book. The largest customer's operations manager, a role, receives the work orders in the pilot. No one is hired. In general, one person holds each gate with a named backup, which is this book's suggestion and not part of the case. In a solo business the owner holds every slice and engages a developer and a lawyer for named jobs. No hour and no amount is promised to a reader.

11.5 Days 31 to 60: The First Integration and the Public Interface

The second slice builds and tests the first integration, and it describes the first version of the company's own interface. The slice takes Karim Haddad 10 hours, Laurence Bergeron 26 hours and the outside lawyer 0 hours, posed by this book.

The first integration is built by the outside integration developer, a provider of the bench of Book I8 (Freelancers, Agencies and Outsourcing), under a fixed fee of $12,000 posed by this book. The acceptance criterion is written by Laurence Bergeron, and it is written before the build starts, because a criterion written after a build describes what was built rather than what was needed. The integration sends the alert event of a building whose manager enabled it to the first property-management system, where it opens one work order. The event carries the building, the unit label, the sensor's location, the time and the severity, and no tenant's name. Each event has an identifier, and a repeated delivery never opens a second work order.

The pilot is live on the largest customer's fourteen buildings on day 52. The largest customer is a property management company with fourteen buildings, printed by Book G8 (Business Insurance and Risk Financing), and its operations manager, a role, receives the work orders. The alert event and its work order are tested in the pilot. The alert path itself runs through no platform, and the work order is a convenience that may fail without silencing an alert. The signed event and its identifier are the design of Chapter 7, and the signature is HMAC-SHA256 over the identifier, the timestamp and the body.

The security questionnaire of the first platform's partner program is answered by Laurence Bergeron and submitted on day 58. Security is Book K3's (Cybersecurity, Backups and Business Continuity), and the connections between tools are Book K8's (No-Code, Low-Code and Integrations); this chapter cites both and describes neither. The questionnaire is a record the gate of day 60 will be read against, and answering it is a task with a day rather than a state of mind.

The public interface is described in its first version on day 60. Version 1 is read access to buildings, sensors and alerts, two events, client credentials for each approved integrator, a limit of 120 requests a minute for each integrator, a sandbox and written terms of use. Chapter 5 holds the opening of one's own interface, and Chapter 7 holds the data and identity architecture behind it.

The table below sets the four tasks of the second slice beside who does them and the day each is due. All of it is posed by this book. Read it as the second gate's checklist: the build, the pilot, the questionnaire and the described interface are the four records the gate of day 60 will be read against.

Table 11.5 — Days 31 to 60: the tasks of the second slice

The gate of day 60 is read against the records of its condition: the pilot live on the fourteen buildings, the tested alert event and its work order, the submitted questionnaire and the described interface. If any of the four is missing, the gate is read again 7 days later and nothing new starts. A gate that is met shows that the four records exist; it does not show that the integration will keep working, that the customers will enable it or that the interface will be used.

TOOLS OF THE TRADE What any record of a gate must offer, whatever it is called

Seven functions carry a gate, and a business should look for them rather than for a product. The first is a list of the conditions of each gate, each with a status. The second is a date for each condition and a person who owns it. The third is a link to the record that shows the condition met, so that the gate is read against a document and not against a memory. The fourth is a place to write the decision and what the gate did not show. The fifth is a read-again date that falls 7 days later when a part of the condition is missing. The sixth is a history that cannot be rewritten, so that a gate read twice shows both readings. The seventh is an export in a form another tool can read, because the records of a gate will be read somewhere else. No brand name belongs on this list and no price; the requirement is the function, and a business chooses by function.

11.6 Days 61 to 90: The Listing, the Register and the Routine

The third slice puts the company in front of others and sets the routine that will run after the plan ends. It is the slice in which the register and the ceiling stop being a draft. The slice takes Karim Haddad 14 hours, Laurence Bergeron 12 hours and the outside lawyer 3 hours, posed by this book.

Two integrators are approved on the public interface, on days 75 and 88, under written terms of use drafted by the outside lawyer. The terms of use are what make the interface governed rather than merely open. The approval of an integrator is a decision with a date, and the case approves two by day 90 and four by day 365, all posed by this book.

The listing is approved on day 84. Selling on a marketplace and in an app store is Book F5's (Marketplaces: Selling Through Distributor, Retailer and App Marketplaces), and the partner program is Book F9's (Building and Running a Partner Program); this chapter cites both and describes neither. The listing is a record the gate of day 90 will be read against, and no source read measures what a listing brings. The case's mobile application is free and nothing is sold inside it, and the company pays no store commission and no share of its subscriptions.

The privacy impact assessment is completed on day 86 by Laurence Bergeron. Personal information is Book H2's (Privacy and Personal Information), and this chapter cites it and describes neither the assessment nor the rules behind it. The assessment is a step the business owes itself before personal information moves, and it is one of the ten mistakes of section 11.2 to send personal information to third-party software with no assessment.

The dependence register is kept with its ceiling, and the routine of Chapter 8 is set as plan tasks with a verification criterion. The register is not a document written once; it is a list read against its ceiling each quarter, and the ceiling of 40 percent of the new buildings of any quarter is the case's own, posed by this book. The routine is 106 hours a year, posed by this book, and it is never added to the 99 hours of the plan. The plan tasks of one worked example of a business platform are described in section 11.2 only, and the case does not use that platform.

The table below sets the five tasks of the third slice beside who does them and the day each is due. All of it is posed by this book. Read it as the third gate's checklist: the approved listing, the two approved integrators, the completed assessment, the kept register and the set routine are the records the gate of day 90 will be read against.

Table 11.6 — Days 61 to 90: the tasks of the third slice

The gate of day 90 is read against the records of its condition: the approved listing, the two approved integrators under written terms of use, the completed assessment, the kept register with its ceiling and the routine set as tasks with a verification criterion. If any of the five is missing, the gate is read again 7 days later and nothing new starts. A gate that is met shows that the five records exist; it does not show that the listing will bring an inquiry, that an integrator will build anything or that the ceiling will hold through a busy quarter.

QUÉBEC & CANADA NOTE The competition statute, the contract rules and the privacy Act are called to Books H4, H1 and H2, and a rule of the European Union is a rule of another jurisdiction

The Canadian point of this section is where the rules live. The competition statute is called to Book H4 (Consumer Protection, Advertising Law, Competition and Language Requirements), the rules on contracts of adhesion to Book H1 (Contracts and Commercial Agreements) and a lawyer, and the Québec private-sector Act on personal information to Book H2 (Privacy and Personal Information), in one sentence each. The privacy impact assessment of the case is completed on day 86, posed by this book, and sending personal information to third-party software with no assessment is one of the ten mistakes of section 11.2. The two European regulations are rules of another jurisdiction and never a right or a duty of a business in Québec or Canada. Only the Tribunal or a court decides whether a platform abuses a dominant position or imposes an abusive clause, and this book concludes neither. This book explains published rules and recommends no vendor; a business with a question about its own agreement, listing or data flow should ask an adviser, and nothing here says whether the reader's own arrangement complies.

11.7 The Few Readings That Show Control Kept

A business that has plugged into ecosystems needs a small number of readings that show whether it still holds the choices it meant to keep. Six readings are enough, and each of them is a count or a date. None of them is a score, none of them is a feeling, and none of them is a rate that any source read calls typical. The readings are the book's reasoning, and the case's readings are posed by this book.

The first reading is the share of the new buildings of a quarter that came after an inquiry from a platform, read against the ceiling. It is the reading that shows whether the ceiling is holding, and it is read as a share of new buildings and never as a share of revenue. The second is the duplicate work orders. It is the reading that shows whether the identifier on each event is doing its work, and a count of zero is the count a business wants to see. The third is the notices of change read and the days of notice left. It is the reading that shows whether the weekly watch of terms is actually running, and it is read as a date rather than as an impression.

The fourth reading is the alerts that came late. It is the reading that shows whether the critical path is still outside every platform. The fifth is the integrators, the keys rotated and the integrators removed. It is the reading that shows whether the public interface is governed, because an interface whose keys are never rotated and whose integrators are never removed is an interface that is open rather than governed. The sixth is the date of the last reading of each platform's terms and the date of the next renewal of the security review. It is the reading that shows whether the yearly upkeep is being done, and it is a date rather than a count.

The table below sets the six readings beside the count or the date a leader reads and the question to ask. No reading on it is a score and none is a feeling, and no frequency of any reading in any business is printed. Read it as the short list a leader keeps in view: each row is a count or a date, and each row has one question attached to it.

Table 11.7 — Six readings that show control kept

The case's readings of day 365 are given in section 11.9, in one sentence each, and they are entirely posed by this book. No source is read for this section, because no source read measures how many readings a business should keep or what a reading returns. A business that keeps these six readings and nothing else has a short list that shows whether the choices of the plan are still the choices of the business.

11.8 Keeping the Practice Alive

The plan ends on day 90, and the practice does not. What runs after day 90 is the routine of Chapter 8, which takes 106 hours a year, posed by this book, and which is never added to the 99 hours of the plan. The routine carries the annual fee of the first platform's partner program, $3,000 posed by this book, and it is the part of the work that keeps the records of the plan true.

The weekly watch reads the terms and the fees of each platform. It is the line that catches a change of terms, a change of fee or a change of policy while there is still notice left to act on, and it is the line that read the announced rise of the annual fee from $3,000 to $3,600 with 60 days' notice in the case, posed by this book. The quarterly reviews read the register against its ceiling, and they read the public interface and its integrators. The yearly reset rescores the integration roadmap, because a candidate that scored 68 and was queued may score differently a year later, and because a platform that was not worth building on may have become worth building on, or the reverse.

The rules of law and the pages of platforms are read again on a set date, and the state of any of them after the date it was read is not stated by this book. A platform's terms are that platform's terms on the day they were read, and a rule read at a consolidation is read at that consolidation. The book's own sentence is read again once a year: plug into the systems the customers run, read the terms the day you sign, open small, keep the critical paths outside any platform, and measure dependence against a ceiling. Reading it again is not a ritual; it is the check that the business still holds the choices it made.

When the practice slips, the remedy is small and it is written down. The missed task is done on the next working day rather than folded into the next cycle. The miss is written down with its reason, because a miss that is not recorded may be repeated. The cause of the miss is found, and it is read as a fact about the system rather than as a person's fault. And where the miss belongs to the plan, the gate is read again 7 days later, and nothing new starts until it passes. The routine of Chapter 8 holds the work after day 90, and this chapter adds nothing to it.

DO THE MATH The 99 hours of the plan and the $22,140 it engages, line by line

Illustrative figures; the case is fictional. Step 1 — Karim Haddad works 18 hours in days 1 to 30, 10 in days 31 to 60 and 14 in days 61 to 90, which is 42 hours. Step 2 — Laurence Bergeron works 14, 26 and 12 hours, which is 52 hours. Step 3 — the outside lawyer works 2, 0 and 3 hours, which is 5 hours. Step 4 — the plan takes 42 plus 52 plus 5, which is 99 hours, and at Book F9's illustrative rates of $60 an hour for each founder and $300 an hour for the outside lawyer the hours come to $2,520, $3,120 and $1,500, which is $7,140. Step 5 — with the developer's fixed fee of $12,000 and the first annual fee of $3,000, the plan engages $22,140. The hours and the two fees are posed by this book, the rates are illustrative and never a pay, nothing is credited to the plan, and the sums are exact.

11.9 The Case, One Year Later

Day 365 of this book is entirely posed by this book, and nothing in it is measured and nothing in it is credited to the plan, to an integration, to the listing or to the interface. What follows is a set of readings, and each reading is a count or a date.

The listing received 52 inquiries, and 11 accounts with 34 buildings signed after an inquiry. That is 17.9 percent of the 190 new buildings of the year, and 22.0 percent in the busiest quarter, where 9 of 41 new buildings came after an inquiry. Both shares are under the ceiling of 40 percent, and both are shares of new buildings that came after an inquiry from the listing; nothing says that the listing caused those signatures. Nine accounts enabled the integration, for 176 buildings.

The alert path held. Of 1,240 alert events relayed, 1,231 went on the first attempt and 9 after retries, with 0 duplicate work orders. The first platform was down for more than six hours on 2 occasions, and no alert was late, because the alert path does not run through it. The first platform announced that its annual fee would rise from $3,000 to $3,600 with 60 days' notice, and the weekly watch read it the week it arrived. Four integrators use the public interface, 1 key was rotated and 0 integrator was removed. One update of the mobile application was rejected by a store's review and fixed in 3 days. The company closes the year with 940 buildings, after 190 new and 70 lost.

The table below sets the readings of the case on day 365 beside what each shows. Every line is posed by this book, nothing is measured, and no result of the business is credited to the plan, to an integration, to the listing or to the interface. Read it as a set of counts and dates rather than as a result: each row shows that a record exists or that a count is where the business wanted it, and none of them shows that anything caused anything.

Table 11.8 — The case on day 365, entirely posed by this book

The chapter ends the book here, and it ends it where the work continues rather than where it stops. What carries the work after day 90 is the routine of Chapter 8: the weekly watch of terms, fees and policies, the monthly reading of integration health, the quarterly review with each platform partner, the quarterly review of the public interface and its integrators, the yearly reset of the integration roadmap, and the yearly upkeep of the first integration. The plan of this chapter puts the records in place; the routine of Chapter 8 keeps them true.

WHAT CHANGED The application copy was read on October 15, 2026, and the plan is read again at each gate

The application code of one worked example of a business platform was read at its copy of September 7, 2026, on October 15, 2026 (La Machine, 2026). In that copy the monthly health reading of Chapter 8 can live as a recurring plan task whose "Done when" criterion the Mark as done button does not verify, so a second person reads it. Every reading of a rule or of a platform's terms is in the chapter that holds it, and this chapter assembles them and adds no rule. None of these dates is a date of the case, which is counted in days: day 1 of this book is day 366 of Book G8 (Business Insurance and Risk Financing), day 731 of Book G7's count and day 1,096 of Book I8's count. The update that a store's review rejected on day 365 belongs to the readings of section 11.9 and never to this box. A reader checks every page and every term on the reader's own date and reads the plan again at each gate, on days 30, 60 and 90.

CASE IN POINT Hydrosentinelle inc. passes three gates in ninety days and keeps its alerts outside every platform

Hydrosentinelle inc. is a fictional business created for this encyclopedia; its founders, its employees, its customers, its partners, its figures and the events described are invented, and any resemblance to a real business is coincidental. In ninety days the company draws the map of the platforms around its customers, scores three candidates on one grid, builds the first integration under a fixed fee, describes a first public interface, gets its listing approved, completes its privacy impact assessment, keeps its dependence register with a ceiling of 40 percent and sets its routine, for 99 hours and $22,140 engaged, all posed by this book. On day 365 the readings are posed and nothing is credited to the plan, to an integration, to the listing or to the interface. The alert path runs through no platform, and the work order in the first property-management system and the mobile application are conveniences that may fail without silencing an alert. All of it is illustrative and none of it is a forecast.

Costly Mistakes

• Routing the alert path through a platform. The most important promise of the business is then governed by a contract the business does not control, and the alert goes by text message and by email directly.
• Signing terms without reading them. A commission, a fee, a notice period or a removal clause is accepted unseen, and a lawyer's reading comes before the acceptance.
• Counting a sale as won because of the listing. An association between a listing and the signatures that follow it is not a cause, and the case says that its accounts came after an inquiry and that nothing says the listing caused the signatures.
• Letting a platform pass the ceiling. A ceiling written once the dependence is already there is a description rather than a limit, and the register has to exist before the ceiling can be read against it.
• Opening an interface with no terms of use and no limits. An interface without written terms has no way to remove an integrator, no way to rotate a key and no ceiling on use, and it is open rather than governed.
• Forgetting the yearly upkeep of an integration. An integration ages with every version of the platform and every renewal of a security review, and the upkeep is a dated task rather than an intention.
• Sending personal information to third-party software with no assessment. The privacy impact assessment is a step the business owes itself before the data moves, and Book H2 holds the rules.

Key Takeaways

• The book rests on one sentence: a business gains from a platform when it plugs into the systems its customers already run, reads the terms of each platform on the day it signs, opens its own interface small, signed and governed, keeps every critical path — above all its alerts — outside any platform, and measures its dependence against a ceiling it set in advance, without promising a gain that it cannot prove.
• The ten most costly mistakes run from plugging into the loudest platform instead of the customer's system to confusing a rule of the European Union with a right of the reader, and Table 11.1 sets each beside why it costs and the chapter that treats it.
• The plan of ninety days is the book's own method, posed by this book and illustrative: three slices of thirty days, a gate on days 30, 60 and 90, a condition written before day 1, and a rule that a gate which is not met is read again 7 days later while nothing new starts.
• The plan takes 99 hours — 42 hours of Karim Haddad, 52 hours of Laurence Bergeron and 5 hours of the outside lawyer — which is $7,140 at Book F9's illustrative rates, and with the developer's fixed fee of $12,000 and the first annual fee of $3,000 it engages $22,140, all posed by this book and never a norm.
• Six readings show control kept: the share of the new buildings of a quarter that came after an inquiry, read against the ceiling; the duplicate work orders; the notices of change read and the days of notice left; the alerts that came late; the integrators, the keys rotated and the integrators removed; and the dates of the last reading of each platform's terms and of the next renewal of the security review.
• The routine of Chapter 8 takes 106 hours a year, posed by this book, and it is never added to the 99 hours of the plan; day 365 of the case is entirely posed by this book, and nothing in it is measured or credited to the plan, to an integration, to the listing or to the interface.

Your Action Plan

1. Write the condition of each gate before day 1. Write the three conditions of days 30, 60 and 90 in the words they will be read in, name the record that will show each part, and write the rule that a gate which is not met is read again 7 days later while nothing new starts. Deliverable: a written list of the three gates with their conditions and their records. Verification: every part of every condition names a record that a second person could open.
2. Draw the map and score the candidates on one grid. Count where the customers actually run their buildings, their accounts or their work, score each candidate from 1 to 5 on the six criteria of the grid, and apply the rule of build at 70 or more, queue from 55 to 70 and not now below 55. Deliverable: a written map and a scored grid with a verdict for each candidate. Verification: every score is written with its reason, and the decision names the candidate that is built and the one that is queued.
3. Have the first platform's partner terms read and write the decision. Have the partner terms of the first candidate read by a lawyer, write the decision on the day the reading is done, and draft the dependence register with its ceiling before the slice ends. Deliverable: a written reading, a written decision and a drafted register with a ceiling. Verification: the decision names the candidate that is built and the one that is queued, and the register names the notice and the way out of each platform.
4. Build the first integration against a criterion written before the build, and describe the first version of the interface. Write the acceptance criterion before the build starts, put the integration live in a pilot on the largest customer's buildings, test the alert event and its work order, submit the security questionnaire, and describe version 1 of the public interface. Deliverable: a live pilot, a tested event, a submitted questionnaire and a described interface. Verification: the alert path runs through no platform, and each event carries a signature and an identifier.
5. Approve the integrators, get the listing, complete the assessment and set the routine. Approve the integrators under written terms of use, get the listing approved, complete the privacy impact assessment, keep the register with its ceiling, and set the routine of Chapter 8 as tasks with a verification criterion. Deliverable: a set of records for the gate of day 90 and a routine set as tasks. Verification: each record exists on the day the gate is read, and each routine task carries a criterion a second person can check.

In La Machine

In the application copy of September 7, 2026, read on October 15, 2026, the routine of the plan can live in Control center → Plan tasks (/taches) as recurring tasks with a "Done when" criterion that is required when the task is created, and the Mark as done button does not verify that criterion, so a second person reads it (La Machine, 2026). Control center → Tools (inventory) (/outils) lists tools with a measured version, a location and a date, and it can serve as a model for an inventory of the dominant offers a business depends on. Check it in your installation.

What a business needs elsewhere is the rest of the work. La Machine keeps no register of dependence on platforms and measures no exposure, no revenue and no share of customers; it watches no platform's terms; it tracks no certification and no security review; and it holds no record of a gate. A register of dependence with a ceiling and an owner for each platform, a watch of the platforms' terms, and a record of each gate are chosen by function, and Chapter 10 gives the functions to look for. La Machine is described and never sold, and the case does not use it.

Self-Check

1. What are the six priorities that carry the book, and what is the book's own sentence?
2. What are the ten most costly mistakes, and why does counting a sale as won because of the listing belong on the list?
3. What are the three slices of the plan, what does each produce, and what happens when a gate is not met?
4. What does the plan take in hours and in money, and what is the difference between the plan and the routine?
5. What are the six readings that show control kept, and what does a met gate show and not show?

Answers. 1. The six priorities are to plug into the systems the customers already run, to read the terms of each platform on the day of signing, to keep every critical path outside any platform, to open the company's own interface small, signed and governed, to measure dependence against a ceiling set in advance, and to keep a small routine without promising a gain that cannot be proved; the book's sentence joins them in one line. 2. The ten mistakes run from plugging into the loudest platform instead of the customer's system to confusing a rule of the European Union with a right of the reader, and Table 11.1 sets them out; counting a sale as won because of the listing belongs on the list because it turns an association into a cause, and the studies read are associations in their own samples. 3. Days 1 to 30 produce the map, the scored grid, the lawyer's reading, the written decision and the drafted register; days 31 to 60 produce the pilot, the tested alert event, the submitted questionnaire and the described interface; days 61 to 90 produce the approved listing, two approved integrators, the completed assessment, the kept register and the routine set as tasks; a gate that is not met is read again 7 days later, and nothing new starts until it passes. 4. The plan takes 99 hours and engages $22,140, posed by this book: 42 hours of Karim Haddad, 52 of Laurence Bergeron and 5 of the outside lawyer, which is $7,140 at Book F9's illustrative rates, plus the developer's fixed fee of $12,000 and the first annual fee of $3,000; the plan is a one-time sequence of ninety days, and the routine of Chapter 8 is 106 hours a year that begins when the plan ends and is never added to it. 5. The six readings are the share of new buildings that came after an inquiry, the duplicate work orders, the notices of change and the days of notice left, the alerts that came late, the integrators and their keys, and the dates of the last reading of each platform's terms and of the next renewal of the security review; a met gate shows that the records its condition names exist, and it never shows that an integration works, that a listing brings customers or that a ceiling has removed a risk.

Chapter References

La Machine. (2026). Documentation — route reference inventory. Internal product documentation, read October 15, 2026, together with the code of the pages this book describes: /taches and /outils.