If you’ve ever said, “We should’ve done this six months ago,” you’re not alone – and it’s not your fault. In this blog, we explore why late-stage design is one of the most expensive problems in product development – and how shifting the sequence (not just the speed) changes everything.
Why “We Should’ve Done This Sooner” Is a Symptom, Not a Mistake
If I had a penny for every time I heard a team say, “We should’ve gone through this process six months ago,” I’d have a drawer full of pennies – plus proof of just how common (and costly) late-stage design regret really is.
The story’s usually the same: the team moved fast. Code got shipped. And only after the product was live, users were confused, and support tickets were piling up… someone said, “Wait. Did we build the right thing?”
It wasn’t that the team moved recklessly. They just moved without design at the table from day one. And when design comes in late, it’s not just an oversight – it’s a signal that something deeper is off in the product culture.
Why It Keeps Happening
We get it. Teams are under pressure to build, to deliver, to show progress. Devs are ready to go, product managers are moving features along, and design often gets seen as the polish – not the planning.
But here’s what we’ve learned at Pepperplane after working with dozens of scaling teams: when design and development work together from the start, everything changes. And not just visually – but structurally, strategically, and financially.
We’ve seen the difference it makes. And we’ve built our entire practice around bridging the gap that most teams don’t even realize is hurting them.
What Happens When You Flip the Sequence
I started my career as both a designer and a front-end developer. Which means I’ve spent years watching the friction play out in real time.
Designers asking for space to think. Developers needing to move yesterday. Two disciplines speaking different languages, trying to solve the same problem from opposite sides of the screen.
That’s why I started Pepperplane – to create a space where design and development collaborate, not compete. Because when those worlds meet early, something incredible happens: clarity.
Developers focus on building things right – efficient, scalable, stable. Designers focus on building the right things – intuitive, meaningful, useful. Together, they make products that work and resonate.
It’s like building a house. You can pour a perfect foundation and frame the walls just right… but if it’s confusing to live in? You missed the point.
We always ask: Are we building the right thing – before we build it right? That one question has saved teams months of rework, thousands of dollars, and a lot of late-night bug fixes for features that should’ve never made it out of design.
The Real Cost of Late Design
By the time most teams bring us in, the product’s already live. Users are frustrated. Devs are firefighting. And decision-makers are scrambling to make sense of drop-offs, churn, and “why doesn’t it just work?”
This is when design debt becomes business debt.
Let’s say a usability bug could’ve been fixed for $400 during the design phase. If you catch it during development? That jumps to $4,000. Catch it after launch, in a product users already mistrust? Try $40,000 or more.
Every stage multiplies complexity. More hands on the code. More systems affected. More risk every time you touch it.
What starts as a quick tweak in Figma turns into a costly rework in production. And the longer you wait, the more expensive that fix becomes.
How We Design with Dev from Day One
Our approach is simple: embed design into development teams early. Not as an add-on, but as a partner.
We run two-week design sprints, side by side with engineering. We bring the research, tools, and clarity devs need to build confidently. We focus every sprint on three outcomes: users get what they need, the business gets what it values, and developers know exactly what to build – and why.
No wasted motion. No guessing. No “we’ll figure it out later.”
And the ripple effect? We’ve watched dev teams adopt design thinking. They start asking different questions. Challenging assumptions. Advocating for the user – even before we do.
That’s when the culture shift happens. From shipping fast… to shipping smart. From pushing pixels… to solving real problems.
What Developers Can Ask (Even Without a Designer)
Even if you don’t have a designer on your team yet, you can start embedding design thinking today. Here are three questions we coach dev teams to ask:
Who am I building for – and what problem are they actually trying to solve? Is this the simplest way for the user to reach their goal? How will this feel once it’s in their hands?
If these questions become second nature, design and development stop handing things off to each other – and start building together.
Design Thinking Is Product Thinking
Design thinking isn’t just a creative framework. It’s a product mindset: empathize, define, ideate, prototype, test. It helps us slow down early so we can move faster later.
When design and dev embrace that together, we stop working in sequence – and start working in sync.
And that’s when great products are born.
Not from last-minute fixes. Not from polish at the end. But from shared clarity at the start.
✨ Want to stop saying “we should’ve done this sooner”? Discovery calls are on us. Let’s talk.
