The Secret Plan for Pizza4People

The Company Left. The Pizza Stayed.

On 4 March 2026, Just Eat announced that it intended to leave Denmark. On 14 April it confirmed that its Danish operations would end on 30 April, after twenty-five years in the country. It even arranged a marketing agreement that would offer customers a route to Uber Eats. None of this is evidence that Denmark suddenly forgot how to order dinner. The restaurants were still there, the customers were still hungry, and, as far as I could tell, the mozzarella continued to melt. What disappeared was one company's willingness to keep providing a particular connection between them. Companies should be free to enter and leave markets. I just wondered why the connection had to leave with them. Source: Just Eat Takeaway.com, 4 March and 14 April 2026.

It was excellent timing for an experiment. Pizza is familiar, the transaction is comprehensible, and just about everybody can picture both sides without needing a lecture in economics. I started building Pizza4People. The obvious approach would have been to make another ordering application, promise lower fees and try to win users from Wolt. There is nothing inherently wrong with that business, except that it would leave the question I actually cared about unanswered. If a restaurant escaped one software company only to depend permanently on my software company, what had changed beyond the logo? So I wrote down the first part of the plan. It was not a plan for an app.

The Secret Plan — So Far

  1. Make the connection open.

A Phone Book, Not a Landlord

Pizza4People is supposed to be a protocol. A restaurant controls a digital node that can announce itself to one or more registries. A customer uses a compatible client to discover the node, retrieve the menu directly from it and submit an order directly to it. The registry helps people find a restaurant; it should not have to hold the order, process its payment or own the relationship. There can be many clients, many registries and many implementations of the same published contract. My reference software is not the protocol any more than a particular email provider is the entirety of email. If I stop operating my registry tomorrow, the network should be able to keep working through other registries. If it cannot, I have merely hidden a platform inside a phone book.

A restaurant may prefer to buy everything from one supplier: hosting, menu editor, payments, kitchen display, technical support and a lovely dashboard with graphs. Good. The point is not to force the restaurant owner to become a systems engineer. It is that the owner should be able to leave that supplier without losing the restaurant's network identity. The current public P4P repository contains an alpha specification, reference implementations, direct discovery and test-order proof, and prototype work on signed node identity, root keys, delegated operational keys and revocation. What it does not yet prove is effortless migration of menus, order histories and every business integration. That work is real and still ahead. But the direction is testable: can a restaurant authorise a new software operator, revoke an old one and remain the same restaurant to the rest of the network?

The moment that works, changing software becomes something different from starting over.

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.

The Second Order Has to Be Worth It

A customer is not going to order a pizza to celebrate my architecture. The existing services have spent years making ordering convenient, and Wolt does genuine work connecting customers, restaurants, payments, support and delivery. There is also nothing new about a restaurant selling directly online. Wolt's own Storefront does that through a restaurant's links and QR codes, with Wolt providing payment, support and, where selected, delivery. It advertises low commissions. The useful comparison is therefore not ‘Wolt takes a fee; an open protocol takes zero’. It is the restaurant's all-in cost and retained customer relationship under each realistically available ordering route, including Storefront, ordinary marketplace orders and its existing direct sales. Removing a commission is not a saving if you quietly add even larger costs elsewhere.

A pizzeria does, however, have something that a brand-new marketplace does not: people who already buy its pizza. Its customers see its shop window, receipt, website, counter and takeaway box. A sticker with a QR code can make the next order direct, if there is a reason to scan it. Perhaps it is easier. Perhaps the restaurant shares some of its actual savings. Suppose, as an illustration rather than a claim about any supplier's prices, that one comparable repeat order produces 20 kroner more contribution after all variable channel costs when made through a P4P-compatible direct route. The restaurant gives the customer ten kroner of that as a discount and keeps ten. If setup costs 1,200 kroner and fixed operation another 150 kroner per month, spreading setup over six months requires 350 kroner a month, or 35 such orders. Roughly 1.2 per day. That may turn out too optimistic, too pessimistic or wholly wrong for a particular shop. Good: now there is something a real pilot can measure against Storefront and the restaurant's other actual options. We should not invent Wolt's contractual commission rate to make the arithmetic prettier.

