Scope Creep & Budget Mismatch — LaMarie Case Study

Overview

A recurring pattern in client engagements is the gradual evolution of a client's vision beyond what the original budget and platform can support. The LaMarie project is a clear example: what began as a $5,000 WordPress/WooCommerce build grew into a request for a custom, flexible user experience that the chosen stack — and budget — could not accommodate.

This article documents the pattern, its root causes, and the recommended path forward when scope and budget diverge mid-project.

The Pattern

Clients often begin a project with a general idea of what they want. As the build progresses and they see the site take shape, their vision sharpens — and frequently expands. By the time the gap becomes visible, the team has already invested significant hours against the original budget, and the client may not understand why more money is needed.

Key signals that scope creep is occurring:

Client begins describing UX or feature requirements not in the original brief
Requests require platform capabilities beyond what was scoped (e.g., custom payment flows, complex integrations)
Third-party tools (e.g., Square, Bookly) prove inflexible against the new requirements
Developer time is consumed troubleshooting integration limits rather than building features

LaMarie: What Happened

The LaMarie project was scoped and budgeted at $5,000 for a WordPress site using Bookly, WooCommerce, and Square for appointment booking and payment processing.

Over time, the client's (Lisa's) vision for the site's user experience evolved significantly. By early 2026, the team was attempting to build a Bookly → WooCommerce → Square payment integration that Square's API fundamentally could not support. Unlike Stripe — which functions more like a programmable platform — Square is designed to be used as-is, with minimal customization available to developers.

"When somebody comes to us and says, oh, we have Square… we can connect it, but we can't make any modifications to how it works." — Mark Hope

Ishak (senior dev) attempted a custom code solution using API tokens but was unable to bridge the gap. A consultant was brought in to review the work and assess feasibility. The consultant's involvement will produce a new cost estimate, and the project will require a re-proposal at an estimated $10,000+.

The expanded scope also makes the current WordPress/WooCommerce stack insufficient. Viable alternatives discussed include:

Framer — more design flexibility than WordPress out of the box
Custom React/HTML — maximum flexibility, but significantly higher maintenance overhead

Why This Happens

Vague initial scoping. Early conversations capture a general direction but not a detailed feature list. Clients don't always know what they want until they see what they have.
Platform lock-in chosen too early. Committing to a stack (WordPress + Square) before fully understanding the client's long-term UX goals creates technical debt when requirements shift.
Budget anchoring. Once a number ($5k) is in the client's mind, any increase feels like a failure — even when the new scope is objectively a different project.
Incremental asks. Scope rarely explodes all at once. It grows through small requests that each seem reasonable in isolation.

Recommended Response

When a scope/budget mismatch is identified:

Stop the clock. Pause development on the contested feature until a new agreement is in place. Do not absorb the cost of unbounded exploration.
Document the gap clearly. Produce a written summary of what was originally scoped vs. what is now being requested. This protects the team and helps the client understand the delta.
Get an external cost estimate if needed. Bringing in a consultant (as with LaMarie) adds credibility to the re-proposal and removes the perception that the agency is inflating costs.
Present options, not ultimatums. Give the client a path forward at the current scope/budget and a path forward at the expanded scope/budget. Let them choose.
Re-propose in writing. A new SOW or change order should be signed before work resumes on the expanded scope.

In the LaMarie case, the planned sequence is:
- Consultant reviews Ishak's technical write-up → produces cost estimate
- Melissa and Mark align on pricing and platform options
- Melissa presents new proposal to Kim (client contact) with clear scope and budget

Platform Selection Implications

This case reinforces the importance of vetting payment processors and booking platforms before committing to a stack. Square's API rigidity is a known constraint. Future projects requiring custom payment flows, complex booking integrations, or evolving UX requirements should default to Stripe and consider more flexible front-end platforms (Framer, React) from the outset.