Shared infrastructure, in a software studio, means building the foundations every product needs once and letting each product use them, instead of rebuilding sign-in, billing, email and hosting from scratch every time. It is the main reason a small team can keep several live products running at once. It is also easy to overdo. This post sets out what we share across the studio, what we deliberately keep separate, and how we decide which side of the line something falls on.
It picks up a thread from running several products with a small team, where we said the biggest reason we can run a portfolio is that we build the plumbing once. Here is what that looks like in a bit more detail.
What does a studio actually share?
We share the parts that every product needs and no customer chooses a product for. Nobody picks a wedding RSVP tool or a CRM because of how its password reset works, but every product needs one that works well. Those are the pieces worth building once:
- Accounts and sign-in. Registration, login, password resets and the security around them.
- Billing. Plans, trials, invoices and what happens when a card fails.
- Sending email and messages. The plumbing that gets confirmations, reminders and receipts to the right inbox or phone.
- Hosting, backups and monitoring. Where the products run, how they are backed up and how we find out when something goes wrong.
- Admin and support tools. The screens we use behind the scenes to help a customer, check an account or fix a record.
Each of these is work that would otherwise be multiplied by the number of products. Done once, it is a single job to maintain and improve.
What do we deliberately keep separate?
We keep separate anything that makes a product what it is, and anything where one customer's data must never touch another's. In practice that means three things.
The product experience
Each product has its own look, voice and way of working. Unavoidable CRM is built for busy service businesses who want calls answered and invoices chased. Aisle Reply speaks to couples planning a wedding. Forcing those into one shared design would make both worse. The foundations underneath can be common. What the customer sees and feels should not be.
Customer data
Data belongs to the customer and the product they signed up for. Shared infrastructure does not mean a shared pot of data. Every product keeps its customers' information apart, and access is limited to what each product needs. This matters even more for a product like Unavoidably Secure, where the customers are themselves careful about how information is handled.
The things customers pay for directly
Where a customer is paying for usage, such as text messages or call minutes, we would rather they hold that account themselves and see the bill directly than have it hidden inside ours. It keeps the pricing honest and stops us becoming a middleman for costs we do not control.
How do we decide whether to share something?
We ask whether at least two products need it now, whether it works the same way in each of them, and whether a customer would ever notice or care that it is shared. If the answer to all three is yes, it goes into the shared platform. If any answer is no, it stays inside the product until the case is clear.
The second question catches most mistakes. Two products might both need "notifications", but if one sends a wedding reminder a week before the RSVP deadline and the other sends an urgent alert about a missed call, the rules around them are different. Sharing the sending is sensible. Sharing the logic behind it usually is not.
Why we wait for the second product
It is tempting to design shared foundations before anyone needs them. We try to resist that. Building something general for one product means guessing what the others will need, and those guesses tend to be wrong. Building it for real once, then pulling it out into the shared platform when the second product needs the same thing, gives us something that has already been tested by a real customer.
What are the risks of sharing too much?
The main risk is that one change can affect every product at once. A mistake in shared sign-in is a mistake in every product's sign-in. We handle that by treating shared code more carefully than product code: more testing, smaller changes and gradual rollouts, so a problem shows up in one place before it reaches all of them.
The second risk is slower, and it is about ownership. When something belongs to everyone, it can end up belonging to nobody. We make sure each shared piece has someone responsible for it, with short written notes on how it works and what usually goes wrong, so it is never a mystery when it needs attention.
The third risk is that shared foundations start to shape the products instead of serving them. If a product idea is rejected because "the platform does not do that", something has gone wrong. The platform should bend to the products, not the other way round.
What would we tell another small studio?
Share the boring, essential parts that every product needs and no customer notices. Keep the product experience, customer data and usage costs separate. Wait until a second product needs something before you generalise it. And treat anything shared with more care than anything else, because its mistakes travel furthest.
You can see the products this approach supports on our portfolio page, and read more about how the studio model works in what a venture studio actually does. If you run a small multi-product team and want to compare notes, get in touch through our contact page.
Follow along as we build
We publish these notes as we ship, learn and change our minds. Browse the rest of the blog to see how the studio is run in the open.
Read more from the blog →