How can I design my database structure in Bubble for a laundry app to support features like pickup, wash tracking, delivery, and multiple cities?

[suheb.devtechnosys]

If I am building a laundry app using Bubble, how should I organize my data (tables, fields, relationships) so that the app can handle all its features — like scheduling pickups, tracking laundry status, managing deliveries, and supporting users from different cities — efficiently and without confusion?

[rpetribu]

ChatGPT gave me a very good answer…
Do you have any questions about how to implement it?

Core Data Types (Tables)

1. User

Represents customers and staff (drivers, admins, etc.).
Fields:

• name (text)
• email (text)
• phone (text)
• role (option set: customer, driver, admin)
• address (geographic address, or link to Address type if multiple addresses per user)
• city (link to City)
• orders (list of Orders – usually referenced from Order instead for efficiency)

---

2. Order

Represents each laundry job.
Fields:

• customer (User)
• pickup_address (Address)
• delivery_address (Address)
• pickup_time (date/time)
• delivery_time (date/time, optional until confirmed)
• status (option set: pending pickup, picked up, in progress, ready for delivery, delivered, canceled)
• driver (User with role = driver, optional until assigned)
• items (list of OrderItems)
• city (City, for filtering availability and logistics)
• price (number)
• payment_status (option set: unpaid, paid, refunded)

---

3. OrderItem

Breaks down an order into line items.
Fields:

• order (Order)
• service (Service)
• quantity (number)
• unit_price (number)
• total_price (number, useful for quick display)

---

4. Service

Represents the laundry services you offer (wash & fold, dry cleaning, ironing, etc.).
Fields:

• name (text)
• description (text)
• price_per_unit (number)
• unit (text: e.g., “kg”, “item”)
• available_in_cities (list of Cities)

---

5. Address

If customers or drivers may have multiple addresses.
Fields:

• label (text: “Home”, “Office”)
• street (text)
• city (City)
• coordinates (geographic address, for maps/routing)
• user (User)

---

6. City

Supports multi-city operations.
Fields:

• name (text)
• country (text)
• timezone (text)
• delivery_zones (list of geographic areas, optional)

---

7. DeliveryLog / OrderHistory

Keeps track of changes over time.
Fields:

• order (Order)
• status (status option)
• timestamp (date/time)
• updated_by (User)

---

Relationships & Best Practices

1. One-to-Many (User → Orders)
   Each order belongs to a single customer, but a user can have many orders.
   So: Order has a customer field (User), not the other way around.
2. Many-to-Many (Services ↔ Cities)
   Services can be offered in multiple cities. Use a list of City inside Service.
3. Order Lifecycle
   Track state changes with status (current) + DeliveryLog (history).
4. Drivers Assignment
   Store driver in Order.driver. If you need driver history, log it in DeliveryLog.

---

Option Sets (recommended for Bubble)

Use option sets for things that don’t change often:

• UserRole (customer, driver, admin)
• OrderStatus (pending pickup, picked up, in progress, ready, delivered, canceled)
• PaymentStatus

Option sets are faster than linked tables and cleaner for fixed lists.

---

Example Flow

1. Customer creates an Order → chooses pickup_address, pickup_time, and adds OrderItems.
2. Order status starts as pending pickup.
3. Driver is assigned → status changes to picked up.
4. Laundry team processes items → status in progress.
5. Once cleaned, set ready for delivery.
6. Driver delivers → status delivered.
7. DeliveryLog tracks each step for reporting.

---

Why this works well in Bubble

• Scalable: clear separation between User, Order, OrderItem, Service.
• Efficient: option sets for statuses and roles.
• Multi-city ready: everything tied back to City.
• History: DeliveryLog prevents overwriting and losing past info.
• Clean relationships: orders reference users, services reference cities.

[senecadatabase]

Not sure you can do better than the answer already given…

but something to remember for future use, Bubble does have ‘Build Guides’ to help you.

On the left side of your editor:

[rpetribu]

It’s funny because I’ve been here for years and never used this. . And now that you mentioned it, I ended up getting curious and went there to test it out… The prompt I used was exactly the same as the one I used in ChatGPT; I copied and pasted the @suheb.devtechnosys post.

I even went into each of these topics individually to explore, but the structure proposed by ChatGPT was actually much more complete in terms of resource utilization and scalability.

Anyway… curious, right?

[senecadatabase]

I did a deep dive into Bubble AI one day…

I concluded that it pulls from the component library to create pages. I also mentioned before that I wish we could save designs to the component library, which could be used in AI designs with Bubble. We all have our own way of designing. Some like big and bold, and others like more subdued designs.

Right now, as it is, I think the Bubble AI needs a lot of work.

I understand it’s harder to have a Bubble AI simply because of the way Bubble is built. It’s built on top of another framework with a lot of twists and turns.

IF Bubble can get its AI right, I think it will be awesome.

I do use other AI builders just for design ideas, etc. I think Floot is pretty good right now when it comes to AI builders. Still, it’s going to cost you about $300 to get an MVP built the way you want.

[fede.bubble]

@suheb.devtechnosys have you given Bubble AI a go to create your data types?