Here is the mistake founders make when they hear "baby registry fulfilment": they picture a warehouse. Boxes, shelves, a shipping label printer. That is not what a universal registry like Babylist is doing at all. The interesting problem is not moving parcels, it is deciding where each purchase goes and then keeping one list honest across dozens of stores it does not control. Fulfilment here is a routing and reconciliation problem wearing a shipping label.
The Two-Rail Fulfilment Model
The cleanest way I have found to explain how Babylist fulfilment works is what I call the Two-Rail Model. Every item a gift-giver buys travels down one of two rails, and the platform behaves like a completely different kind of company on each one.
Babylist reports that over nine million people shop with it each year, and they are added to registries from tens of thousands of retailers, including Amazon and Target. That single sentence is the whole fulfilment challenge in miniature. Some of those nine million check out through the Babylist Shop, where the platform is the merchant of record. Many buy the item at its original store, where the platform never touches the box. Both purchases have to land on the same list and decrement the same quantity, or the model collapses. If you want the money side of this, we break it down in how Babylist makes money.
Why run two rails at all?
You could build a registry that forces every purchase through your own Shop. It would be simpler to reconcile because you would process every transaction yourself. It would also convert worse. Gift-givers are not loyal to your Shop, they are loyal to completing the gift with the least friction. If the item is cheaper on the original retailer, or already sitting in a cart they trust, forcing them into your checkout is how you lose the sale.
So the universal registry makes a deliberate trade: it gives up control of some transactions to capture completion on all of them. On the Shop rail it keeps the full retail margin. On the retailer rail it accepts a thinner affiliate commission in exchange for never losing a buyer to friction. That is not a compromise, it is the strategy. The Shop versus original-retailer checkout decision is the single most important product choice in the whole model.
What everyone gets wrong: fulfilment is about boxes
The instinct, especially from founders who have run an ecommerce store, is to over-invest in the warehouse and under-invest in the ledger. It is backwards. On a universal registry the hard part is not packing the Shop-rail orders, that is solved retail. The hard part is the retailer rail, where you have to know that a purchase happened in a system you do not own, and reflect it on your list within seconds so nobody buys the item twice.
When someone buys on the retailer rail, your platform needs a signal to mark the item purchased: a confirmation redirect, a browser-side event, a periodic check, or a gift-giver simply tapping "I bought this." None of these is perfectly reliable, so you build for the messy reality that some purchases arrive late or not at all. This is exactly the reconciliation discipline that separates a real registry from a demo. I have watched teams build a gorgeous registry UI and then discover, three weeks after launch, that their "purchased" counts are quietly wrong because they trusted a single fragile signal. Reconciliation is not a feature you add later. It is the spine.
The three objects on one list
There is a second thing the box-centric mental model misses entirely. A universal registry does not only fulfil physical items. Babylist lets parents add cash funds and favor requests alongside products. That means your fulfilment system is really handling three different objects, and only one of them ships.
This is why the data model matters more than the warehouse. An item, a fund contribution, and a favor are three different shapes with three different fulfilment paths, and they all have to coexist on one list, in one purchased-or-not view, with one thank-you tracker behind them. Teams that model only "products" end up bolting funds on later as a hack, and it always leaks.
Tell us what you have in mind. We turn AI prototypes and fresh ideas into shipped, scalable products, from India, for the US and UK.
How we scope a fulfilment build
When we take on a registry-style project, we do not start with the UI. We start with the three questions that actually decide whether it works:
- What is the source of truth for "remaining quantity," and how does every rail signal it? This is the reconciliation core. We design it first, then everything else hangs off it.
- Which retailers are rail-one (your Shop) versus rail-two (routed), and how does each one confirm a purchase? Some retailers give you clean signals, others give you almost nothing, and your system has to survive the weakest one.
- How do funds and favors flow, including payout and tax edge cases? Money movement carries its own compliance weight, and it is cheaper to design in than to retrofit.
Then, and this is the part most cheap builds skip, we test the whole thing with internal mock orders before launch. We push a purchase down each rail, confirm the quantity decrements correctly, confirm the commission or margin is recorded, and confirm the thank-you data is captured. It is unglamorous and it is the difference between a smooth launch and a public one that double-ships gifts. Launching is about one percent of the journey anyway, the reconciliation you get right on day one is what keeps the registry trustworthy for years.
If you are weighing whether to build this yourself, our custom software team scopes the routing and reconciliation before anything else, from India for US, UK and EU founders, so the estimate you get reflects the real product and not just the screens. For the wider picture of how the pieces connect, the business model breakdown is the companion to this one.
Frequently asked questions
How does baby registry fulfilment work?
Baby registry fulfilment on a universal platform is a routing problem, not a warehouse problem. When a gift-giver buys an item, the platform decides whether that purchase flows through its own Shop (which it stocks and ships) or through the original retailer where the item actually lives, for example Amazon or Target. Babylist runs both rails at once, which is exactly why fulfilment there is more about reconciliation than about boxes.
Does Babylist hold its own inventory?
For items bought through the Babylist Shop, yes, that is a real retail operation with stock, packing and shipping. But the universal registry also lets parents add items from tens of thousands of retailers, and those purchases are fulfilled by the original retailer. So the honest answer is that Babylist is part real merchant and part affiliate router, running two fulfilment rails side by side.
What is the difference between the Shop rail and the retailer rail?
On the Shop rail the platform is the merchant: it takes the payment, owns the margin, and ships the box. On the retailer rail the platform is a router: the gift-giver buys at the original store, the store ships, and the platform earns an affiliate cut and marks the item purchased. Same registry, two completely different money and logistics flows behind one button.
How does a registry avoid duplicate gifts across so many stores?
The registry has to be the single source of truth for quantity remaining, no matter where the purchase happened. When an item is bought on the retailer rail, the platform needs a signal (a confirmation, a redirect, a purchase ping) to decrement the count so nobody buys the ninth onesie. Getting this reconciliation right is the hardest, least glamorous part of registry fulfilment.
How do cash funds and favor requests get fulfilled?
They do not ship at all, which is the point. Babylist lets parents add cash funds and favor requests alongside physical items, so a slice of the registry is fulfilled as money or as a promise rather than a parcel. That means your fulfilment system has to treat "an item," "a fund contribution," and "a favor" as three different objects that all live on one list.
Why do gift-givers sometimes check out on the original retailer instead of the Shop?
Because the item is cheaper, faster to them, or already in a cart they trust. A universal registry that forces everything through its own Shop loses those buyers. Babylist keeps both options open, which raises conversion but forces the platform to reconcile purchases it did not process itself. It is a deliberate trade of control for completion.
What does reconciliation actually involve on a registry?
Netting three things: what was marked purchased, what actually shipped, and what money the platform is owed (Shop margin on one rail, affiliate commission on the other). If those three drift apart you get double gifts, missing thank-you data, and revenue you cannot invoice. This is the same reconciliation discipline that makes or breaks any two-sided commerce build.
Can appico build a fulfilment system that routes across many retailers?
Yes, this is squarely the kind of multi-rail commerce logic we build from India for US, UK and EU founders, at a fraction of onshore cost. We scope the routing and reconciliation first, because that is the actual product, then wire the retailer integrations and test them with internal mock orders before launch so every field lands correctly in every system.
“Disciplined, committed, over-delivers. Three years in, I would re-hire any day.”
“A factory of ideas.”
“A fantastic-looking and performing website.”
Talk to the team, we reply within 24 hours, and the first consultation is free.
Start a conversation →