The importance of a restaurant's freedom to offer a direct price is not only theoretical. In August 2026 the Danish Competition Council found that Wolt had abused a dominant position through several contractual terms, including a price-parity clause that had restricted restaurants' freedom to offer lower prices through their own channels in an earlier period. The authority described strong network effects in the Danish market for meal-ordering platforms with delivery and estimated Wolt's share at 70–80 percent during the investigated 2022–2024 period; that is not a figure for the entire pizza market. Wolt told the authority that the parity clause had not been applied in Denmark since 4 December 2025. It would be misleading to describe that restriction as still operating today. But the episode makes one thing hard to dismiss: the route by which someone orders a pizza is part of the market's economics, not merely its user interface. Source: Danish Competition and Consumer Authority, 26 August 2026.

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.

I Told the World. I Forgot to Give Them the Plan.

Now someone has to build good software around the open connection. I would like those companies to make money. Lots of it, if their customers are happy. Restaurants should be able to choose an excellent complete package rather than assembling twenty separate tools to answer one telephone call.

When I made Pizza4People public on 29 April 2026, I did not exactly keep it secret. I sent 26 launch emails to journalists, technologists and people I thought might understand the market. I even wrote directly to Jesper Buch, one of Just Eat's founders. Seven messages bounced. The other nineteen produced no human reply. That silence does not tell me who read the emails or what anybody thought. It tells me something simpler about my own launch: I had explained what I had built and why the connection should be open, but not how restaurants, software providers, installers, printers and customers might create a market around it. I had published the protocol. I had not published the plan.

The distinction still matters to the argument. I do not want Wolt excluded. I want Wolt to compete without possessing exclusive control of the shared connection.

Recently, something rather unexpected happened in the other direction. An established restaurant-software company found the public project and wrote to me, unprompted, about the possibility of interoperability. It was the first serious unsolicited commercial inquiry I had received about Pizza4People. I was delighted. But I was also curious. A supplier may genuinely support connecting outside payment services and still insist that its own software remains indispensable at the centre. The mail does not settle that question. It gives us a sharper one: will a commercial implementation allow a restaurant to leave the entire provider while retaining the identity and basic ordering connection? The answer would tell us more than a hundred agreeable paragraphs about openness.

Imagine Wolt itself ends up supplying half the paid services running around this protocol. It might provide the best delivery, the best reviews or the best package nobody has thought of yet. I would have no objection. Fifty percent of the business voluntarily won is not fifty percent ownership of the rules of participation. A good supplier ought to be allowed to win. The more interesting condition is that it ought to be possible for that supplier to lose.

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.
  4. Let every provider compete — even Wolt.

The Printer Is Not a Law of Physics

There are really two software markets hiding in this proposal. The first is for complete P4P-compatible restaurant systems. They may be proprietary, bundled, beautifully designed and worth every cent they charge. The second is for optional modules: a payment adapter, a kitchen display, an accounting connector, a delivery service, a review system. A P4P-compatible system should meet the core published protocol; it does not follow that every system must accept every imaginable plugin. But where a vendor claims to support a particular interchangeable module interface, we should be able to test that claim. An eventual P4P module marketplace could publish evidence and make good modules easy to find. It must not become the only shop where modules are permitted to exist.

Some modules would come from established businesses. Others might be invented by the people who live with the problem. Why must a kitchen print every order on paper? Perhaps a cook would prefer a headset that reads it aloud, takes a spoken confirmation and falls back to a screen when the restaurant is too noisy. Why must a delivery service have one fixed organisational form? A group of neighbours might build a trusted-circle collection service for selected orders. Independent couriers might organise a cooperative and publish their prices and terms. A reviewer might design a system for recording what was actually verified rather than which platform collected the stars. Each suggestion brings hard questions about privacy, consent, reliability, labour and liability. None of those proposed modules is a promised production feature. But the developers should not have to reproduce an entire marketplace merely to test one function.

