← Back to the Filing Cabinet The Workshop

Four products. Real ownership. All live.

These aren't side-project screenshots — they're running today, right now, with real users, real payments, and real infrastructure decisions behind them. Three of these I built solo, start to finish. The fourth started as a team's campaign concept, and I'm the one who built the backend and got it live. I build with Claude, Gemini, Cursor, and Lovable, and wherever I'm the engineer, I own every decision in between: the data model, the payment flow, the failure states, the thing that breaks at 2am. Here's the full story on each.

🤖 Auto-Post 🎂 Cheerly 📸 Pixdrop 🧩 Father Figure
🤖
Auto-Post
autopost.grownownow.com · solo-built · live · runs daily
DailyFully hands-off
LiveResearch + write + publish
SoloConcept to deploy

The problem

A consistent LinkedIn presence is one of the highest-leverage things a person building in public can do — and also one of the easiest things to let slide. Between a full-time lifecycle marketing role and everything else, I didn't have a spare 30 minutes a day to find something worth posting about, write it, and actually hit publish.

What I actually built

Auto-Post is an agentic tool, built on Lovable, that runs on its own schedule. Each day it goes out and researches trending, relevant topics live on Google — not a static list I fed it once, but a fresh look every single time — then drafts a post in a voice I defined up front, and publishes it. No queue to review, no draft folder to remember to check.

The decisions that mattered

The interesting design problem wasn't "call an LLM" — it was making the research step live instead of static, so the output doesn't go stale after week one, and constraining the voice tightly enough that it still sounds like something I'd actually say. I iterated on the prompt scaffolding several times before it stopped sounding like generic LinkedIn filler.

What's next

I'm considering a lightweight approval step for sensitive weeks (launches, layoffs in the industry, etc.) — full autonomy is the point, but a manual override switch is cheap insurance.

The whole point was: if I stop thinking about it for a week, it should still be working. It is.
See it live →
🎂
Cheerly
cheerly.grownownow.com · solo-built · live · monetized product
PaystackReal subscriptions
RLSRow-level security
AutoRefund handling

The problem

Birthday shoutouts on social media are throwaway — a story that disappears in 24 hours, or a comment buried under a hundred others. I wanted to build something that felt like an actual gift: a page someone could keep, made specifically for one person's day.

What I actually built

Cheerly lets anyone create a personal birthday page — friends and family record voice-note messages that play back on the celebrant's own page. It's a full product, not a demo: there's a free tier and a paid tier, with Paystack handling live subscription billing, automated refund processing when someone cancels or disputes a charge, and Row-Level Security enforced at the database layer so one user's data is never visible to another, even through a bug.

The decisions that mattered

The payment and security layer was the real engineering work here. Getting refunds to happen automatically (instead of me manually processing them from a dashboard) meant thinking through the failure states up front: what happens if a webhook fires twice, what happens if a refund is issued for a subscription that's already renewed, what the user sees during that window. RLS wasn't optional once real payment data was involved — it was the baseline for shipping something I'd trust with someone else's money and someone else's voice recordings.

What's next

Looking at group-gift pages (multiple contributors, one page) as the next feature, since that's the most common request from actual users.

This is the one where "vibe coding" stopped being the point — the payment logic had to be correct, not just working in the happy path.
See it live →
📸
Pixdrop
pixdrop1.lovable.app · solo-built · live · hosted image & GIF links
100MBPer-file ceiling
Private + publicSplit visibility model
RLSRow-level ownership

The problem

Marketing and ops teams constantly need a hosted image URL — for MoEngage, Mailchimp, Notion, anywhere an <img> tag is accepted. The existing options are all wrong in their own way: Imgur is noisy with ads and a social feed you don't need, Discord CDN links rot and stop resolving, and a full DAM is overkill for what's really a one-step job.

What I actually built

Pixdrop is that one step, and nothing else: drag and drop a file, get a permanent direct URL, copy it, paste it anywhere. Every upload lands in a private dashboard that only the uploader can see, while the file itself resolves as a public URL — because the whole point is that it has to work embedded in an email or a CRM template. Auth-gated writes, one-click copy on every card, 100MB per file.

The decisions that mattered

The split-visibility model was the real design call: gallery metadata is private per user, but the underlying file bytes are public by design so the URL actually works where it's pasted. I backed that with real security hardening rather than trusting client-side checks — row-level ownership on every upload row, storage policies that scope writes and deletes to the uploader's own folder path, and leaked-password protection on auth. Visually I went dark theme, monospace accents — signalling "developer utility," not another social upload app.

What's next

Fronting high-traffic embeds with a CDN is the next real improvement — right now a heavily hotlinked image can hit Postgres connection limits, and I already added retry-with-backoff as the stopgap while that's on the list.

Think Imgur, stripped to the one job that matters: upload → copy link → paste anywhere.
See it live →
🧩
Father Figure
fatherfigure.netlify.app · team concept, backend built solo · live
Team ideaFront-end campaign concept
SoloBackend — I brought it to life

The problem

This one wasn't my idea to begin with — it was a Father's Day campaign concept the team came up with: an interactive HTML experience with no backend behind it. A good idea sitting still is just a mockup, and nobody had actually made it work yet.

What I actually built

I took ownership of turning the front-end concept into a real, live product — building the backend it was missing and getting it from "interactive HTML idea" to a working, shareable experience at a public URL. The team brought the campaign concept; I'm the reason it actually runs.

The decisions that mattered

Since the front-end direction was already set by the team, my decisions were all about what it would take to make that idea functional without over-building it — picking the lightest backend that could support the experience as designed, and hosting (Netlify) that kept the whole thing fast to ship.

What's next

It's stayed scoped to what the campaign needed — a good example of knowing when a build is done rather than adding scope for its own sake.

Team's concept, my backend. Knowing which part is yours to own is half of working well on a team.
See it live →
Wondering if this maps to your role?

Run a fit check with April.

Go to Fit Check →
AprilFaith's assistant

Visual interview with AI Faith

This is a recorded, consent-first conversation with an AI clone of Faith. By continuing, you agree the session may be recorded so the real Faith can review it and follow up personally.