MoFlo Shipped: Feb 2026

Building a content execution system for SMBs

Every tool worked and nobody was posting. My first fix, better generation, barely moved it. What worked was giving up on getting users to start.

Founding product designer 5 weeks
60→25% weekly drop-off
70% drafts approved as-is
3× multi-platform posts per session
0 changes to the AI model
Product analytics, one month after launch.
Mine
  • Product strategy
  • User research
  • Interaction design
  • UI design
  • Prototyping
Shared
  • Detection logicwith CTO
  • Roadmapwith lead dev
Not mine
  • AI models
  • Publishing integrations
  • Back end

The situation

The product worked. The behaviour didn't.

MoFlo is an AI content platform for small businesses: generation, scheduling, multi-platform publishing. All of it worked. Owners kept opening the dashboard and still didn't post.

The live MoFlo posts page: a To do grid of drafts, each marked Flo Generated or Drafts with Post Now and Schedule buttons, beside lists of upcoming and posted content
The posts page today, after the redesign.
2posts per session before most users stopped
20% of users who acted on a performance insight

Wrong guess

I blamed the output. I was wrong about where sessions died.

My first guess was the comfortable one: output quality. So I tested it cheaply, simplifying the input, suggesting topics and cutting friction from generation.

Built to test the hypothesis, not to ship.
Caveat:

Drop-off improved slightly. Most users still stopped as early as before.

Real cause

Not quality. Starting. That was where every session ended.

I interviewed active customers about how they handle content week to week.

How do you decide what to post? When do you create content? What happens when you open the dashboard? What usually stops you from publishing?

None of them mention the product, so the answers couldn't turn into opinions about the generator.

I open the dashboard, look at the numbers, and then close it. It feels like I have to think too much before I can even start.

SMB owner, customer interview
Session 1
Sorting what people said from what they did.

They didn't lack tools; they lacked momentum. Content happened when they had time or felt pressure, so every week started from zero.

The reframe

Stop asking to begin. The product should open with a first move.

If the expensive step is starting, the system should do the starting.

Existing flow
  1. You: Decide to begin
  2. You: Decide what to postTopic, angle, occasion
  3. System: Generate caption
  4. System: Generate image
  5. You: SchedulePlatform, date, time, confirm
Redesigned flow
  1. System: Detects a gap
  2. System: Drafts are waiting
  3. You: Review in one place
  4. You: Approve
Runs on its ownA decision asked of you
Four decisions before anything exists, versus one after.
Signals surfacing what needs attention, in real time.

Early versions

Three structures. One shipped; here is what the others got wrong.

As first built, each was organised and reasonable, and each still made the owner choose where to start.

Which one first?Rejected
Recreation, as a timeline from Monday night to Tuesday evening. The owner is away overnight. While they are, MoFlo finds three gaps, a quiet platform, an unbalanced mix and a thin runway, and drafts a post for each, one at a time. At 8:12am the owner comes back and approves all three at once, in about a minute. From then on the posts go out on their own: the first at 6pm, the other two later.

What shipped

Review, don't create. The work arrives already drafted.

Three pieces, in the order they run. I prototyped each before handoff, so developers built against a working thing, not a spec.

MoFlo's February calendar under a Flo Insights bar reading Content runway 3 days, Instagram inactive for 72 hours, and 23 posts on LinkedIn in the last month. Posts sit on the 3rd and 5th; the rest of the month is empty
Flo Insights over the calendar: three days of runway, then nothing booked.

Gap detection decides what to make. Three signals, each fixable in one click: a quiet platform, a thin content runway, an unbalanced channel mix. Engagement dips are just information, so they stay out.

View Post dialog for a published post: the image and caption marked read-only, posted March 17th, with Instagram and Twitter tabs and 18% engagement, 24.1K reach and 847 likes
Engagement lives on the posted work, read-only.
How one post lands on each platform, before approval.

One review, not three previews. Every platform's version of a post, in one view. The hardest piece to argue for: a platform switcher saves space but costs a decision per platform.

Post or Schedule dialog: the post's image and caption with Instagram and X tabs, platforms to publish to, suggested dates and times, a custom date and time, and Let Flo Schedule for You
Review, then let Flo pick the time.

Approval is the only decision left. It schedules the post on an optimised cadence. The time stays overridable, so the system helps rather than decides.

MoFlo week view: a To do list of Flo Generated and Drafts cards beside Sunday to Saturday, each day offering suggested posting times, with one post out on Monday and two more scheduled
Best times on every day, and the to-do list docked beside them.

The system spends the decisions; the user spends the judgment.

Reflection

A design problem. No model has ever fixed a blank page.

Users stopped planning content. They started maintaining it.

I spent the first stretch improving output because it was the legible thing to improve. The experiment that disproved it took two days.

Drop-off is the whole active base one month after launch, not a test cohort.

70% approved unedited could also mean owners rubber-stamping a queue to get through it. The publishing number rules that out: rubber-stamped content doesn't get posted to three platforms. Had the two moved in opposite directions, I'd have read the 70% as a failure.

Role
Founding Product Designer
Team
Founding Product Designer (Me), CTO, Lead Developer, 2 Dev Interns
Timeline
5 Weeks
Tools
Figma (Design, Make, Jam), Claude Code, Lottielab, v0, Fullstory