La Marie Beauty — Scope Definition & Budget

Overview

The La Marie Beauty booking integration project has stalled due to a fundamental mismatch between what Bookly provides out of the box and the highly customized booking experience the client (Lisa Frommelt) envisions. This article captures the decision framework established in the December 16, 2025 project reset call, the critical technical blocker, and the two paths forward being evaluated.

See also: ^[1] | ^[2]

The Core Scope Problem

Bookly is designed as a plug-and-play scheduling plugin. La Marie Beauty's requirements are not plug-and-play. The gap between these two realities is the root cause of the project's extended timeline and scope creep.

Specific friction points identified:

• Service variants: Lisa wants variant-style service selection; Bookly's native approach is a flat list. Bookly does offer "compound services" as a potential workaround — not yet fully evaluated.
• The "Flash Services" page: A single Bookly booking form that exposed every possible service overwhelmed and frustrated the client. Bookly's "custom service-specific forms" feature may resolve this by scoping forms per service category (e.g., one form for all microneedling options).
• Visual styling of booking tiles: Lisa dislikes the default Bookly tile UI. Whether this is addressable within Bookly's customization limits or requires custom code is still under investigation.
• Square as source of truth: Lisa's longer-term product vision (a separate SaaS layer) requires Square to remain the authoritative data source. This constrains how much logic can live inside Bookly's WordPress plugin.

Critical Technical Blocker: Credit Card Tokenization

This is a go/no-go requirement. The project cannot launch without it.

What's needed: Save a credit card on file at booking time (charged $0) so that staff can later charge a cancellation fee against the stored token.

Current status: Eshock (Asymmetric's developer) built a custom PHP integration against the Square API to handle tokenization. As of the Dec 16 call, it is not working. The integration routes through WooCommerce — the token flow is Bookly → WooCommerce → Square API — and has been failing at some point in that chain.

History: This blocker has surfaced at least twice. Chris Ostergaard (previous Asymmetric lead, now departed) also flagged it as non-functional before leaving the project.

Required next step: Eshock must provide a written summary or Loom walkthrough of:
- What approaches have been attempted
- What specifically failed and why
- Whether he is actively blocked (no remaining ideas) or still has avenues to explore

Kimberly Gehrmann will email Eshock directly (CC: Melissa Cusumano) to request this. A Loom is explicitly acceptable.

Decision Framework: Two Paths Forward

The Dec 30, 2025 one-on-one between Melissa Cusumano and Kimberly Gehrmann is the decision gate. The technical report (due Dec 26) will inform which path is viable.

Path A — Launch with Bookly Defaults, Scope Custom Work Separately

• Ship the site using Bookly's native capabilities (with whatever customization is achievable within the plugin)
• Accept that the result will not match Lisa's full vision
• Scope a separate Statement of Work for custom development to address the gap
• Asymmetric's custom dev team (led by Dimitri) is a candidate for that SOW, given their existing project knowledge

Pros: Closes the current engagement, delivers something live, preserves the investment already made in Bookly.
Cons: Lisa will not be fully satisfied with the initial launch; requires a follow-on contract and budget commitment.

Path B — Abandon Bookly, Custom Build

• Discontinue the Bookly integration entirely
• Build a fully custom booking flow (potentially as a micro-frontend embedded into WordPress)
• Could leverage offshore dev resources at lower hourly rates (~$45/hr India-based teams Kimberly has relationships with, or Asymmetric's own custom dev team)

Pros: Can be built to Lisa's exact specification; aligns with her longer-term SaaS vision.
Cons: Significant additional cost and timeline; discards months of Bookly integration work; requires Lisa to approve new budget.

Scope Boundary Principles

From the Dec 16 discussion, several principles were made explicit for the upcoming negotiation:

1. What was sold matters. Bookly was what was sold to Lisa. Features outside Bookly's native capability are, by definition, outside the original scope — regardless of how much Lisa wants them.
2. Nobody will be perfectly happy. The negotiation goal is a workable middle ground, not full satisfaction on all sides.
3. Money already spent is a factor. Months of investigation and Bookly add-on purchases have been made. A go-live with Bookly's defaults preserves that investment; abandoning Bookly does not.
4. Rox (Roxana Lopez) cannot maintain custom code. Once Eshock's custom PHP is in place, Asymmetric — not the client — owns maintenance. This is a long-term support consideration.
5. Square must remain the source of truth. Any architecture decision must preserve Square as the canonical data source for services, staff, and products, to support Lisa's future SaaS plans.

Key Decisions from Dec 16 Call

Action Items

• [ ] Kimberly — Sync with Lisa (Dec 22) to align on vision and gather her priorities
• [ ] Kimberly — Deliver technical report covering Bookly capabilities, WooCommerce integration, and tokenization status to Melissa and Lisa (by Dec 26)
• [ ] Kimberly — Email Eshock directly requesting a summary of all Square API tokenization attempts (written or Loom)
• [ ] Eshock — Provide summary of tokenization work: what was tried, what failed, current blocked/unblocked status
• [ ] Melissa — Review technical report on Dec 26; consult with Eshock and Mark as needed
• [ ] Melissa + Kimberly — Attend team sync Mon Dec 29, 3 PM
• [ ] Melissa + Kimberly — One-on-one Tue Dec 30, 11 AM to finalize scope, budget, and path forward

Generalizable Insight

When a plug-and-play tool is sold to a client with custom ambitions, the scope gap will surface late — usually after significant investment. The healthiest resolution is an explicit decision gate: define what the tool can deliver, document what it cannot, and force a binary choice (ship what exists vs. fund a custom build) rather than continuing to stretch the tool indefinitely.

This pattern has appeared in other Asymmetric projects. See ^[3] for related examples.