Layrrrd was built during an intensive product sprint by a four-person team. Unlike the other projects in this portfolio, there was no existing product, client brief, or defined requirement to work from. We started with an observation, formed a hypothesis, tested it with real people, and eventually put a working product in the hands of paying users.
The product changed several times during that process. The underlying behaviour did not.
People kept discovering and saving things they considered valuable. The failure happened afterwards: those things became increasingly difficult to find, retrieve, and use again.
That distinction became the foundation for Layrrrd.
The initial hypothesis was that people needed better content discovery.
Designers were already surrounded by an enormous amount of useful material, articles, tools, references, newsletters, podcasts, and research — but finding the right things consistently was difficult. A curated content experience therefore seemed like a reasonable starting point. The first direction explored a design-focused newsletter, built around the belief that better curation could reduce the noise.
The logic was simple:
Discover better → Save more intentionally → Get more value.
But as the product moved closer to real users, the assumption became harder to defend. People weren't telling us they couldn't find good content. They were telling us they had too much of it saved. Links were sent to themselves. Browser tabs were kept open. Bookmarks accumulated without being revisited. The problem appeared after the moment of discovery, not before it. That was the first important shift in our understanding: saving and retrieving are different problems. The product had initially been designed around the first. The users were revealing a much stronger need around the second.
The problem wasn't discovering content.
It was finding it again.
The research did more than validate the existence of a problem. It showed us where the problem was concentrated.
85.5% of respondents experienced at least one content-management pain point, while 50% experienced multiple pain points simultaneously. Only 11.8% reported no issues at all.
More revealing were the behaviours people had developed in the absence of a better system. 67% sent links to themselves, while 45% kept tabs open rather than bookmarking them. These workarounds suggested that the issue wasn't a lack of willingness to save, it was the absence of a reliable way to return to what had been saved.
Then came the finding that settled the delivery question: 43% preferred asking for content when they needed it rather than receiving a scheduled digest.
The evidence base eventually included 84 sign-ups, 82 survey responses, and 8 usability studies.
The product had to be reconsidered from several directions. The recommendation engine was dropped. Collaborative filtering was parked. The ICP moved away from a profession-specific definition of designers toward a behaviour-defined profile: Serial Savers. The delivery model moved from scheduled content toward on-demand retrieval. The onboarding model changed from asking users to build their library before experiencing value to providing a taste-calibrated dashboard from the beginning.
Four decisions became connected:
Library → Taste calibration
Instead of waiting for a user's library to become useful, the product could establish relevance from the first session.
Memory layer over media library
Bridge the gap between “I saved this once” and “I need this now.”
Designers → Serial Savers
The ICP became a behaviour rather than a job title, opening the product to anyone with the same underlying problem.
Subscription → Founding Membership
For the sprint, a limited one-time founding offer created a simpler path to validating willingness to pay without introducing recurring billing overhead.
The pivot clarified what Layrrrd needed to be:
Personal Content Management, built around retrieving saved content rather than organising or discovering more of it.
Three principles shaped the product:
Retrieval over organisation
Find what you saved without remembering where you put it.
On-demand over scheduled
Retrieve content when you need it, rather than being interrupted by it.
Memory layer over media library
Bridge the gap between “I saved this once” and “I need this now.”
From here, every product decision had a simple test: Does it improve retrieval?
The MVP centred on one simple loop:
Save → Process → Retrieve → Refine
Three entry points supported the same system:
Web app
manage your library and dashboard.
Chrome extension
save content with minimal friction.
Rudolf
retrieve saved content conversationally through Telegram and WhatsApp.
Rudolf was deliberately limited to the user's own library. This kept the experience focused on retrieval rather than drifting back toward generic discovery. Testing then shaped the details: shorter onboarding, curated starter collections, clearer save confirmations, more intentional reminders, and simpler navigation. The goal wasn't to add more features. It was to make the retrieval model work naturally.
Building the product was only half the experiment. We also needed to understand whether people would use it, pay for it, and whether the model could extend beyond founder-led acquisition.
The first funnel moved from
84 sign-ups → 8 usability-tested users → 12 paying customers
generating ₹9,588 in founding-membership sales.
The early cohort provided evidence of willingness to pay, while also exposing the questions that remained open: retention, repeatable acquisition, and sustainable subscription economics.
The goal was never to manufacture certainty. It was to move from
Assumption → Evidence → Better questions
The most valuable outcome of Layrrrd wasn't the interface or the AI layer. It was learning how much can change when the question changes. The newsletter, recommendation engine, and retrieval product were different attempts to solve the same underlying behaviour: people discover, save, and eventually lose track of content.
What changed was where we chose to intervene.
The early versions focused on discovery. The final product focused on retrieval. That shift changed how I approach product work: define where the problem actually occurs before deciding what to build around it.
We didn't find a new problem. We found the right place to solve the same one.
That lesson is what I carried forward from building Layrrrd.