The problem
Buying a gift for someone is a small problem that never goes away. You know the person. You still have no idea what to get them. So you open three shopping tabs, scroll for twenty minutes and buy the same candle you bought last year.
The apps that exist treat this as a shopping problem. They show you a catalogue and hope something sticks. But the hard part is not finding products. It is working out what this particular person would actually like, from the handful of things you know about them.
Most founders are told a first version takes a team and two quarters. Giftlo is the counter-example, and it is the same process I run on client work: one person taking an idea all the way to a paid product on the App Store. Not a prototype, and not a demo video. Design, build, launch, store listing, subscriptions and review submissions, with nobody else on the project.
What I built
A gift finder you talk to, not a catalogue you browse. The centre of the app is a chat. You describe the person: their age, what they are into, the occasion, roughly what you want to spend, and it comes back with ideas you can act on. I chose a conversation over a filter form because the useful details about a person do not fit in dropdowns.
“Ask AI” on the product itself. Every gift idea opens into a detail screen with a question box attached. Would this suit someone who already owns one? Is this too much for a colleague? The answer arrives without leaving the screen. I built this after noticing the first version sent people back to the chat to ask follow-ups, which broke the thread they were on.
Wishlists, split by category. Ideas are only useful if you can keep them. Lists are grouped by category rather than by person, because most people collect gift ideas long before they know who they are for.
A QR code instead of a share sheet. Sharing a profile was originally a link. It became a QR code on screen, because the moment people actually swap wishlists is when they are standing next to each other: at a birthday, at a dinner, before a holiday.
Flutter on Supabase, with Superwall for subscriptions. One codebase, one backend and a paywall I could change without shipping a new build. That last part mattered more than I expected: getting pricing and paywall wording right takes several attempts, and each attempt should not cost a week in review.
The hard part
The model was too agreeable.
Ask a general-purpose model for gift ideas and it will give you five, confidently, every time, including when it has nothing to go on. Early on, “a gift for my dad” returned a wallet, a watch and a whisky set. Technically valid. Completely useless, and worse than useless, because a generic answer told the user the app had nothing to offer them.
The fix was not a better prompt. It was making the app willing to ask a question back. Now, when there is not enough to work with, the chat asks one specific follow-up before it suggests anything: what he does at the weekend, what he bought himself last. One question, not a form, and only when the answer would genuinely change the suggestions.
Getting that threshold right took the longest of anything in the build. Ask too often and it feels like an interrogation. Ask too rarely and you are back to the wallet and the whisky set.
The result
Giftlo is live on the App Store, built and shipped by one person in under four months, start to finish. That includes the parts most developers hand back to the client: the store listing, the screenshots, the subscription setup and the review rejections nobody warns you about.
I am not publishing download or revenue numbers here. They are mine to know and not yet mine to make a claim from, and a number on a portfolio page that cannot be checked is worth nothing to you.
What it does prove is the thing this page exists to prove. The distance between a working demo and a product a stranger can download and pay for is where most projects die. I have crossed it, on my own money and my own deadline, and I know exactly what is in that gap.
What I’d do differently
I built the wishlist before I built the chat.
It was the safer piece: well-understood, easy to scope, satisfying to finish. But it was not the reason anyone would open the app, and building it first meant the chat inherited data structures shaped around lists rather than conversations. I spent time later undoing that.
If I started again I would build the one thing the product is for first, badly, and let everything else form around it. It is the same advice I give clients on the first call, and I still had to learn it on my own product.