The wishlist app I wanted did not exist

I was already using a wishlist app. It worked, in the strictest sense of the word: I could add something I wanted, keep a link to it, and share the list with other people.

But every time I used it, I noticed another thing I wished it did differently.

I wanted more control over the information attached to an item. I wanted several lists with different sharing options. I wanted proper states for wishes that were received or no longer relevant instead of treating everything as either present or deleted. I wanted people to reserve gifts without revealing the surprise. I wanted adding a product from another website to feel quick, but still let me check and edit what was captured.

And, honestly, I wanted it to look better.

Eventually the list of things I wanted from my wishlist app became long enough that the obvious thought arrived: I could build my own.

You can open Wishly here or look at a shared list.

The public side of Wishly: enough information to choose a gift, without giving away who reserved it.

Starting with the app I wanted to use

The goal was not to reproduce the app I already had with a different logo. If I was going to build a wishlist, it needed to fit the way I actually think about gifts.

A wish is not always one product with one perfect URL. The same thing can be available from several shops at different prices. Sometimes I know exactly what I want; sometimes I only have a description and will decide later. Some ideas are important, some are casual, and some stop being relevant without needing to disappear forever.

Sharing also has more nuance than a single public switch. I wanted private lists, unlisted links that I could send to specific people, and public lists when that made sense. A visitor should be able to reserve a gift even without an account. The owner should know that an item is taken, but not who took it. If a guest changes their mind, they should have a private way to cancel.

The customization I wanted was not a giant settings screen or a choice of decorative themes. It was the ability to shape a list around real situations:

• several wishlists instead of one permanent bucket;
• multiple offers and an optional preferred shop;
• prices that can be present, absent, or use different currencies;
• priorities, statuses, filtering, ordering, archiving, and restoration;
• private, unlisted, and public sharing;
• manual entry or an editable draft prepared by a browser extension.

The visual side mattered for the same reason. A wishlist should feel pleasant to browse, especially for someone opening a shared link on their phone. It should show the product, shop, price, availability, and next action without making the visitor decode the interface.

A personal product became a multi-agent experiment

At the same time, I wanted to try a more ambitious approach to multi-agent development.

Space View had already taught me that several agents can move very quickly when the work has clear seams. It had also taught me what happens when the instruction is too broad: each part can be reasonable on its own while the finished product quietly disagrees with itself.

Wishly was a good next test. It had a website, a backend, a database, authentication, sharing, guest actions, concurrent reservations, history, and a browser extension. Those parts could be developed separately, but only if they shared the same understanding of the product.

So I did not begin implementation with “build me a better wishlist app.” I began by trying to write down what better meant.

The initial prompt had to carry the product idea

The first prompt described more than features and technology. It described the people using the app, what each person should be allowed to see, how a wish moves through its lifecycle, and what should happen when two actions arrive at the same time.

It separated the first version from later ideas and from things I explicitly did not want to build. It defined the privacy promise around reservations. It covered the difference between website sessions, guest management links, and browser-extension access. It made room for missing prices, several offers, reversible states, and stable shared links.

That initial prompt eventually became 22 implementation tasks, six independent review tasks, eight verification tasks, and twelve recorded architecture decisions. Each implementation task had a bounded area, named dependencies, owned files, acceptance criteria, test commands, likely pitfalls, and an expected hand-off.

The agents could work in parallel because the product decisions and boundaries were shared first.

The prompt was not there to tell every agent how to write every line. It was there to stop them from independently inventing different versions of the application.

Give every agent a territory

One rule was especially useful: no two agents owned the same implementation files.

Authentication, database foundations, wishlists, items, reservations, history, the website, and the browser extension each had a clear owner. An agent could read the contracts around its work, but it could not casually rewrite another part to make its own task easier. Changes to shared surfaces had to be coordinated.

Review was also separate from implementation. Finishing a task meant it was ready for somebody else to inspect, not that it was automatically approved. Integration and verification were separate again. “The code exists,” “the code was reviewed,” “the pieces work together,” and “the product is ready to release” were deliberately different statements.

This required much more preparation than giving several agents a list of features. Once implementation started, that preparation paid for itself. Work could happen in parallel without every agent standing in the same files or making incompatible assumptions.

The plan still had to meet reality

A detailed prompt did not produce a perfect application in one pass.

Real startup exposed framework problems that compilation did not. Transaction behaviour changed when code ran through the complete application. Public-list reads, security-filter ordering, and browser-extension details needed fixes after integration. Even the build process needed coordination because several backend agents shared the same output directory.

The plan was valuable because it gave those failures somewhere to belong. A problem could be traced to a contract, an owner, a test, or a hand-off. It did not remain a vague feeling that the project was almost working.

The final local verification ran 44 backend tests against PostgreSQL, compared the running API with the frozen contract with zero drift, exercised owner, buyer, guest, and other-user journeys through real HTTP, and built the website plus both browser-extension targets. Reservation tests included simultaneous claims, because a reservation feature is only correct when two people want the same thing at the same time.

The small screen tells the truth

The desktop layout can show a whole shared list at once. The phone view is closer to the real moment: somebody opens a link from a message, looks through the ideas, and decides what to reserve.

The same list, reduced to the information and action that matter for one gift at a time.

That view is a useful reminder of why I started the project. The implementation underneath includes authorization rules, concurrency control, history, and several kinds of credentials. The person choosing a gift should not have to care about any of that. They should see a pleasant page and understand what to do next.

Building the alternative

Wishly started because I was using something that was nearly useful to me, but never quite felt like mine. Instead of continuing to collect complaints, I turned them into product decisions and built the alternative I wanted.

The multi-agent experiment came after that decision, and the order matters. The agents were not a reason to invent a project. They were a way to develop a product whose purpose and details I already cared about.

The biggest lesson was that a good initial prompt is not mainly about commanding agents. It is about understanding the product well enough that many agents can contribute without losing the original reason for building it.

I now have a wishlist app that I can keep adapting as my own needs change. I also have a development approach I trust much more than “send a big prompt and hope the pieces agree.”

Visit Wishly →