Building MyRubrica: A Designer’s Six-Month Experiment in Vibe-Coding a SaaS Product

What I learned taking an idea from research doc to real users to shutdown, almost entirely through AI-assisted development

A few months ago I decided to test something on myself: could a solo product designer, with no engineering team, build and launch a real SaaS product using nothing but AI tools — end to end, from idea to paying customers?

That experiment was MyRubrica, an AI grading assistant for teachers. This week I shut it down. But the “did it work” question was never really about the product surviving. It was about the process. Here’s how it actually unfolded.

Finding the Idea

I didn’t start with a feature. I started with research. TALIS data showed teachers globally spend about 9% of their working time grading — US teachers roughly 4.1 hours a week, often at home, off the clock. A Learnosity survey found 75% of teachers would use an AI tool if it cut grading time in half, and a third had considered leaving the profession over it. Districts spend around $25,000 replacing a burned-out teacher.

That’s the pattern I look for as a designer: a documented, painful, recurring problem with an audience that’s already looking for a fix. Grading fit all three. So the idea became a freemium, bilingual (EN/ES) app: upload a rubric, bulk-upload exams, let AI grade them against the key — with the teacher always holding final override power. That last part wasn’t a feature decision, it was a trust decision. Teachers have been burned by EdTech overpromising; AI had to read as assistant, not replacement.

The output was a web app built around the phone in a teacher’s pocket. A teacher types or photographs an answer key once to create a rubric, then simply photographs a stack of student exams with their phone camera. The AI reads the handwriting, matches each exam to a student on the roster, compares every answer against the rubric, and returns a score with a written justification per question. The teacher reviews it in seconds, overrides anything that looks off, and finalizes the grade. What used to be a weekend with a red pen became a five-step guided flow: setup, upload, processing, review, done.

Building It: Lovable for the Product, Perplexity as My Second Brain

I built the entire application in Lovable — the React/Supabase frontend, the grading wizard, the Stripe/PayPal billing, the admin panel, all of it prompted into existence rather than hand-coded.

Perplexity ran alongside as the operational layer that Lovable doesn’t cover. I used it to pull and structure the original workload research (TALIS, RAND, Learnosity) into a pain-points brief before writing a single prompt. I used it to draft the financial model logic — freemium conversion benchmarks, churn assumptions, Lovable’s own pricing tiers — before building it out in a spreadsheet. When campaign data came in, I fed it GA4 exports and Google Ads reports and had it diagnose funnel breaks, like a rubric-creation event that was firing in the wrong place in the code. And every time I needed to hand Lovable a precise spec instead of a vague idea, I’d have it turn a rough ask into a structured, code-free prompt anchored in the app’s own system-context doc, so the AI building the product and the AI managing the project stayed in sync. Lovable shipped the product; Perplexity kept the thinking behind it organized and evidence-based.

The First Signal: Traffic Was Fine, Trust Wasn’t

I launched Google Ads before fully validating the landing page, and week one exposed it fast. CTR was excellent — 10.18%, well above the SaaS/EdTech benchmark. Conversion rate was 0.26%. Five sign-ups from over 1,900 clicks.

The page had been selling AI capability. I paused the campaign and rebuilt it around what I started calling “High Intent, Low Trust”: teachers already believe they have a grading problem, they just don’t trust an unknown tool to solve it. The rebuild added cited workload data, a personalized time-saved calculator, and a founder’s letter — nothing about the ad targeting or the underlying offer changed, only the page. Conversion rate jumped to 7.12% three days later, a 27x lift, with the same traffic and the same clicks.

That redesign is the single highest-leverage thing I did in the entire project. It didn’t just fix a metric — it proved the entire premise of the campaign. Good targeting had been masking a bad landing page, and no amount of media spend or audience tweaking would have fixed that. Design was the bottleneck, and design was the unlock. Every dollar spent before the redesign was close to wasted; every dollar after it converted at top-quartile SaaS rates. That gap, more than any single line of code, is what separated a campaign that looked broken from one that worked.

The Second Signal: The Funnel Can Lie to You

The next campaign split English and Spanish ad groups and nearly doubled sign-ups while cutting CPA to $1.97 — against a $15–50 benchmark. Good news, until I looked past sign-ups. Only 18 users had created a rubric against 135 who’d apparently started grading — a sequence the product doesn’t even allow. Only 6 ever completed a session.

That meant a full GA4 event audit before I could trust any of it: tracing every conversion event back to the exact line firing it, to separate a real activation cliff from a measurement bug. Some of both turned out to be true. The lesson stuck: a funnel dashboard is not evidence until you’ve verified it’s measuring what you think it’s measuring.

The Real Number

Underneath the campaigns was a financial model I’d kept deliberately conservative. Even in the base case, breakeven needed sustained ad spend and years of compounding paid subscribers off a 3% freemium-to-paid rate.

The campaigns proved I could acquire interested teachers cheaply — especially across Latin America, at a $1.30 CPA. What never showed up, across every beta, was a single paid conversion. Free interest was real and inexpensive to generate. Willingness to pay, from individual teachers in a market where schools rarely fund tools like this out of pocket, never materialized fast enough to outrun infrastructure and AI costs.

What Sticks

• Evidence of pain isn’t evidence of willingness to pay — I only rigorously tested the first.
• Design is not decoration on top of a growth strategy — it can be the entire bottleneck. A 27x conversion lift came from the landing page alone, with zero change to targeting, spend, or offer.
• Trust architecture beats feature-first messaging for unfamiliar tools, and the lift is dramatic, not marginal.
• Vibe-coding compresses the build phase, not the go-to-market phase — it can tempt you to ship before the business model is validated.
• Analytics infrastructure is part of the product. A broken funnel event breaks every decision downstream of it.
• A great CPA on unmonetized demand is just an efficient way to lose money slower.

Today MyRubrica is off with around 300 users signed up. I’m closing this chapter with more conviction than I started it, about what I look for in a market and what I don’t chase again without proof. I’m already putting down the first steps toward my next digital adventure, and I’ll keep you all posted.

Building MyRubrica: A Designer’s Six-Month Experiment in Vibe-Coding a SaaS Product was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.