Perhaps the start of that experiment is no more glamorous than an open specification, example manifests, contract tests, a workpack and a good AI prompt. AI might reduce the cost of a first implementation, but it does not make a payments or delivery module safe by wishing. Still, a lower cost of trying one small idea could change who gets to participate in the market. A software company can sell the whole package; a courier can experiment with one service. Neither needs to own the protocol.

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.
  4. Let every provider compete — even Wolt.
  5. Let modules become a market of their own.

Seven Trade Unions and a Rubber Duck

The word best becomes awkward once different people are allowed to choose for themselves. Some evenings I am simply hungry and want a pizza without a referendum on my conscience. Other evenings I may care about the courier's working conditions, the privacy of the payment provider or whether the restaurant is a real place I can visit. Perhaps I demand a delivery service approved by seven trade unions and a rubber duck. I cannot imagine the duck's audit being especially rigorous. That is fine. I am making a joke about the extent of personal choice, not proposing duck-based certification.

One client might show the cheapest pickup option; another might let me choose between several delivery arrangements with documented terms. A restaurant may also decide which services it is prepared to work with. Some claims will be verified by independent parties, others will be merely asserted, and some information will be unknown. Those are different states, not labels to be blurred together in the name of a clean user interface. The protocol does not need to determine the morally correct dinner for everybody. It needs to make different options, conditions and sources of evidence usable without making one platform's preferences mandatory. The choice can be simple for the customer who wants simple, and more demanding for the person who wishes to ask questions.

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.
  4. Let every provider compete — even Wolt.
  5. Let modules become a market of their own.
  6. Let people choose what matters to them.

A List That Is Not a Licence

Of course, freedom to choose becomes rather useless if every claim in a restaurant directory can be invented by whoever fills in the form. My proposal is for a Protocols4People umbrella maintaining the shared technical standards and an overarching registry, with independent registries remaining possible. National Pizza4People organisations could operate their own, more carefully curated lists of physical, customer-accessible restaurants. A pizza YouTuber might know the city well enough to investigate a restaurant, but a reviewer's opinion of the crust should not become proof of the restaurant's identity. For each listing, there could be an evidence workpack with dates, sources, an assessment, an appeal path and a clear boundary for material that should not be public. A national panel would be responsible for its list, not for granting permission to exist on the network.

The same separation applies to optional software modules. A future national module shop could show exactly which version passed which compatibility tests, who reviewed it and what the review did not establish. An approved module should not be mistaken for a guarantee against all security failures. Independent directories could list ghost kitchens; other organisations could issue their own assessments. A restaurant removed from Pizza4People Deutschland's curated list would not thereby lose its node identity or become illegal to discover elsewhere. The distinction between this source has reviewed a claim and this source has the power to forbid your participation is the distinction the entire architecture must preserve. The organisations described here are proposed institutions, not entities I am pretending are all up and running.

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.
  4. Let every provider compete — even Wolt.
  5. Let modules become a market of their own.
  6. Let people choose what matters to them.
  7. Make trust verifiable, never compulsory.

Somebody Has to Pay for the Work

The objection here is not philosophical; it is a payroll. Servers cost money. So do software maintenance, security work, field visits, independent reviews, translation, printer ink and the person called when the kitchen screen stops responding. I do not intend to earn a transaction commission from Pizza4People, but that does not make the resources free. A supplier should be allowed to charge restaurants for hosted software and support. A printer can sell optional materials. An installer can be paid for an installation. An organisation can seek grants, donations or voluntary member support for common infrastructure. Commercial participants might fund their own acquisition costs because they expect to win customers. None of those revenue streams proves that a coordinated international launch is financed; at present, it is not.

The guardrail is simple. Paying a company to do valuable work should not purchase exclusive rights to the common protocol, an unearned verification mark or preferred placement in an allegedly neutral list. Funding and governance need disclosure. Workers need real compensation and lawful conditions. The possibility that many different businesses can fund different parts of a shared launch is a mechanism worth investigating, not a budget that materialises because I have drawn enough arrows. But at least it asks a better question than how I personally raise enough money to employ a multinational staff forever: who stands to gain from making one useful part of this network work well?

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.
  4. Let every provider compete — even Wolt.
  5. Let modules become a market of their own.
  6. Let people choose what matters to them.
  7. Make trust verifiable, never compulsory.
  8. Pay for work, not permission.

