How to run a build-a-box meal subscription on Shopify

Updated July 2026 · 7 min read

A build-a-box subscription lets each customer assemble their own recurring box from your catalog: pick 10 frozen meals, mix 15 baby food pouches, choose this cycle's snack lineup. It's the natural model for any food business with a stable range — and it's surprisingly awkward to set up on Shopify, because the pieces live in three different app categories. This guide covers the product structure, the subscription mechanics, and the renewal behavior that decides whether subscribers stay.

What a build-a-box subscription really is

Three things have to work together on every order:

• A box product — the thing customers actually subscribe to, with variants for box size (10 meals / 14 meals, or 5 / 10 / 15 pouches). The variant price is the subscription price.
• Item products — the individual meals or pouches customers choose from. Each is a normal Shopify product with its own photos, description and inventory.
• A selection step — the UI where the customer fills the box, and the data that carries those picks into the order so your kitchen or warehouse knows what to pack.

The first two are standard Shopify product modeling — if you haven't structured them yet, start with how to structure meal plans and meals as Shopify products and why the plan should be a dedicated bundle product. The third piece is where stores usually get into trouble.

The three-app trap

Search the App Store for "build a box" and you'll find plenty of bundle builders; search "subscriptions" and you'll find plenty of billing apps. The common result is a stack stitched together from parts:

• a page builder or bundle app renders the box picker on the product page,
• a separate subscription app handles recurring billing,
• and nothing connects the customer's picks to renewals or fulfillment — so packing lists live in a spreadsheet and "can I swap next box?" becomes a support email.

The picker is the easy 20%. The operational 80% — what happens on the second order and every order after it — is exactly what the stitched stack doesn't cover.

Renewals: the part that decides retention

On the first order, every build-a-box experience looks similar. The difference shows up at renewal:

• Repeat last picks by default. An evergreen subscription should behave like a standing order — customers who do nothing get their usual box, and no box ever ships empty.
• Make changes self-service. Swapping items in the next delivery, skipping a cycle, or pausing entirely should happen in a customer portal, not over email.
• Have a discontinuation policy. When you retire an item that's in someone's saved box, replace it automatically on renewal and tell the customer — a silent gap in the box is how you lose them.

Menus without dates, deliveries with dates

Build-a-box stores almost always want an evergreen menu — one selection that doesn't change by calendar week (the full comparison: weekly menu vs evergreen menu). But evergreen only removes dates from the menu, not from fulfillment: each delivery still has a real delivery day and an order cutoff, so your warehouse knows when a box is locked and what to pack. Delivery-zone rules by postal code apply the same way they would for a weekly-menu store.

Setting it up in Servd

1. Create the box product with a variant per size (for example 5 / 10 / 15 items) and its subscription selling plan.
2. Create or reuse the item products customers pick from.
3. Build one menu template containing every pickable item, and enable evergreen mode with that template.
4. Set delivery days, cutoffs, and (if you deliver locally) delivery zones.
5. Enable the app embed so the box picker appears on your storefront, and place a test subscription: check that your picks show as line items on the order, then that a renewal repeats them.

From there, changing your range is just editing the template — new customers see the updated menu immediately, and existing saved boxes keep what was stored until their owners edit them.