[03]
Metering, added later than it should have been
Billing arrived after the pipeline, so partial failures, retries and cancellations needed rules after the fact. Metering now works, but should have shaped the workflow from the start.
[CASE STUDY 06]
Muterpe AI Image Generation SaaS
An AI model-training and image-generation SaaS built from the ground up, with per-user training, streamed generation and usage-based billing.
- Role
- Founding Engineer
- Timeline
- 2023 – Present
- Status
- Live, monetised
- Stack
- Next.js, React, PostgreSQL +3
* TRAIN / GENERATE PIPELINE
[AT A GLANCE]
- ROLE
- Founding engineer — pipeline, prompt shaping, storage, metering and billing, end to end
- USERS
- 200+ on self-serve signup, paying for what they generate rather than for a seat
- OWNED
- Training and generation pipeline · async job queue · asset storage and delivery · usage metering and billing
- NOT MINE
- The models themselves — training and inference run on Fal.ai, prompt shaping goes through OpenAI
- PRODUCT
- Train a model on your own images once, then generate against it, billed per generation
[STACK]
- Next.js
- React
- PostgreSQL
- OpenAI
- Fal.ai
- AWS S3
[01] The problem
Generic models don’t hold a likeness
Generic image generators don’t hold a brand or a person’s likeness. Muterpe needed per-user model training, plus a generation pipeline fast enough that users wouldn’t abandon mid-flow.
[02] The constraints
What a per-user model costs before it earns
Every signup costs money before it earns any
Per-user training consumes GPU time before a customer generates anything, setting a real floor under pricing and free access.
The wait is at the front, where people leave
Training takes minutes before the first result, so progress and responsive background work are essential to first-run retention.
The training set is photographs of the user
Training images contain personal data, so storage and delivery were designed around access control rather than convenience.
[03] The approach
How it was built
Training and generation run as queued jobs, while progress and partial results stream to the interface. Slow model work never blocks the application.
[KEY DECISIONS]
- [01]Trained one model per user on Fal.ai behind an asynchronous job queue.
- [02]Shaped prompts server-side and streamed generated images as they arrived.
- [03]Metered generation in the workflow so billing tracks the operation with real unit cost.
[04] The trade-offs
Where quality beat instant
[01]
Rent the model runtime rather than run GPUs
- Instead of
- Self-host training and inference, which is cheaper per run at volume and gives you the whole stack
- What it cost
- Fal.ai sets the price floor and controls cold starts and queue depth.
- What it bought
- The product shipped without GPU capacity planning, driver maintenance or idle infrastructure cost.
[02]
Train a model per user
- Instead of
- Prompt one shared model with the user's photos as reference images, which needs no training step at all
- What it cost
- Each account incurs training time, GPU cost, storage and a slower first run.
- What it bought
- Likeness remains more consistent than reference-image prompting, the product’s core value.
[03]
Stream partial results instead of returning a finished batch
- Instead of
- Wait for the set to complete and render it at once, which is far simpler to reason about
- What it cost
- The interface must handle partial state, cancellation and mid-stream failures.
- What it bought
- Time to first visible result improved by about 40% without changing the model.
[04]
Charge per generation, not per month
- Instead of
- A flat subscription, which is easier to sell and far easier to build
- What it cost
- Metering must handle partial failures, retries and cancellations in the request path.
- What it bought
- Revenue follows the GPU-backed operation instead of relying on average usage assumptions.
[05] The build
Train, then generate
[01]
Per-user model training
Users upload a set, the job queue picks it up, and training progress streams back to the UI. Nothing about the app is blocked while a model bakes.
[02]
Generation that feels immediate
Prompts are shaped server-side before they hit the generation provider, and results stream in as they land. Perceived speed improved ~40% without changing the underlying model.
[06] The result
What Muterpe measured
200+
Users
* self-serve signup
$5K+
Revenue
* usage-based
99%
Uptime
* rolling 12 months
~40%
Faster, perceived
* streaming, vs. first release
[HOW THESE WERE MEASURED]
Users and revenue come from platform and billing records. The ~40% measures time to first visible result against the first release, not model throughput. Uptime is the rolling twelve-month monitoring figure.
[07] What I’d do differently
Honestly
Usage metering arrived too late and cost more to retrofit than to design upfront. Next time I would meter first and price second.
Need something like this built?
Next case study [07]
SeeTrack
Field-Force & Distribution Platform
Read the case study →
