Direct answer
Every claim is sourced below
Growth-driven design asks for a continuing commitment of money and people, and that's its largest disadvantage for a team that can't sustain one. The others are narrower. Testing is slow on pages with little traffic, and priorities can drift when nobody has the authority to hold them. An existing site with a lot of content also needs a migration plan, which a small first release doesn't supply by itself. Which of these matter depends on your situation.
A conventional redesign is sold as a project with a launch date. Growth-driven design describes a first release followed by continuing improvement. How long that continues and how it's billed are set by the agreement you sign. The method only says the work goes on.
Rikki Lear's article on how the method goes wrong names the misunderstanding this produces. The mistake, in Lear's telling, is to treat a small first site and a short run of improvements as a shortcut to a finished website, possibly a cheaper one. Lear says the method should be approached as a long-term investment.
Lean Labs makes a cost comparison of its own. Its post on the three stages of growth-driven design says a first year of its engagement costs more than a single redesign from a comparable agency, since the year covers the build and the months of improvement after it. A budget holder who expects a cheaper website should see a comparison like that before the work starts.
Money is half of the commitment, and people are the other half. Suppose a 40-person software company has two marketers, and neither has spare hours in a typical month. Its site has 180 pages, and 120 of them are blog posts that bring in most of its search visitors. Its pricing page gets 500 visits a month and produces 10 demo requests. Suppose its agreement leaves approvals, content questions, reviews and sales feedback with those two marketers. Lear names content as the most common cause of delay on web projects. With a release every month, that work comes back to the two of them every month.
The way the work is billed can add a risk of its own. NP Group's critique of growth-driven design argues that a fixed block of hours each month changes how clients plan. In its account, clients start planning around the hours they have and stop planning around what the site needs. Busy months end with work undone, and slow months end with hours unused. NP Group says these agreements work when usage is steady and the terms for overages are agreed in advance.
So the terms are worth reading closely. Lean Labs' growth-driven design program, for example, renews each quarter and can be canceled at any renewal, which limits the commitment to three months at a time. We cover the other terms to look for in what a growth-driven design contract and retainer should include.
The method favors decisions based on data, and a counted result takes visitors. Consider how a controlled test works. HubSpot's page A/B test shows one version of a page to half the visitors and a second version to the other half.
Run that on our software company's pricing page. Each version gets about 250 visits a month and about five demo requests. Say the new version gets seven and the old one gets four. That difference doesn't establish a winner, because a gap of three requests can easily turn up by chance at those volumes. A longer run adds observations, though it comes with no guarantee of a clear answer. And any other change made to the page while the test runs muddies the comparison.
No single traffic number separates pages that can be tested from pages that can't. It depends on the visits a page gets, how often visitors convert and how large a difference you're trying to detect.
This limits quantitative testing. It doesn't stop the team from learning. Lean Labs' post says as much about its own service. For an early-stage company with little traffic, it suggests that a focused first build informed by what sales hears may suit it better than the full program. Interviews and sales calls help explain why buyers hesitate. They don't measure how far a change moved the number. A company in this position should expect more of its decisions to rest on judgment than on counted results.
Iteration has a second cost that applies at any traffic level. Lear notes that some experiments fail, and that executives who aren't used to this take it badly. Jakob Nielsen's paper on iterative interface design makes a related point about iteration in general. A revised version can introduce new usability problems, and some measures can get worse when a redesign concentrates on improving others. So some shipped work can need reversing, and that work was paid for.
Growth-driven design asks a team to hold a line on scope, and that takes authority. Lear's first warning is that the launchpad swells before it ships, as senior people ask for more pages and functions until the first release has become the full site. A later one is that ideas picked up from a trend or a networking event get passed down as requirements. Lear's fix is a strong person in charge of the project who keeps everything except the high-impact items on the wishlist.
That fix shows what the method depends on. Someone, or some agreed process, has to be able to keep a lower-impact item waiting. In our software company, suppose the chief executive adds a page most months and it skips the scoring. Each addition takes hours from the ranked work, and two marketers don't have many hours to give. Put new requests through the same prioritization as the rest of the list, with room for work the site requires whatever its score.
Drift can also be quiet. Lear describes teams that keep building new pages, and favors improving existing ones as the likelier source of quicker gains. A site that keeps adding pages can grow every month while its conversion rate stays where it was. We describe how to keep the list honest in how teams organize a growth-driven design roadmap.
NP Group argues that the launchpad idea suits a new website better than an existing one. Its reason is that a redesign involves migration. Everything on the old site has to be accounted for on the new one, and the search value those pages have earned has to be preserved.
Our software company shows where that bites. A small first release doesn't have to leave its 120 blog posts behind, since they can be carried across as they are. What the release can't do is skip the planning. Before launch, someone has to decide which posts move, which get redirected and which stay where they are. That work belongs in the first phase however few new pages it contains.
A change of platform makes the migration larger. Lean Labs' program is built for HubSpot CMS and offers to migrate a site that isn't on it as part of the engagement. For a company on another system, that move belongs in the scope and the price from the first conversation.
The first release also has to do its job with no retainer behind it. NP Group's test is whether the site would still serve its purpose if the ongoing agreement never happened. We'd put it more narrowly. Anything a customer has to complete must work on the first day. A checkout or a booking form that half works is broken, and calling the release a launchpad doesn't change that. Lean Labs describes its own launchpad as a complete site of three to eight pages chosen for their effect on the buying decision, and says it isn't a placeholder. We think that's the right standard, because a short list of finished pages can do its job on launch day.
Consistency is the last risk in this group. NP Group argues that a site improved in pieces needs design guidelines, or later work drifts from the original look. Lean Labs' post describes the launchpad design as a system of reusable components, so pages added later match without a fresh design each time. If you're comparing providers, ask whether a design system is part of the first release.
NP Group recommends the method for a new property whose owner would sooner spread the budget and wants continuing help. A company that matches that description has less to lose from the disadvantages above. We set out both sides of the decision in who should invest in growth-driven design and when it's the wrong fit.
A company in between has a smaller option. If you mostly want to improve the pages you already have, you can test changes to them without adopting the whole method. We explain that choice in the difference between growth-driven design and conversion rate optimization.
Our software company sits on the other side. Its two marketers have no spare hours, and its pricing page is too quiet for a quick test. We think a conventional redesign fits it better as things stand, with improvements made when the team has time for them. More traffic would ease the testing limit, and another person would ease the capacity limit. The 120 posts don't tip the decision, because their migration has to be planned under either approach.