Detail A2Our product

In production

TribeCrafter

A community platform we design, build and run ourselves, from the product to the servers it runs on.

In production since2026Built since 2024 · run by Quvor

Each communityOwn stackContainers, database, storage

Codebase~340k linesAbout 10,000 commits

Data model87Data collections

Running cost~$8–12Per community, per month

A–A

Where it started

It began as a speed job.

2020

Make our site fast

Great Big Photography World, a photography education business, wanted their WordPress site fast, and real experts only.

Then

Years of community sites

WordPress slowed down as communities grew, and plugins clashed.

2024

We build TribeCrafter

The platform we wanted those communities to run on.

2026

In production

Launched to its first customers, each community on its own stack.

B–B

The product

Each customer gets their own branded community.

For: Creators, coaches, founders, brands
Inside: Feed, groups, courses, paid video, events, chat, search, memberships
Payments: The customer’s own Stripe, 0% platform fee
Branding: Their name, their domain

C–C

What we run

Every community runs on its own. One control plane looks after all of them.

Each customer’s community, isolated

Community

Its own stack

Community

Its own stack

Community

Its own stack

K4 …

And every new one

Its own stack, no shared database

H · Control plane

Control plane

Creates, updates and looks after every community in the fleet

Provisioning

Servers set up as code, with a pool of ready communities

Fleet deploys

Updates roll out in parallel, without downtime

Domains and SSL

Custom domains checked and secured automatically

Single sign-on

Customers sign members in from their own systems

The control plane

Fig. 2 — System map. Every part shown is built and run by Quvor.

D–D

The work, in detail

Five pieces of the platform, and what changed.

Detail D1Isolation

In production

Every community on its own

0shared app databases

Every community runs on its own stack, and signup is instant.

How we did it

Problem: When communities share one application database, one customer’s growth, mistake or migration can reach every other customer.
What we did: Every community gets its own set of containers, its own database, its own storage and its own video library. A pool of communities is kept ready, so a new customer claims one the moment they sign up.
Outcome: No shared application database. Signup is instant. Running a community costs about $8–12 a month.

One community · its own

GetsContainersDatabaseStorageVideo library

Shared app DBNone

SignupInstant←pool of ready communities

Cost~$8–12per community, per month

Detail D2Fleet deploys

In production

Updates without downtime

0failed deploys

Updates reach the whole fleet in parallel, with no downtime.

How we did it

Problem: With every community on its own stack, an update has to reach every stack. Doing that one community at a time was slow and took communities offline while it ran.
What we did: We rebuilt the rollout so communities update in parallel, with no downtime, and schema changes go out to the whole fleet at once.
Outcome: The whole fleet updated with 0 failures in about 387 seconds, against about 769 with downtime before. A schema push across the fleet takes 1m38s, against 7–10 minutes.

Fleet deploy · every community

Deploy time

One by one≈769s

Parallel≈387s

Measure	Before	Now
Downtime	Yes	None
Failed deploys	—	0
Schema push	7–10 min	1m38s

Detail D3Databases

In production

Databases tuned for bare metal

~18×more writes per second

Bare-metal machines, set up automatically and tuned to each one.

How we did it

Problem: Communities write all day: posts, comments, messages, course progress. On virtual servers the database became the limit.
What we did: We moved to bare-metal machines that are ordered and set up automatically, and tuned the database to each machine.
Outcome: About 18× more writes per second at 8 clients, and about 223,000 reads per second against 20,000–30,000 on a virtual server. Single-machine benchmark, after tuning.

Database · transactions per second

Writes · 8 clients

Before1,404

After32,523

Measure	Before	After
Writes · 1 client	323	5,864
Writes · 8 clients	1,404	32,523
Reads	20–30k	223k

Single-machine benchmark, after tuning

Detail D4Paid content

In production

Paid content stays paid

1access check

Paid video plays only for a member with an active enrollment.

How we did it

Problem: Courses and memberships are how customers earn. If paid content leaks, or a paid video can be shared as a plain link, the business behind the community loses money.
What we did: Every request for paid content goes through one access check, and that check refuses by default. Paid course video only plays with a signed token issued to a member with an active enrollment.
Outcome: One place decides who sees what. Paid videos don’t play outside an active enrollment.

Request for paid content

1A member asks for a lesson or a paid video
2One access check looks at their enrollment
3Active enrollment: a signed token plays the video

DefaultRefuse

Detail D5How we build it

Internal

An engineering workspace with AI in it

87data collections

Our agents read the live schema, so work starts from the platform as it is. Internal, not a feature we sell.

How we did it

Problem: A platform with 87 data collections and about 800 fields is too much for anyone to hold in their head. Work done from memory goes wrong.
What we did: We built an AI-assisted engineering workspace for the team. Its agents read the live schema, so specs, test cases and reviews start from the platform as it is. Our docs are written for AI retrieval, so the answers come from the source.
Outcome: The team works from the live platform and written specs, not from memory. This is how we build; it is internal, not a feature we sell.

Engineering workspace · internal

Agents readLive schemaWritten specs

Used forSpecsTest casesReviewsPrototypes

DocsWritten for AI retrieval

E–E

All work Visit TribeCrafter Next caseGreat Big Photography World