Internal technical review call with the La Marie Beauty team to surface and diagnose integration roadblocks in the booking system build. The meeting surfaced that the Zapier/Bookly/Square integration path is unworkable, that the proposed five-system architecture is over-engineered, and that service variants in Square were never properly communicated in the original data handoff — creating a potential scope creep issue.
Attendees:
- Melissa Cusumano (Asymmetric)
- Chris Ostergaard (Asymmetric)
- Mark Hope (Asymmetric)
- Kimberly Gehrmann (external consultant)
- Katie Schueller, Lisa Frommelt, Roxana Lopez (La Marie Beauty)
Zapier integration is dead. The Zapier connector between Bookly and Square pulls incorrect data — wrong availability, wrong product IDs, some IDs unresolvable — making it impossible to create appointments in Square via this route. This path is abandoned.
Square remains the single source of truth. All inventory, payments, and staff scheduling must continue to live in Square. Any architecture that displaces Square as source of truth is a non-starter, particularly given the risk of corrupting in-store appointment availability.
Bookly is on a go/no-go clock. The team will make a formal go/no-go decision on whether Bookly remains in the stack. The goal is a unified cart experience — Bookly is a means, not the end. If it cannot be made to work, it will be replaced.
Service variants are flagged as scope creep. Variants (e.g., microneedling — face only vs. face & neck vs. face, neck & décolleté) have always existed in Square but were delivered to the dev team as flat line items in a spreadsheet, not as grouped variants. The team built separate pages for each, adding significant complexity. Whether this constitutes billable scope creep requires contract review.
The current proposed stack involves five systems: Square, Bookly, Zapier, WooCommerce, and Google Calendar. Kimberly flagged this as a significant red flag:
"I've heard Square, Bookly, Google Calendar, Zapier, WooCommerce. So we're on five things. And that is sending alarm bells off in my brain about overengineering this."
Key risks identified:
- Circular dependencies between systems for availability data
- Single point of failure risk on appointment availability — a sync error could corrupt in-store scheduling
- No clear source of truth for staff scheduling (Square? Bookly? Google Calendar?)
The working hypothesis is a Bookly → WooCommerce → Square flow, where:
- Bookly handles scheduling UI
- WooCommerce handles checkout (enabling unified cart for products + services)
- Square remains the payment and data backend
Challenge: Bookly does not natively push appointments into WooCommerce. This connection still requires a solution. WooCommerce ↔ Square for products works natively (no Zapier needed), which is a positive signal.
Roxana (La Marie Beauty) confirmed that service variants have always existed in Square — e.g., classic microneedling has sub-variants by treatment area (face, face & neck, face/neck/décolleté, single area). These were not new additions.
What went wrong: The original data handoff was a flat spreadsheet with each variant as its own line item, not grouped under a parent service. The dev team built individual pages for each line item. The result is a large number of standalone service pages rather than a single service page with variant selection.
Melissa flagged this as scope creep from Asymmetric's side — the variant pages grew beyond what was originally scoped under the Bookly project. The original contract will need to be reviewed to determine what was and wasn't included.
Roxana's perspective: LMB had no prior website-building experience and didn't know how to format the data handoff. Earlier exploration of the Square booking flow (which already shows variants) might have surfaced this earlier.
| Owner | Action | Notes |
|---|---|---|
| Chris | Create architecture diagram of current and proposed data flows | Doesn't need to be formal — even a hand-drawn diagram is sufficient |
| Chris | Investigate WooCommerce integration path further | Focus on how Bookly appointments can flow into WooCommerce checkout |
| Kimberly | Review Chris's research document and add comments | Access granted during the call |
| Kimberly | Pull and analyze a Square data dump | Goal: understand actual service variant structure and ID mapping |
| Melissa | Provide Kimberly with the original project contract | For scope creep review against delivered work |
| Team | Schedule follow-up meeting | Agenda: go/no-go decision on Bookly; review architecture diagram |
Chris: "The data that Zapier pulls from Square doesn't necessarily seem to match what we need to create an appointment in Square, which is weird. So the data it pulls from Square doesn't match what is required in Square."
Kimberly: "Square should continue to remain the source of truth unless there is an extremely compelling reason for why not. A big danger in this project is mucking up the availability of appointments because if we get into a case of a go live and someone is unavailable and books an appointment or books an appointment and we mess up the actual in-store operations, that is concerning."
Kimberly: "Software, like my philosophy on software engineering, code, any third party thing is a tool to solve a problem. Right now, it's less important to me that Bookly is the solution."
Melissa: "You look at the Bookly website, and it's like, oh, it works perfectly with Square and all this stuff. And once you get into it, it doesn't."
Roxana: "Our Square website, if you go through the booking process through the Square link right now, it currently has variations. So then being able to like see that and notice like, okay, they're going to have to select from these different choices."