Scaling CutiePage to 50,000+ users and 10,000+ monthly actives

CutiePage started as a small idea with an obvious emotional hook: people want to give something personal, and a generic gift card does not carry feeling. So we built a way to make a custom website gift — pick a design, add your own photos and words, publish a private link, and send it to someone who matters.

That idea has now grown into India's digital gifting platform, with 50,000+ users and 10,000+ monthly active users. I'm the founder, and I've worked across the product, the growth, and the systems that keep it standing.

This post is about what actually moved the numbers. I'm deliberately not going deep on our internal architecture — that stack is our own. What follows is the product and scaling thinking, which I think is the more transferable part anyway.

The Product Insight: Gifting Is a Deadline, Not a Category

The single most useful thing I learned early is that gifting is not a browsing behaviour. It is a deadline behaviour.

Nobody wakes up wanting to explore gift options. They remember an anniversary is on Friday. They realise a birthday is tomorrow. They are already slightly anxious when they arrive, and that anxiety shapes everything about what the product needs to be.

That reframing changed our priorities completely:

• Time-to-finished-gift became the north star metric, not time on site. Engagement is a vanity metric when your user wants to leave with something done.
• Templates had to be genuinely good out of the box, because a stressed user will not art-direct anything. The default state has to already feel like a gift.
• Every optional step became suspect. If a field did not make the final gift more personal, it was friction standing between a user and their deadline.

Most people finish in under fifteen minutes. That number is the product.

Growth Came From the Gift Itself

We did not scale on ad spend. The distribution was built into what we sell.

Every CutiePage gift ends up as a link that one person sends to another person, and that recipient is almost always exactly the kind of person who would use the product themselves. The gift *is* the marketing. Someone receives something that made them feel genuinely special, and the natural next thought is "I want to make one of these."

That has a few practical consequences worth naming:

1. The recipient experience matters more than the creator experience. This is counterintuitive, because the creator is the one who paid. But the recipient is the entire acquisition channel, and they arrive with zero context and high emotional expectation.
2. Loading speed on a shared link is a growth metric. A gift link is opened on mobile, often on a weak connection, usually within seconds of receiving it. A page that stalls does not just disappoint the recipient — it kills the referral.
3. Occasions are seasonal, and seasons compound. Valentine's, birthdays, anniversaries, festivals. Each spike leaves behind users who come back for the next occasion in their own calendar.

What Breaks Between 1,000 and 50,000 Users

Things that were completely fine at small scale stopped being fine, and almost none of them were the things I expected.

Traffic is spiky, not smooth. Gifting demand clusters hard around dates. Average load tells you nothing useful; the peak is the only number that matters. We had to plan capacity around the worst hour of the worst day, not the average week.

User-generated media is the real weight. People upload photos, and photos from modern phones are large. A meaningful share of our early performance problems traced back to media handling rather than anything clever. Getting disciplined about how images are processed, stored, and delivered was probably the highest-leverage performance work we did.

Support volume scales with emotion, not with users. When something goes wrong with an ordinary SaaS tool, people are annoyed. When something goes wrong with a gift for someone's anniversary, people are *distressed*. We had to treat support as a core product surface with real response commitments, not an afterthought inbox.

Edge cases become daily events. At a thousand users, a one-in-a-thousand bug is a curiosity. At thirty thousand, it is something happening constantly to real people on important days.

Retention in a Product People "Only Need Once"

The obvious critique of a gifting product is that it should have terrible retention. You make a birthday gift, you leave, you are done.

That turned out to be wrong, but only because we designed against it.

The insight is that people do not have *one* occasion. They have a calendar full of them — a partner, parents, a best friend, siblings — and those dates recur every single year. A user who has a good experience once has a genuine reason to return within a few months, without us manufacturing one.

Holding 10,000+ monthly actives against a 50,000+ user base comes down to earning that second occasion:

• The first gift has to be good enough to be remembered months later. Retention here is decided at creation time, not by a re-engagement campaign.
• Rewards and referrals give returning users a reason to bring the next person. Growth and retention are the same motion in this product.
• Coming back should feel easier than the first time. Returning users have already learned the product; making them re-learn it wastes the trust the first gift earned.

What I'd Tell Someone Building Something Similar

Three things I believe more strongly now than when I started.

Emotional products have a higher correctness bar than technical ones. A dashboard that glitches is a bug report. A gift that glitches is a ruined moment someone cannot redo. That standard should shape how you think about reliability well before your scale justifies it.

Distribution should live inside the product, not beside it. We got to 50,000 users because sharing was the core mechanic rather than a growth feature bolted on afterwards. If you have to add virality later, you probably built the wrong core loop.

Optimise for the user's actual emotional state. Ours arrive slightly panicked and short on time. Every decision we made — the templates, the flow length, the speed — follows from taking that seriously instead of designing for an imaginary user with unlimited patience.

CutiePage is still growing, and the interesting problems keep changing shape as it does. But the thing that got it here was never the technology. It was being honest about what people were actually trying to do, and removing everything in their way.