Three28 Creator Platform

What is Three28?

Three28 is a video app for creators. Its App Store listing describes four things: uploading and sharing videos with an audience; selling videos directly to fans at prices the creator sets, including exclusive content; selling merchandise alongside the videos; and receiving payments directly to the creator's account.

The pitch is that hosting, selling and merchandise sit in one app, rather than being spread across a video host, a payment page and a separate shop.

What problem was Three28 built to solve?

The problem is plain: content creators struggle to sell their work efficiently, often paying high fees and lacking control over their pricing. Those are two separate failures that happen to arrive together.

Fees are a distribution problem. When the channel carrying the audience also sets the take rate, a creator's margin is decided by someone else's policy, not by the work. Pricing control is a product problem. A platform offering only fixed tiers forces every creator into the same commercial shape, whether they sell one long piece of work or a catalogue of short ones.

Solving both in one system means price cannot be a setting on a page. It has to be first-class data attached to each item, and the money path has to be explicit enough that a creator can account for where every sale went.

What did Sameem work on?

Three28 hired Sameem directly, and he worked on the build. The app is built in React Native, the backend in NestJS, and the backend is hosted on AWS.

That shape is the ordinary one for a product that takes money. A mobile app is code running on devices other people control, and its local state can be read and changed. The server is the only part of the system whose behaviour the person using it cannot edit. Any product where a price or a payment has to mean the same thing for everyone keeps those decisions on the server, not because apps misbehave often, but because trusting one cannot be verified.

Release speed is the second reason. Mobile code reaches users through App Store review; server code does not. Anything commercial that may need correcting quickly is better held where correcting it does not need a new build.

Why does React Native suit a video monetisation app?

React Native is the framework behind the Three28 app, and the workload it carries, uploading, sharing and selling video, plays to its strengths. It renders through native view components rather than a web wrapper, so scrolling and video surfaces behave the way the platform's own do instead of approximating them.

The demanding part of that workload is the upload. Moving a large file off a phone is native-side work in any framework: it has to survive a weak connection, an app sent to the background and a user who switches away mid-transfer. React Native suits that, because the native layer is reachable through modules while product logic stays in JavaScript, where commercial behaviour can change without rewriting the parts that touch the operating system.

Its usual argument is one codebase across platforms, and where a paid product ships on two platforms, having one implementation of the rules that decide money is a correctness property, not just a saving.

Why does NestJS suit a backend handling video, pricing and payments?

The product areas are known from the listing: video content, creator-set pricing, payments to creators and merchandise. That is several distinct concerns with one awkward property in common. Some of them touch money and some do not, and the ones that do should not be reachable by accident from the ones that do not.

NestJS answers that at framework level. Modules, providers and dependency injection make the boundaries between areas explicit and enforced by the framework rather than by convention, which is the difference between a structure that holds under pressure and one that holds only while everybody remembers it.

Being TypeScript-first matters where records are financial. The shape of a price or a payment is checked when the code compiles rather than discovered when a figure looks wrong. Guards, pipes and interceptors cover role separation between creators and fans, validation of incoming payloads before they reach a stored record, and a consistent error shape.

What does creator-set pricing demand of a data model?

Letting creators set their own prices sounds like a form field and is really a modelling decision. If a price lives on the video record and is edited in place, every past purchase loses the context it was made under, and earnings reports become guesswork the moment a creator changes what they charge.

The alternative is to treat price as versioned data and bind each sale to the price in effect when it happened, so the sale record carries its own amount rather than pointing to one that may since have changed. That is what makes a creator's earnings reconstructable from the sale records instead of approximated from current settings, and it is what a creator needs before trusting a payout.

It constrains the buying flow too. The price shown before a fan confirms and the price charged at confirmation have to be the same number, which argues for deciding it in one place rather than two.

What does secure and transparent payment handling require of a backend?

The listing says creators receive payments to their account quickly and securely, and the build's payment handling is designed to be secure and transparent. Security governs who may act. Transparency, the ability to explain afterwards and exactly what happened to a given payment, is the stricter requirement, and it is a storage question before it is a permissions one.

It pushes towards recording financial activity as append-only events rather than as a single balance that gets overwritten. A sequence of sales, adjustments and payouts can be replayed to produce a total, and a disagreement can be traced to a single entry. A balance that is overwritten loses its history the first time it is corrected, which is exactly when the history is wanted.

Wherever payment confirmation arrives from an outside system, idempotency stops being optional. Payment providers retry, and a retried confirmation must not create a second record of the same sale. Handling that inside whichever component owns the financial record is safer than a check every new code path has to remember.

Why is selling merchandise alongside video a different problem?

The listing describes merchandise integration: selling merchandise alongside videos. A second kind of sellable thing is rarely just another row in the same table.

Digital and physical goods differ in when a sale is finished. A video purchase is complete once payment clears. A physical item stays open through states the payment system knows nothing about, such as packing, shipping and returns. A catalogue that carries both usually keeps a single checkout and lets each product type hold its own rules after it, because merging them makes the simple case inherit the harder one's lifecycle for no benefit.

Three28 also has a dashboard for tracking performance, which is a different workload again. Selling is transactional and has to be correct; reporting aggregates over accumulated history. Running both against the same tables is how a report ends up competing with the sale it reports on, which is the general argument for emitting events from the sales path and serving reports from pre-aggregated read models.

Where can you see Three28?

Three28 is on the Apple App Store at apps.apple.com/us/app/three28/id6504447934, where it has been listed since July 2024 in the Photo & Video category. The listing describes video sharing, direct video sales at creator-set prices, merchandise integration and direct payments to creators.

Three28 has no web or Android link; the App Store listing is the place to see it.

Why this stack

• React Native: the framework the Three28 app is built on, and a reasonable fit for a product whose core is video. It renders through native view components rather than a web wrapper, so video and scrolling surfaces behave the way the platform's own do, and it reaches native capability through modules where JavaScript cannot go; large uploads that must survive interruption are the obvious case. Its usual argument, one codebase across platforms, keeps the rules that decide money implemented once.
• NestJS: the backend framework behind Three28, and a TypeScript-first one, which matters where the shape of a price or payment record is better checked at compile time than discovered at runtime. Its modules, providers and dependency injection give a framework-level answer to keeping video, pricing, payments, merchandise and reporting apart, with boundaries the framework enforces rather than convention. Guards, pipes and interceptors cover what any paid product needs: role separation, validation of incoming payloads before they reach a stored record, and consistent errors.
• AWS: the host for the backend, and the right class of infrastructure for video. Video is the heaviest payload a product like this moves, and storage and bandwidth should scale independently of the compute running the API rather than sit on the same machines. Elastic capacity is the general argument: anything sized for a provisioned peak pays for that peak permanently.