The Part Where the Plan Stops Being Secret

A functioning protocol, a credible financial offer and an honest directory are still not a market if nobody knows where to find them. This is where my plan stops resembling software development and begins to resemble a small, lawful public action. I do not want to build a global sales department to persuade restaurants one by one. Existing job portals can help recruit local people for paid, defined assignments. Existing printing companies can prepare translated starter packs and QR or NFC materials. Workers can collect the packs from the printers or, where they agree, from participating pizzerias that act as neighbourhood hubs. Local technicians can offer installation and support. Someone must coordinate consent, training, route allocation, complaints and quality control, but the people doing the work do not all need to work for one company.

There is a second half to that mobilisation, and it should happen in the same places. Tell only restaurants and customers will find an empty app. Tell only customers and they will find no restaurants. Pizza YouTubers and other creators already have audiences interested in pizza, but those viewers are not all the same sort of person. Some are hungry customers; others are restaurant owners, owners' children, couriers, developers and people working in printing shops. One video might make someone want a pizza, another person want to build a delivery module, and a third person tell their family restaurant to look into the protocol. That is not a result we can assume. We can give public participants voluntary referral paths and measure which content produced restaurant inquiries, worker applications, installed modules, first orders and repeat orders. Views alone are not the metric.

The plan needs to be public before the coordinated day. People would have time to decide whether it makes sense, argue with the numbers, develop their own compatible software, organise in their own cities or decline. That openness is not a confession of tactical weakness. It is a potential source of capacity: I cannot personally recruit every courier, printer, developer and restaurant owner. But I can publish what each of them would need to participate. A secret plan for an open protocol becomes more useful when it stops being secret.

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.
  4. Let every provider compete — even Wolt.
  5. Let modules become a market of their own.
  6. Let people choose what matters to them.
  7. Make trust verifiable, never compulsory.
  8. Pay for work, not permission.
  9. Publish the plan; mobilise both sides.

One Percent. One Day.

Now comes the number I deliberately left out until the machinery had a reason to exist. I do not want ten thousand disconnected dots scattered around the world. A pizzeria that is the only active node in its neighbourhood will not solve the customer's search problem. The intended launch is a collection of dense local markets, each with enough participating restaurants and customers to make the network worth opening on day one. The global percentage is the sum, not the unit of usefulness. We would need to define a local coverage threshold and measure it in each participating city or district before claiming that a useful market had begun. Otherwise the headline would conceal an empty map.

The operation would have a preparation period, perhaps months or longer. Restaurants could be contacted, give informed consent, have their nodes configured and pass test orders before the day. But they would remain out of public live order availability until the coordinated launch window. During that window, the public clients and registries would begin showing the ready restaurants as live, real customer orders could be accepted, local field teams could deal with the last physical steps, and creators could direct customers toward markets that were genuinely ready. The event is not intended to be a theatrical switch thrown on a network that was already conducting normal trade. It is a test of synchronised supply, discoverability and actual customer use. Activation would be measured as a consented restaurant becoming publicly reachable for live orders in that window, with the order path verified; real orders and repeat behaviour would be reported separately. The window and timezone rule would be fixed publicly in advance, not adjusted afterward to make the target look easier.

The target is one percent of the world's physical pizzerias becoming active through a coordinated one-day launch. I do not yet have a defensible worldwide count of establishments that meet that definition. If, purely for illustration, there were one million, the target would be 10,000 locations. To reach 10,000 with a hypothetical ten-percent conversion rate from qualified approach to consented activation would require 100,000 qualified approaches. At twenty first-contact visits per field-worker day, that is 5,000 worker-days of outreach, largely during preparation rather than magically performed on the launch day. At a hypothetical fully burdened €150 per worker-day, the outreach labour alone would total €750,000, before equipment, printing, recruitment, travel, translation, installation, support, verification, hosting, local administration and failure recovery. Neither the denominator, conversion rate nor daily cost is an observed global average, and the budget is not funded. Every one of those assumptions is open to challenge.

