“At Reducto I rebuilt the whole app end to end because the rough parts were everywhere, and at Lyft I shipped one screen that became the framework everything else built on.”

“I redesigned HotPads from the ground up when Zillow acquired it, but at Humble Bundle I fixed the bottleneck first: automating the production grind so the team could think strategically before touching the product. If the rough parts are eating your team's capacity, fix those first. A redesign without that breathing room becomes another emergency.”

“I wrote a whole Medium piece on this after watching engineers ship faster by slicing work. A full redesign feels clean but it usually buries the risk; I'd rather fix the roughest part first, measure whether the metric moves, and let that tell you if the rest is worth touching.”

“I shipped a full onboarding redesign at ClockShark in 90 days because the old flow was fractured across platforms and conversion was stuck at 5%. Fixing it piece by piece would have kept the debt hidden; the redesign made the system visible and lifted trial-to-paid 18%. If the rough parts are connected, redesign the system. If they're isolated, patch them.”

“I usually start by fixing the roughest parts, because a full redesign too often becomes a beautiful answer to the wrong question. At Fiber and Syndicate, the biggest wins came from shipping small fixes that revealed what users actually needed, not what we assumed was broken.”

“At CloudOn we had years of design and engineering debt, so we went for the full redesign, but only after we knew the exact risk of losing users to a new learning curve. If the rough parts are scattered across the same core flow, a redesign pays off; if they’re isolated, fixing them one at a time is the smarter bet.”

“I would fix the roughest parts first, because a full redesign usually hides the real problem under a fresh coat of paint. When we redesigned OS Maps, the wins came from untangling specific broken flows, not from starting over.”

“I usually push for fixing the rough parts when every new feature starts taking longer because the foundation is cracked. At BOLD I saw tacked-on features slow the whole roadmap down, so the question for me is whether the current pain is blocking the next few bets or just cosmetic.”

“I would map the actual failure points before deciding. At Assurant, we thought we needed a full redesign until research showed three clustered friction areas; fixing those moved the needle faster than any broad overhaul would have.”