Service Variants & Scope Creep — La Marie Beauty
Overview
During a technical review of the La Marie Beauty booking system, the team discovered that service variations (e.g., microneedling on "face only" vs. "face & neck" vs. "face, neck & décolleté") had always existed in Square but were never surfaced as grouped variants in the initial data specification delivered to the development team. As a result, the team built separate, fully-realized pages for each variation rather than treating them as variants of a parent service — significantly increasing scope and complexity without a formal change order.
This case illustrates a recurring risk in client projects: data handoff format determines build decisions, and when a client's internal data structure is not communicated in a way the development team can interpret, unplanned scope accumulates silently.
What Happened
The Data Spec Problem
The client (La Marie Beauty) provided an initial product/service spreadsheet as a flat list — each line item was a separate row, with no grouping or parent-child relationships indicated. The development team took this at face value and built individual pages for each line item.
In reality, Square had always stored these as variants under a parent service. For example:
- Classic Microneedling (parent)
- Face only
- Face & neck
- Face, neck & décolleté
- Single area
The client's team (Roxana) noted that this structure was visible in Square's own booking flow, but the format of the delivered spreadsheet obscured it:
"The original spreadsheet just had like a dump and each line item was a different one. But they've always existed as a variation."
— Roxana Lopez, La Marie Beauty
Why the Gap Occurred
Two contributing factors:
-
Client-side: The LMB team member responsible for the data export had no prior experience with web development and could not anticipate what format would be meaningful to a build team. She delivered what she had — a raw export — without knowing that grouping and hierarchy mattered.
-
Agency-side: The development team did not perform an exploratory review of the Square account or its live booking flow before beginning the build. Had they done so, the variant structure would have been immediately apparent.
"A little bit more exploration of Square and like even how to book a service from the beginning would have been [helpful] because our Square website, if you go through the booking process through the Square link right now, it currently has variations."
— Roxana Lopez
Scope Impact
Because each variation was built as a standalone page rather than a variant selector on a parent page, the resulting pages became "very large and robust" — far exceeding what would have been required for a simple variant UI pattern.
Melissa Cusumano (Asymmetric) flagged this directly:
"When we initially kicked this Bookly project off, it truly, in my mind and from that document, is Bookly. And then I started thinking, oh, we could add some of the variants. But now those variant pages have become very large and robust versus just making it a variant. So I'll just flag that I do think that we can't eat that, as that was a creep, technically."
This positions the variant pages as out-of-scope work relative to the original contract — work that was done in good faith but was not explicitly authorized.
Key Decisions & Next Steps (from this meeting)
| Owner | Action |
|---|---|
| Kimberly Gehrmann | Analyze a Square data dump to understand the actual service variant structure and IDs |
| Melissa Cusumano | Provide Kimberly with the original project contract for scope review |
| Team | Determine whether variant pages constitute billable scope creep vs. included work |
Lessons & Generalizable Patterns
1. Flat data exports hide hierarchy
When clients export data from systems like Square, Shopify, or similar platforms, the export format is often a flat list. Development teams should always request a live walkthrough of the source system (or perform one independently) before treating an export as the authoritative data spec.
2. Scope creep can be structural, not behavioral
Neither party acted in bad faith here. The scope expanded because a structural assumption (flat list = flat pages) was never validated against the source system. This is a process gap, not a communication failure.
3. Variant UI decisions have downstream integration consequences
Choosing to build variants as separate pages vs. a selector on a parent page is not just a UX decision — it affects URL structure, booking system integration (which IDs get passed), and Square API calls. This decision should be made explicitly, with awareness of the full stack.
4. Establish data format requirements before client handoff
Agencies should provide clients with a data template or intake format that makes hierarchy explicit (e.g., "Parent Service / Variant Name / Price / Duration") rather than accepting raw exports and interpreting them independently.
Related
- [1]
- [2]
- [3]
- [4]