The first requirement is still a real restaurant pilot, and I have not completed it. My intended first kebab restaurant went bankrupt before the experiment could happen, and I failed to replace the contact quickly enough. That is a personal and operational gap, not a detail that disappears when I start multiplying worker-days. We need to prove one restaurant can take actual orders reliably, that a second independent implementation works against the public specification, that switching a provider is possible, and that local customers have a reason to use the resulting channel. After any coordinated launch we would report survival at thirty and ninety days, genuine order rates, customer repeat use, actual restaurant costs and the percentage of supposed activations that failed. A hundred excellent TikTok videos and ten thousand idle QR stickers would not pass those tests.

The Secret Plan — So Far

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.
  4. Let every provider compete — even Wolt.
  5. Let modules become a market of their own.
  6. Let people choose what matters to them.
  7. Make trust verifiable, never compulsory.
  8. Pay for work, not permission.
  9. Publish the plan; mobilise both sides.
  10. Prove one percent in one day — in real local markets.

The Number After One

One percent sounds like a sufficiently unreasonable ending, particularly for somebody who is still working toward his first live restaurant pilot. But it was never the destination. It is an attempt to test whether a distributed market can reach a useful starting density quickly, and whether the resulting network becomes valuable enough to attract people and companies who were not involved in preparing the day. What I want to learn is not merely how fast workers can install something, but whether the network begins to recruit its own next participants. If it only grows when I arrange another international campaign, then the more radical part of the theory has not been demonstrated.

The concealed end goal is one hundred percent. I want the pizza-ordering market, over time, to actually adopt a common open protocol — not simply to be theoretically allowed to use one. I do not mean one hundred percent of pizza orders going to my company, because I do not want a pizza-ordering company. I do not mean one hundred percent of software vendors agreeing to my commercial preferences, or every restaurant joining a national P4P organisation. I mean that, ideally, a pizzeria and its customers can expect a common interoperable path to exist regardless of which software vendor the pizzeria has chosen. Adoption must be voluntary and earned. One hundred percent is a direction, not a prediction or a licence to compel anyone.

Email offers a useful analogy. Gmail, Outlook and many independent mail services can still exchange messages using common technical standards such as SMTP. Their businesses differ. Their interfaces differ. They can compete for customers while speaking a shared language. Email also has spam, lock-in and portability problems of its own, so I do not intend to borrow its halo uncritically. I borrow only the idea that the basic act of reaching someone need not be sold as the exclusive property of the best-known provider. SMTP, RFC 5321. Pizza4People is a first test of that idea in one market. What Protocols4People might eventually investigate beyond it is a different article.

There is one modest complication before all of that. Pizza4People now has a public protocol proof with primary and backup registry discovery, but my first controlled live restaurant pilot is still ahead of me. A real restaurant still has to run a node, receive real pickup orders and prove that backup discovery works when the primary registry is unavailable. The proposed organisations do not yet exist, and nobody has funded that remarkably large first-contact operation. Those are facts, not an invitation to pretend otherwise. The entire plan is an experiment waiting to earn its results.

And despite the years of work this might involve, I don't need to make a single dollar from Pizza4People. I want to walk into a pizzeria I have never contacted, sit down, and notice a little P4P sticker in the window. Someone else printed it. Someone else installed the software. I do not know which company supplies the kitchen system, and nobody there needs to know who I am. I would like to look at that sticker and realise the idea no longer needs me to explain it. Then perhaps someone could bring me a pizza.

The Secret Plan — Complete

  1. Make the connection open.
  2. Let restaurants keep their identity.
  3. Make the second order worth switching.
  4. Let every provider compete — even Wolt.
  5. Let modules become a market of their own.
  6. Let people choose what matters to them.
  7. Make trust verifiable, never compulsory.
  8. Pay for work, not permission.
  9. Publish the plan; mobilise both sides.
  10. Prove one percent in one day — in real local markets.
  11. Aim for universal use, not ownership of the market.