Operating model
How we build.
A repeatable path, so a new product is an extension of the group rather than a fresh gamble.
- 01
Idea tested against a real buyer
We only start when there is a specific person with a specific problem who would pay to have it removed. No product starts from a category.
- 02
Narrow first build
The first version does one job properly. No roadmap theatre, no half-finished modules shipped to look bigger than we are.
- 03
Operate it ourselves
We run our own platforms. Support load, edge cases and unit economics come back to the people who build them.
- 04
Reuse into the next product
Live streaming, scheduling, payments, identity and admin are solved once as reusable patterns, then re-applied. Each product starts further along than the last — on its own isolated deployment.
Shared foundations
What every product inherits.
The reason a small group can run several products at once: most of the hard parts are built once.
Identity and accounts
One approach to users, roles and permissions across products.
Scheduling
Session and booking logic shared by Tour 27 and Tour 27 Together.
Live delivery
Streaming and interaction patterns re-applied to Tour 27 and Fan 27 — each on its own isolated deployment, not a shared production stack.
Commerce
Tickets, memberships and drops on one payment model.
Admin and reporting
A common operator surface rather than one per product.
Design system
The tokens and components this site is built from.
What we don't do
Being clear about the edges.
Saying no to the wrong work is part of why the portfolio stays coherent.
- We don't claim delivery experience we don't have
- We don't ship a product to a market we can't support
- We don't take on builds that need a team we don't have
- We don't publish launch dates before something is ready
See what the process has produced.
Explore the portfolio