There’s a version of “build in public” where every post is a shipped feature and every week is a win. I’ve tried to write that version a few times. It gets boring fast, for the writer and probably for the reader.
This week’s post is about the week I mostly stopped building features and thought about growth instead. Three things happened. One came from a conversation. One came from reading competitor sitemaps. One came from finally fixing something I’d been quietly avoiding for months. All three changed how I think about what Memolio needs to become before it can grow, and all three have nothing to do with the AI pipeline that I usually write about here.
The friction in the intake is a feature, not a bug
I spent an hour with someone who used to run seven-figure-a-month Meta ad accounts. I expected tactics. What I got instead was a structural diagnosis.
The conversation went roughly like this. He looked at what Memolio is: a personalised book for grandparents built from a half-hour WhatsApp or web intake, their photos, and a two-week production run. Then he looked at what a Meta ad is, an impulse-buy surface where someone scrolls, sees a thing, taps, and expects to be three clicks from checkout. And he said: “These two things are not compatible.”
He wasn’t wrong. Memolio’s intake, the thing that makes the book actually personalised rather than a template with a name dropped in, takes time. You need photos. You need to know your grandparent’s story. You need to coordinate with someone, or at least go find the old phone photos. That’s work. That’s not what someone does from a Meta ad in forty seconds.
The usual advice in this situation is “reduce friction.” Shorten the form. Cut questions. Make it faster. That advice is correct if the friction is accidental, if you’re asking questions the product doesn’t actually need. Our intake isn’t like that. Every question shapes the story. The friction is what makes the book yours rather than generic. Removing it would make a worse book.
So the real fix isn’t less friction. It’s a different first step.
The sample page generator, which I built back in March and then half-forgot about, turns out to be exactly the right first step. Someone answers three questions and uploads one photo, and in twenty minutes they have a painted page that looks like a page from their book. That’s the impulse-buy moment. That’s what converts from a Meta ad. The full intake, the full production run, the hardcover delivered in two weeks, all of that becomes a warm follow-up to someone who already saw what the product does for them specifically.
The framing that stuck with me: the friction isn’t a bug to remove. It’s a feature to gate behind a smaller, finished artefact.
Two-tier funnels are not a new idea. What surprised me was how obvious it was in hindsight, and how long I’d been looking at this problem from the wrong angle.
The unsexy work is where the growth is
After the ads conversation, I spent an afternoon doing something I’d been vaguely meaning to do for weeks: actually reading competitor sitemaps.
Two of the bigger competitors in this space expose full sitemaps. One has roughly 150 URLs, a dense taxonomy of every recipient (grandparents, dads, mums, partners, aunties) crossed with every occasion (anniversaries, milestone birthdays, wedding engagements) crossed with every theme (astrology, pets, sports, poetry). Same product, a couple dozen different keyword entry points.
The other has a thinner taxonomy but a much bigger journal: 23 “questions to ask your [relative]” pages, and over 60 individual customer-story posts. Each customer story is simultaneously an SEO target and a wall of social proof. Someone landing on three or four of them starts to feel like “this is normal, not novel.”
What hit hardest about the customer-stories engine: it doesn’t require any new product engineering. There are no new features to build. The work is “set up a templated post type, write the first three yourself once you have permission, and ship one a week thereafter.” Content operations, not software development.
I’ve been building Memolio on the things I find technically interesting: an on-site sample generator, a bilingual pipeline, AEO definition pages, a character age-band system so grandchildren don’t all look like toddlers. That work matters. But the pattern I saw in those sitemaps is clear. The thing that actually drives organic growth is volume of what I’m calling unsexy content, recipient landing pages, comparison articles, question banks, customer stories. Not technically interesting. Scales through repetition. We’re strong on the things builders find interesting, and weak on the things that compound through volume.
I updated the content calendar. There are new priorities now.
The waitlist that was actually a newsletter subscription
The third thing I fixed this week had been bothering me for longer than I care to admit.
Every “Join the Waitlist” button on the Memolio site pointed at the Substack subscribe page, which means every person who clicked it was asked to subscribe to a writer’s newsletter, from a writer they’d never read, when all they actually wanted was an email when the product opened for orders.
Two things are wrong with that. From the user’s side, you’re asking for a bigger commitment (”follow this person”) when they just wanted a smaller one (”tell me when I can buy this”). From Memolio’s side, you’re collecting an email address with no context, no language preference, no sense of whether this is a gift for a grandmother in Vienna or a grandfather in Edinburgh. And Substack owns the list, which means your launch email goes out through their delivery layer, with their headers, their branding, their unsubscribe page.
The right solution is an owned waitlist table in Postgres, which is where customer data actually belongs. I rebuilt it: two tables (waitlist, samples) joined by a view (marketing_recipients) that deduplicates automatically, with a primary_channel flag so the launch email addresses people the right way depending on which channel brought them in. Both the waitlist form and the sample form now collect explicit marketing consent, the GDPR-shaped kind, where the wording is stored alongside the checkbox state and the timestamp so you can prove what they agreed to.
What finally tipped me into doing this: realising the sample page was a much stronger lead magnet than a newsletter subscribe button, and that building the two-tier funnel properly meant owning both layers. You can’t run a proper launch sequence through Substack. I’d been quietly ignoring this for months because it felt like infrastructure, not product. It was infrastructure. It still needed doing.
What’s next
Next week I’m back to building. The Stripe integration is the last pre-launch blocker, and that’s where the focus goes. The sample funnel is running, the waitlist is owned, the content strategy is updated. The pipeline behind the personalised book for grandparents is in better shape than it’s ever been.
The build-in-public post in two weeks will probably be about something that broke while I was hooking up payment flows. Looking forward to it.
If you’re building something that has real intake friction, a long-form product, a service that requires coordination, I’d be curious how you’ve handled the funnel split. Drop a note.
Follow the build on Substack — new posts every Monday.
Memolio makes personalised illustrated books for grandparents, built from their photos and stories. Coming soon — join the waitlist to be notified when we open.