Hi all. First post here, hoping to get a bit of insight from this knowledgeable group!
I’m trying to create a meal subscription app, very similar to the function of Blue Apron, HelloFresh, GoodFood, ChefsPlate, Gousto UK, etc.
In essence, the user would subscribe to a plan with a set number of meals (i.e. 6 meals/week). They would then be taken to a page where they choose their meal selections for the upcoming week, but would only be able to select the quantity for which their plan allows (6 meal plan = choose 6 meals from the menu).
This plan would renew every week, and the user would be able to change their meal selections up to 4 weeks in advance prior to its renewal.
What I’ve determined so far (and I could be wrong here) is that I need to create these “plans” as a database, as well as Meals, users, etc. Meals would also need a date range (the date that the meal would be available on the menu and the date that it would be removed).
Can anybody provide any insight into the best way to set this up, from a database perspective and a flow/functional perspective that would allow the users to select the correct quantity of meals based on the number of meals in their plan, as well as integrating the element of commerce into this so it would renew each week, and they could manage their “weekly meal selection” from their own account dashboard?
Basically just looking for some overall guidance on this to see if it’s something that Bubble could be used for/prove out the functionality.
The main one to answer is the last one. Yes, bubble is a great tool for the functionality you are looking to build.
You could create plans and menus and then link them together or just set date ranges and only show the menus which are available that week. For instance an entry level plan would offer different choices from a higher level one.
You could subscribe the user to a plan and store the limit of meals in the plan data type. And check against this limit when accepting orders.
For good UX, you can allow a user to not only select meals but also see what they have ordered for the next 4 weeks.
Perhaps when a user tries to add their 7th meal, you can show a popup and invite them to upgrade to the next higher plan.
If you’re planning on using Stripe, they allow setting up subscriptions as well. Would be best to see how they do it and align your app to a similar data structure.
Ideally I was hoping to set a date range on the meal specifically, still need to figure out specifically how I would achieve this though.
I think my biggest hold up at this point is specifically figuring out how I would validate the # of meals selected inside the plan. And I how I would “add” the meal when the “add” button gets clicked.
I have been emulating a similar approach to Bubble’s “how to make an Instacart” approach, adding meals to the database and assigning them to different packages, then using the repeater inside the necessary package.
But I can’t quite figure out how to “add” the user’s selection to the package, then how to validate that number against the Package’s “meal quantity”.
Any thoughts on how this could be achieved?
Glad to hear Bubble can be used for something like this!
Your database would have Plan, Meal, User, Order at the least.
Plan - details on the plan, pricing, # of meals allowed, etc.
Meal - name, description, picture, etc. of the various meals available, along with a Start and End date for triggering availability
Order - actual meals ordered by users (add a field in the User linked to a list of Orders)
User - store the Plan that they are on
When the user logs in, use the current date to show only those meals where the start date > current date and end date < current date. This way, the user can only see meals that are available.
Then, when the current user clicks on the Add button, create a new thing in the Meal data type and if the number of things for that user exceed the # of meals allowed, disallow the operation or suggest a plan upgrade.
How do you suppose I would go about dynamically displaying “future” meal items/menus then? If I’m using a condition of Meal Start Date > today > Meal End Date, that makes perfect sense. But how do you propose I’d go about showing menu items that are 3 weeks away from today’s date, so that they could choose their meals a couple of weeks in advance?
Perhaps use just the start date in your filter and ignore the end date.
Then sort the meals by start date or week so that the user sees the meals available to order for the current week, followed by the ones available in the next week, the next one and so on.
Do you have a link to your app that you can share? Would be easier to guide you.
I honestly haven’t made it quite that far yet, but I’ll share as soon as that aspect is available.
Primarily struggling with adding meals to the plan/package, then the plan/package to cart/checkout right now. Can’t seem to figure out how the data needs to flow to make functional sense. Haven’t even go to the validation of # of meals added yet.
I.e. User goes to the “Choose Meals for Your Plan” page > clicks the + button on the meal to “add” it to the package, then proceeds to checkout with their plan, including the current meal selections. Any thoughts?
Looks good, the pictures are really nice. I’m hungry now Especially love the lemon grilled chicken, looks yummy.
From a flow perspective, what is the user experience going to be?
(A) Choose 9 meal plan > Pay for Plan > Signed In > Choose Meals for each week
-OR-
(B) Choose 9 meal plan > Choose meals for each week > Add to plan > Pay for Plan
Looks like you are planning to do (B) - is that right?
Hey, I’m willing to give you an hour of my time at no cost if you like. We can hop onto zoom and I can help you figure this out with the app editor open. What time zone are you in? I am in Toronto, which is EST.
Admittedly, still a bit undecided on the actual flow. A lot of the bigger meal kit companies go with Flow A: Choose Plan > Pay for Plan > Choose Meals (and inside this dashboard, they have some meals that are additional costs, some extras/add-ons, that are more “one-time” purchases too).
I’m just west of Hamilton, so not far from you at all. I’m around this evening after 5pm, otherwise, any time tomorrow works too? I really appreciate the help with this, a ton.
Hey, @apottruff I’m building the same thing. Essentially a more localized version of the main competitors you mentioned in the original question. Your design looks really great! Admittedly way better than mine .
I’m still having trouble with my data structures, but what I did differently than you, which may be helpful, is set the subscription plans as option sets rather than its own data type. Then include “# of meals” and “price per meal” as an attribute for each option.
My data types are:
User: email, name, subscription, … etc.
Cart: # of meals (num), Cart items (cart item data type) (list), customer (user data type) , delivery date, delivery time, pickup/delivery?
Cart Item: cart (cart data type), meal (meal data type)
Meal: title, calories, carbs, fat, protein,… etc.
Order: customer (user data type), delivery date, delivery time, meals ordered (cart item data type) (list), # of meals (num), pickup/delivery?,… etc.
To have the user select the correct number of meals based on their plan, I made the following workflow:
When: “button + is clicked”
Only When: “Current Page Cart’s” “# of meals”>Current User’s Cart’s Cart Items:count
Create new thing: Cart Item; meal = Parent group’s meal, cart = Current Page Cart
Make changes to a thing: Thing to change: Current Page Cart; Cart items add Result of Step 1.
Hope this helps. I’d love to see how you design your workflows, I might be able to learn a thing or two from your set up as well! I’m still very much a newbie!
Thank you! This is greatly appreciated. I’m going to give this a shot later today and see if that helps at all. How are you planning to handle delivery dates/order deadline dates?
Admittedly, we have a cumbersome and truly quite frustrating delivery setup. Because we only deliver in specific provinces right now, I need to disable the ability to purchase if we don’t delivery to a specific province/country, first and foremost.
Secondly, we delivery every Monday for a list of cities in British Columbia, and every Tuesday for all other cities in British Columbia - then the same concept for Ontario as well: Monday delivery’s = a list of cities in Ontario, Tuesday deliveries = all other cities in Ontario that are not “Monday Delivery” cities.
I’m thinking the best way to approach this is some sort of Delivery Zones list that references the delivery address, checks for the city & province, then provides an outcome of when their meals will arrive each week. Though I’m not entirely certain that’s the best approach either.
@apottruff - for a marketplace I built a couple of years ago, I extracted the City and Province from the address entered by the customer. Then, I searched this combination against a data type where I stored the Province+City to see if we served that Province+City or not. You could store the delivery day of the week in this data type.
If we didn’t serve the area, a popup asked the visitor to add their name to our waiting list to be notified when we start serving their area (a great way to build up the business and see where demand is coming from). Could you do the same?
Creating a data type to store City+Province+DeliveryDay would give you the flexibility to easily add new areas to your service as well as alter delivery days if needed.
Especially love the lemon grilled chicken, looks yummy.
.