The details change, but the way I handle it does not. Each scenario below follows this sequence.
Confirm the goal in the client's language before touching solutions. The goal is to earn trust and catch any misalignment early.
Structured questions across data, workflow, users, tech, and stakeholders. The answers scope the work; I would typically not pitch a solution in meeting one.
Two or three paths in a good, better, best frame, each with real-world comps the client can react to. Their reaction provides context on budget and level of complexity.
If necessary, each resolution closes with evaluation of process so the same problem cannot sneak back in.
"We're growing quickly and our current locations page is no longer working for us. As we expand from 50 to 100 locations, we need a better location finder experience."
Today the page is a single static list: no search, no filtering, no geolocation, and every update is manual. If we only fix the page, they hit the same wall at 150 locations. So the conversation anchors on where the data lives, who owns it, and how it flows, and the solution comes after clarity on the following is received.
Data source and ownership comes first.
Move locations into a structured CMS collection (Webflow CMS or a WordPress custom post type), power a filterable, map-driven finder, and auto-generate an individual page for every studio from the same data.
A purpose-built platform like Yext, Uberall, or Storepoint becomes the location data source of truth; powering the on-site finder while syncing listings to Google, Apple Maps, Bing, and Yelp simultaneously.
Location data flows via API from the franchise management system into a fully custom finder built for live data: real-time class schedules, open-now status, and availability.
CMS-driven location pages carry the SEO and brand experience; a listings platform handles data distribution everywhere else. Two things I raise proactively: governance (at 100 franchised locations, "who is allowed to edit what") and the steps to selecting a new platform: current-state pain, then data questions, then UX vision, then directional options. I do not pitch a solution in meeting one.
"We need all of this done before the trade show. These updates are important for the business and we can't miss the deadline. Can you help us figure out how to move forward?"
The setup: 20 of 25 retainer hours are already spent, the in-flight feature needs 15 more to complete and QA, and the client wants five additional enhancements live before the show.
But before reframing anything with the client, I check facts internally: were we clear in the original requirements, or did genuinely new scope emerge mid-build? And do we have the ability to pull in additional resources if the client wants to add hours? Only then do I go back to the client, and I lead with ownership.
"The scope grew when new requirements emerged during development and QA. We should have flagged the hour impact sooner, and I'll make sure you get that visibility going forward."
If there is a gap between what they expected and what they will get, I say so, own that it happened, and name what I am changing to prevent it. Then I pivot immediately to prioritization.
Finish the in-flight feature first: it is 80 percent invested, and abandoning it wastes the hours. Then rank the five enhancements by trade show impact and deliver the top one or two by front-loading next month's hours. Requires the client to cut scope.
A one-time change order adds the hours for the feature plus the highest-impact enhancements, with additional resources pulled in if availability checks out. Costs money, so I am upfront with the estimate and get sign-off before work starts.
Ship an MVP of the feature plus the most critical enhancements before the show within a modest overage, and schedule the rest as fast-follows immediately after. Trade shows rarely need all five things equally.
That is what prevents this exact frustration from recurring.
"We've outgrown our current website setup. Managing all of our franchise locations has become difficult and inefficient, and we're starting to question whether our current platform can scale with the business long term."
The client has jumped to "maybe we replatform." But every site is only as good as the set up and the workflows allowed. If there isn't structure around the content, utilizing reusable components or governing what is allowed to change, the breakdown will happen regardless of the platform. My goal is to help them identify where the true issues are, so we can prescribe the best next steps.
Questions can be sent in a questionnaire or discussed live.
"If we could give you centralized templates with structured, location-level content control, on any platform, would the platform itself still be the concern? Or is this really about workflow and governance?"
They may need a component-based, structured-content architecture, which could be a headless CMS, HubSpot, Webflow, or a rebuilt WordPress with ACF, modular components, and a location data strategy. The replatform decision comes after requirements conversation.
In every scenario, the stated ask was reframed into the underlying problem, so the solution solves future problems, as well.
When something goes sideways, I own it plainly, explain what changed, and name the fix. Clients forgive scope creep; they do not forgive surprises.
Good, better, best framing with real comps turns abstract decisions into things a client can react to, and every engagement closes with a process fix.