Bending Spoons is the most interesting software company in Italy and most people using their apps have never heard of them. The story everyone tells is the acquisitions: Evernote, WeTransfer, Meetup. That is the visible part. The part that actually does the work is what happens after they buy something, which is that the app gets moved onto the same shared platform as everything else they own.

The acquired app keeps its product team and its roadmap. What it stops doing is maintaining its own plumbing. Sign-in, payments, infrastructure, analytics, growth machinery, support tooling: built once, centrally, used by everything. When the platform improves, every app in the portfolio improves the same day, and none of those teams did anything.

I do not buy companies. But I run more products than a person my size has any business running, and the only reason that is possible is that I made the same structural choice they did.

The marginal cost of the next product

Here is the thing nobody tells you about running several small products at once. The hard part is not building product number two. It is that product number two arrives with a full set of obligations that have nothing to do with what it does.

It needs accounts and a login. It needs somewhere for errors to go. It needs uptime monitoring, because you will not notice it is down otherwise. It needs a deploy pipeline. It needs transactional email that actually arrives. It needs analytics, a privacy policy, a support channel, a changelog. None of that is the product. All of it has to exist anyway, and all of it has to keep existing forever.

If every product carries its own copy of that, the marginal cost of the next one is enormous, and you top out at two or three before maintenance eats the whole week. If they share one copy, the marginal cost collapses to roughly the cost of the actual product idea. That is the difference between a portfolio and a graveyard.

So none of my products own their plumbing. Not one of them has its own login system, its own error tracking, its own deploy pipeline, its own uptime monitoring, its own email infrastructure, its own design system. There is one of each, and everything runs on it.

What "the platform" actually is

Here is the whole inventory, because the abstraction is a lot less interesting than the list.

Identity and access

  • Single sign-on across every product and every internal tool
  • A passkey-first identity provider for the places where a hardware key beats a password

Staying up

  • Error tracking, Sentry compatible, wired into every app
  • Uptime monitoring across the public surface
  • Server metrics for every host
  • Heartbeat monitoring for background jobs and cron
  • Automated QA: end-to-end tests generated and run against real headless browsers on a schedule
  • A cross-product health scoreboard that rolls all of the above into one view

Shipping

  • A deploy tool that watches repos and ships over SSH when they change
  • A shared code layer required directly by every product: sessions, auth, mail
  • A design system that every front end links to
  • A shared headless browser pool for QA, screenshots and scraping

Understanding what happens

  • Product analytics on every front end
  • An A/B testing platform for running experiments across products
  • BI and ad-hoc SQL over the warehouse
  • A first-party data collection API

Talking to users

  • Transactional and broadcast email with delivery observability on top
  • A support dashboard
  • An embeddable support chat widget
  • A public feedback and feature request board
  • Embeddable changelog widgets and public changelog pages
  • A multi-tenant blogging platform, which this post is running on
  • Referral campaigns with click and conversion tracking
  • Programmatic social and OG image generation
  • A link shortener
  • A social scheduler

Staying legal

  • Centralised cookie consent and privacy policy generation, embeddable into every front end

Automation and AI

  • Agent orchestration: a set of agents doing standing background work across all of it, watching pipelines, drafting, running research passes, and reporting when something drifts
  • A single LLM gateway that every app and job calls through, with model routing, failover and per-key spend tracking
  • Workflow automation for the glue nobody wants living in a repo
  • A central proxy router that everything egresses through

Running the company

  • Internal chat, which is where every monitor alerts
  • Project management and task tracking
  • Forms and surveys
  • E-signature
  • A whiteboard, a pastebin, a password manager
  • Finance and CRM
  • A single chronological event stream of everything happening across the company

Almost none of that is exotic. Any competent software company has all of it. The only decision that matters is whether each product pays for it separately or once.

The compounding is the actual payoff

The economics get you to a portfolio. The compounding is why you stay.

Last week I wrote a monitor that probes every internal service on a fifteen minute cycle and alerts when one stops answering. It took an afternoon. Every product I run got monitoring that day, and I did not touch a single product to do it. The next product I launch will have it before it has a landing page.

That is the shape of every improvement in a shared layer. You do the work once, at the platform, and it lands everywhere at once, including in the things you have not built yet. Do that for a few years and the baseline quality of a brand new product is higher than the quality of a mature product built the other way.

The part that is not free

Shared plumbing has a blast radius. A change to the shared layer ships to everything simultaneously, and that includes your mistakes. There is no staged rollout across products, because there are no separate copies to stage. You get the compounding in both directions.

The subtler failure is that a shared platform rots quietly, and it rots in a way that is very hard to see. I found a good example of this in my own system a few days ago. I keep a catalogue of the internal tooling, the thing that lists what exists and where it lives. Every single URL in it was stale. They all pointed at hostnames that had been redirecting elsewhere for months. Worse, the job that health-checked those services had depended on a piece of infrastructure I decommissioned in June, so it had been exiting immediately ever since. Every service in the catalogue had been sitting on a status last written three months earlier, and nothing anywhere said so. The dashboard was green because nothing was updating it.

That is the characteristic shared-platform failure. Not a loud outage, but a slow drift where the thing that is supposed to tell you the truth quietly stops running and the silence reads as good news. If you centralise, you have to monitor the monitoring, and you have to periodically go and check that the checks are real.

It does not make the products good

The last thing worth saying is the limit of all this. A shared platform is entirely uninterested in whether your product is any good.

One of my products aggregates tax lien auction data from across the United States. Property taxes there are administered across roughly 3,000 separate jurisdictions, each with its own calendar, its own format, its own website, and no national feed of any kind. Untangling that is slow, specific, deeply unglamorous work, and no amount of shared infrastructure does one minute of it for me.

That is the whole trade, and it is the same one Bending Spoons makes at a vastly larger scale. Centralise everything that is not the product, so that the only thing left to think about is the product. The platform does not give you good ideas. It just makes sure that having one is enough.