[01]
A builder people can drive by hand
Built end to end: the user dashboard where owners create and edit every page, the admin dashboard across all accounts and sites, and the customer-facing site their visitors see.
[CASE STUDY 01]
Carder AI Mini-Site Builder
An AI mini-site builder for local businesses: one prompt becomes a complete site in about 30 seconds. I built the site builder end to end, then automated it with RAG over each user's own uploads, and led the backend and data.
- Role
- Full-Stack Engineer & Backend Lead
- Timeline
- Nov 2022 – Feb 2026
- Status
- Live
- Stack
- Laravel, Next.js, TypeScript +6
[AT A GLANCE]
- TEAM
- Two backend engineers working with product and frontend
- USERS
- 150+ users across the Middle East and Europe, live throughout
- OWNED
- Site builder end to end: user dashboard, admin dashboard, published site · AI automation · schema · quotas · media · billing · CI/CD
- NOT MINE
- The pre-trained generation model itself, and the marketing site
- AI
- Pre-trained model grounded by RAG over each user's uploads, with instructions the user can fully customise
- RUNTIMES
- Laravel core, Node/Express services for specific workloads
- PRODUCT
- Free · Pro $12/mo · Business $29/mo; 5 AI generations in a free account's first month, then 10 / 30 a month on Pro / Business
[STACK]
- Laravel
- Next.js
- TypeScript
- Node.js
- Express
- SQL
- RAG
- Stripe
- AWS S3
[01] The problem
A list of links is not a business
Small businesses often need more than a link list but cannot justify a custom site or learn a page builder. Carder first needed a builder people could drive by hand, then a way to skip it: one sentence in, a finished site out. All of it had to ship into a live Laravel product without disrupting paying customers.
[02] The constraints
What a live product would not let us do
The product was live the whole time
Every schema change had to support a running application and every deployment needed a rollback path that did not require restoring a backup.
Laravel was not up for replacement
The established Laravel core stayed in place. New services had to integrate with its database and workflows rather than justify a rewrite.
A two-person backend team
With no dedicated platform team, every new service also became ours to deploy, monitor and support.
[03] The approach
How it was built
I built the manual builder first: the user dashboard where owners create and edit every page, the admin dashboard across all accounts, and the customer-facing site it publishes. Then I automated the same flow with our pre-trained model, grounded by RAG over each user's uploads and steered by instructions they can fully customise. Underneath, Laravel stayed the core, media moved to object storage and billing state came from its authoritative source.
[KEY DECISIONS]
- [01]Built the manual builder end to end first: user dashboard, admin dashboard and the published customer site.
- [02]Automated the whole flow with our pre-trained model, grounded by RAG over the user's own uploads.
- [03]Let each user fully customise the generation instructions instead of fixing one house prompt.
- [04]Kept Laravel as the core while separating media and billing workloads.
- [05]Metered AI generation by plan without locking existing sites when the quota ended.
* REQUEST, BILLING AND MEDIA PATHS
[04] The trade-offs
What each choice cost
[01]
Meter generations, not requests
- Instead of
- Cap the expensive thing at the API layer, or trust the client not to ask twice
- What it cost
- Monthly counters must handle resets, retries and partial failures correctly.
- What it bought
- Plans limit the operation with a real unit cost while ordinary editing and browsing remain unrestricted.
[02]
A Node service for the media pipeline, Laravel for everything else
- Instead of
- Handle uploads in Laravel like the rest of the application
- What it cost
- A second runtime added deployment, monitoring and patching overhead.
- What it bought
- Image uploads stopped competing with page requests for PHP workers.
[03]
Expand and contract for every schema change
- Instead of
- Alter the column and ship it
- What it cost
- Changes take multiple deploys while old and new shapes coexist.
- What it bought
- Live migrations remain reversible without restoring a database backup.
[04]
Signed S3 URLs, delivered from the edge
- Instead of
- Proxy the bytes through the application server
- What it cost
- Expiring URLs and a signing endpoint add lifecycle and caching work.
- What it bought
- The application no longer handles image bytes, and delivery scales independently at the edge.
[05]
Stripe is the source of truth for entitlement
- Instead of
- Mirror subscription state into our own tables and trust the local copy
- What it cost
- Entitlement requires a provider call or a short-lived cache that must be invalidated correctly.
- What it bought
- Refunds and failed renewals change access promptly, without a stale local copy granting the wrong tier.
[05] The build
What Carder is made of
[02]
The editor, as owners see it
Owners build a site section by section with a live preview in mobile or desktop view. Design, content, contact, links, AI and settings each have their own panel, every change auto-saves, and a progress meter shows which sections are complete before the site goes live or is unpublished.
[03]
Then one sentence does the building
The same flow, automated with our pre-trained model. Generation is grounded by RAG over the user's own uploaded material and steered by instructions each user can fully customise, so the site reads like their business rather than a template.
[04]
Media that never touches the app
Uploads go directly to S3 through signed URLs and are delivered from the edge. The API never handles image bytes, so media growth does not consume request workers.
[05]
Three tiers, asked on every request
Free, Pro and Business plans control pages, sites, domains and generation quotas. Entitlement is derived from Stripe and briefly cached for frequent checks on save, publish and domain lookup.
[06]
An admin panel over the whole tenancy
The back office covers accounts, sites, companies and subscriptions without requiring production SQL. Changes flow through the same billing and entitlement paths as the product.
[07]
Metering the one expensive operation
Quotas apply only to AI generation: 5 in a free account's first month, then 10 a month on Pro and 30 on Business. Existing sites stay editable, and failed generations do not consume allowance.
[06] What broke
And what fixed it
!01
Entitlement drifted from billing
The first version trusted locally mirrored subscription state. Duplicate, delayed and out-of-order Stripe webhooks let that copy drift from the billing record, sometimes granting the wrong access.
!02
The fix was to stop remembering
Entitlement now comes from Stripe. Webhooks are idempotent by event ID, and stale events are discarded, so replaying an event is a no-op.
[07] The result
What Carder measured
150+
Users, ME & Europe
* two regions, as of Feb 2026
+40%
Adoption growth
* first tracked month to Feb 2026
3
Metered tiers
* free · $12 · $29; 5 in the first month, then 10 / 30 a month
0
Downtime migrations
* expand / contract, against live data
[HOW THESE WERE MEASURED]
User count and tier structure come from platform records and public pricing. The +40% compares the first instrumented month with February 2026, not the full rebuild. Zero-downtime migrations counts schema changes shipped against live data, not uptime.
[08] What I’d do differently
Honestly
I’d instrument adoption from day one. Early features shipped on intuition, so the +40% improvement only became visible after analytics arrived.
Need something like this built?
Next case study [02]
Volumize
Telehealth E-Commerce Platform
Read the case study →
