When I started, I had no investments or resources — just an idea, enthusiasm, and two hands. At first glance, that seems like a serious constraint. In practice, however, a lack of budget brings not only challenges but also specific advantages that shape both the product and its development.

I came to the idea of building the service as a user myself. I discovered wishlists and realized how convenient they are: people simply share what they want, and you no longer need to guess gifts. But the services I used were clunky and poorly designed. As a designer, I wondered if it could be done better.

At the beginning, I wasn’t trying to build a company or think about scale. I had no monetization ideas at all. It was more about exploring and finding a balance between aesthetics and usability — where neither compromises the other, and the user gets a strong experience. The first thing I did was create a concept. This is a basic step: until you visualize an idea, it’s hard to tell if it’s viable. The concept helped validate the hypothesis quickly and showed there was real potential.

Soon it became clear I couldn’t build it alone. I could handle design and product, but without development nothing would work. With no budget, hiring wasn’t an option. You go straight to people you already trust.

That’s what I did. I shared the idea with colleagues I had strong relationships with and invited them to give it a try. At that stage, it wasn’t about money — the idea itself resonated. The project ran on interest and trust.
This is one of the key advantages of having no budget: you become extremely selective about your team. When there’s no money, everything depends on people — their motivation, engagement, and responsibility.

Lack of budget also changes how you scale. With limited resources, you can’t do everything at once. You constantly prioritize what matters now versus what can wait. This becomes critical when user feedback starts coming in. You get many ideas — new mechanics, features, expansions. But large features require time and resources. A wrong priority can waste both.

So we often chose a different path: small improvements with immediate impact on user experience. This is not rapid scaling — it’s refinement of the core idea.

A clear example is recommendations. Early users liked the concept but struggled to fill their wishlists or choose gifts. They needed a place for inspiration. We saw this pattern and built a simple recommendations section. The first version was minimal — I manually curated ideas, defined categories, and set principles for useful gift suggestions.

Over time, this evolved into a full product direction. Today, a 17-person editorial team led by an editor-in-chief works on it. Recommendations have become one of our key differentiators.

In essence, lack of resources acts as a filter. You can’t spread yourself thin, so every decision is more deliberate.

Another point became clear later: investment requires skill — knowing where to allocate capital, what to prioritize, and what results are realistic. Early on, these skills are often missing. At the same time, funding shifts your mindset toward growth and scaling. That’s useful, but at early stages it can be premature — especially when you’re building a product driven by intrinsic motivation rather than revenue. There’s a risk of scaling before understanding what actually works.

We developed the product organically, alongside users and the market.

If I were starting now, I’d follow the same approach: build a concept, visualize the idea, and assemble a minimum viable product quickly. Today, this is easier — AI tools allow you to build an MVP in days.
But one thing hasn’t changed: the team.

Yes, a single person can launch faster now. But at the growth stage, the same challenges appear — scaling development, maintaining stability, expanding functionality. One person is no longer enough.
So I would still rely on people I trust, who apply strong modern practices in their work.

In summary, lack of budget doesn’t slow development — it defines a different operating model. You move at a sustainable pace, make more deliberate decisions, and stay closer to your intuition.

In our case, it wasn’t a limitation but a factor that enabled Ohmywishes to emerge, grow, and build a foundation for unlimited scaling.

Why a Lack of Budget Can Be an Advantage was originally published in Ohmywishes on Medium, where people are continuing the conversation by highlighting and responding to this story.

The pace of modern life — and simple human laziness — breaks the user journey that wishlist services like this rely on. Our team has long been receiving feedback that Ohmywishes users find it hard to get their friends to actually join. People don’t claim gifts simply because they can’t be bothered to sign up for yet another app or website.

On paper, the wishlist concept sounds perfectly simple: someone creates a list of wishes, shares it with friends, and their friends each pick one and claim it so nobody gives the same gift twice. In practice, everything falls apart:

So some of my more resourceful friends don’t bother — they find a workaround in… Google Sheets. The setup goes like this: create a spreadsheet with a list of gifts, add links, share access — friends jump in and write down who’s taking what. It works, but there are catches:

• The element of surprise disappears — the wishlist owner can immediately see who claimed what;
• Anyone with the link has full edit access — the spreadsheet can be accidentally (or not so accidentally) ruined;
• And have you ever tried to navigate a spreadsheet on your phone?!

Yet people still use it because it’s “the fastest way.” I’ve personally received links to spreadsheets like these more than once:

There’s also another option. Some people use wishlist services that allow claiming without registration (yes, those exist). You get a link and claim right away. Sounds convenient, but the same problems surface:

• Anyone can claim anything — or everything;
• There’s no way to know who did it, or why;
• If you claimed something and then changed your mind, you can’t undo it.

The result: two extremes. Registration pushes people away, and claiming without it creates chaos.

Like many good ideas, this one came to me mid-run — somewhere around kilometer seven of a ten-kilometer loop through the park.

What if registration didn’t feel like registration?

You open a wishlist link, pick a gift, hit “Claim.” Then what? Instead of a standard registration form — a small pop-up asking for just your phone number or email address. You get a link or a four-digit code back. One click — and that’s it, the gift is claimed.

Technically, it’s still registration: the user still creates an account. But now we’re not asking for any unnecessary information.

The sign-up process happens quickly and almost invisibly. Later, the user can come back to the wishlist — to change their claim or pick a different gift — by signing in again.

And an authenticated user is a potential future wishlist creator in their own right. All they have to do is fill out their profile and add their own wishes.

The short version: we studied user behavior, came up with an idea at the intersection of psychology and UI design, and found a simple solution to a big problem.

Your move, Excel.

Taking on Excel. How We Invented Quick Claiming was originally published in Ohmywishes on Medium, where people are continuing the conversation by highlighting and responding to this story.