When a new client comes to us at Newpath, more often than not, they’re not starting from scratch. They come to us with a website, app, system or platform already in place—often custom-built, sometimes partially complete, and in many cases, deeply broken. It’s a situation we’ve grown familiar with: fixing or rescuing work that has been poorly executed by another agency.
This blog isn’t about naming names or throwing shade. It’s about sharing some hard-earned lessons we’ve picked up along the way, and offering some insights for business owners and marketing teams who might be navigating similar waters.
- “Custom” Doesn’t Always Mean Good
We’ve seen our fair share of custom-built CMSs, proprietary frameworks, and spaghetti-coded backends that are held together by little more than digital duct tape. Agencies love to pitch bespoke solutions, but not every custom build is created with scalability, maintainability, or performance in mind.
The problem? When that agency disappears, so does the roadmap. Suddenly, you’re locked into a system no one else can understand or support without major rework.
What we’ve learned: If it’s going to be custom, it needs to be clean, documented, and justifiable. Otherwise, open standards and battle-tested platforms are often safer and smarter bets.
- Over-Engineering Is a Silent Killer
One of the most common patterns we encounter is over-engineering. Features built for the sake of complexity, not necessity. Systems layered so heavily with abstraction and dependencies that even small changes become risky and time-consuming.
We once inherited a booking system with a microservice for every minor feature—a system so complex it needed a developer just to update the address field in the admin. That’s not elegant. That’s chaos disguised as architecture.
What we’ve learned: Simplicity scales. Code should serve the business need, not the developer’s ego. Elegant solutions are not the most complex—they’re the most effective.
- Comments Matter (So Does Documentation)
You know what’s worse than bad code? Bad code with no documentation. Or even good code with no comments.
We’ve had to spend hours deciphering the logic behind poorly named functions, hardcoded values, and entirely undocumented workflows. It’s not just inefficient—it’s expensive.
What we’ve learned: When we build, we build with a future developer in mind. Comments are breadcrumbs. Documentation is a roadmap. Without them, you’re just wandering in the dark.
- UX and UI Are Often Afterthoughts
Plenty of builds look impressive in a proposal or Figma prototype but fall apart in the hands of actual users. We’ve taken over websites that were visually polished but functionally unusable. Forms that didn’t validate properly. Navigation that broke on mobile. Accessibility violations galore.
What we’ve learned: User experience isn’t the icing—it’s the cake. We embed UX and accessibility thinking from the very beginning. Because pretty isn’t useful if no one can figure out how to use it.
- “Agile” in Name Only
Many agencies love to talk about being agile. But when we dig into their process, it’s often just waterfall in disguise. Clients are locked out of meaningful input until the end, timelines are rigid, and there’s little room for iteration.
We’ve been brought in to recover projects that were 90% done but 0% aligned with what the client actually needed.
What we’ve learned: Agile isn’t about sprints and stand-ups—it’s about flexibility, communication, and client visibility. Transparency builds trust, and course correction early saves everyone time.
- Business Logic > Developer Preferences
Developers are opinionated. (We say this with love—some of our team are the most opinionated people we know.) But sometimes, developer preferences get in the way of business logic. We’ve inherited codebases built with bleeding-edge tools that added no real value—just complexity.
In one project, the previous agency had integrated a new JavaScript framework purely because the lead dev was excited to try it. No one on the client’s internal team knew how to support it. It was a novelty that turned into a liability.
What we’ve learned: The right tech stack is the one that meets the needs of the business and the people supporting it. Shiny and new is fine—as long as it’s the right fit.
- Handovers Are Rarely Done Well
We rarely receive anything resembling a clean handover. Sometimes there’s no access to the code repository. Sometimes we don’t even get admin access to the CMS. Documentation? Credentials? Hosting details? Often missing.
What we’ve learned: When we hand off a project (whether to a client team or another agency), we do it with respect. Because professionalism isn’t about ownership—it’s about stewardship.
So, What Should You Ask Your Agency?
If you’re thinking of working with a digital agency (or wondering about the work your current one has done), here are some questions worth asking:
- Can any developer (not just your team) understand and maintain this code?
- What platform is this built on, and why was it chosen?
- Is there documentation for every major feature and system?
- How is the business logic captured and validated?
- Can you provide access to the repository and staging environments at any time?
- How do you approach handover/transition out?
Final Thoughts
We’re not in the business of slamming other agencies. We’ve seen amazing work from peers in the industry. But we’ve also seen what happens when shortcuts are taken, when handovers are sloppy, and when code is written without empathy.
At Newpath, we approach every rescue project as a chance to rebuild trust—not just in code, but in process, communication, and accountability. And when we hand something over, we do it with pride, knowing that the next person who looks under the hood won’t have to guess what they’re looking at.
Because digital builds should stand the test of time. And the best way to future-proof your tech? Build it right the first time—or get help from someone who knows how to fix it when it wasn’t.
