If you're struggling with your current software developers, you're not alone. Many innovative NZ businesses experience budget, service, quality, or delivery issues with custom digital projects, and the rise of AI "vibe coding" is increasing quality problems further. This guide covers how to read the warning signs, navigate a clean developer handover, and evaluate a replacement so you don't jump from the frying pan into the fire.
Why Do Developer Relationships Sour?
Many issues stem from software development being an unregulated industry operating in a country with a shallow investment environment. This combination means budgets are often pressured relative to what's being aimed for, while the industry is full of people willing to say "yes" and give it a go.
This can give rise to a cocktail of misaligned expectations and poor project governance. In some cases, outright incompetence is also part of the equation. And developers aren't always known for being great communicators.
Warning signs can be seen in:
- Arguments about scope vs budget
- Delivery that doesn't align with expectations
- Quality control problems
- A complete failure to deliver
Great NZ development agencies do exist. It's a matter of identifying them and being willing to invest sufficient funds to produce and maintain a high quality product.
When Should You Make Up vs. Break Up?
Like any breakup, it's a big step and not to be taken lightly. The first step is to properly identify whether issues are minor and fixable, or whether there's simply no way forward.
The best approach is to meet in person (or at least over video call) and dig deeply into the situation. Consider whether:
- Explanations are credible
- There is a willingness to explain in depth
- Their portfolio of past projects proves their ability to deliver
- They have an experienced NZ team
- There is trust left in the relationship
Often this will require bringing in a third-party with sufficient skill to understand the developer's world. If even they are unsure, it may be necessary to get a professional code audit done. This will uncover the quality of what's been built and provide expert feedback on what's required to finish the job.
If delving into everything suggests it's best to move on, then it's best to move on. Often people get tempted back, only to go through the same toxic rinse-and-repeat cycle all over again.
The Clean Break: A Transition Checklist
If a breakup is where you find yourself, here is a checklist to make it as unmessy as possible. If it seems like a lot, that's because a lot can go wrong; transition is a delicate moment in time.
Revisit the Vision
The start of a transition is a great time to remind yourself why you were building something in the first place. What was the vision and intended outcome? You can also remind your internal team that, just by attempting to do something unique, you're already ahead of most competitors.
Review Contract Termination
Before any practical steps, ensure you have the legal right to terminate. Give notice as required, or mutually agree an exit. Involve legal counsel if the developer disputes termination. Document the termination details in writing.
Finalise Outstanding Items
Clarify what work will still be completed before the handover date. Agree on a final payment or dispute resolution if needed. Make sure final deliverables are handed over before any final payment.
Documentation
Collect all requirement documents, design notes, user manuals, runbooks, test plans, API docs, and related materials. These contextualise the codebase for the new team.
Source Code and Assets
Make sure you have control of:
- The full code repository, including all branches
- Binary assets (images, fonts, etc.)
- Database schema
- DevOps scripts and seed data
- Libraries and licences
Ensure the code is up-to-date on a central repo and tagged or branched at handover point.
Technical Credentials
Ensure you have access keys, passwords, and accounts for:
- Version control systems
- Servers and cloud services
- CI/CD tools
- Domain registrars and SSL certificates
- Analytics and third-party services
After the transition, revoke the previous developer's credentials promptly.
Deployment Pipelines
Ensure build and deployment processes are documented and functional, including build scripts, container images, VM images, and infrastructure-as-code. Verify the new team can deploy the latest build.
Data and Migrations
If data must be migrated (databases, user data, content), plan the steps and timing carefully. Back up all current databases and files before handover, and validate that the new team can restore and run the system end-to-end.
Outstanding Bugs and Issues
List any known defects or technical debt. Provide the new team with bug reports, logs, and the current issue tracker. Clarify which issues the old developer will resolve (if any) during transition.
Support Arrangements
Clarify any post-handover support period, for example an overlap where the old team can fix critical bugs or support the new team during cutover.
Intellectual Property and Legal
Complete any contractual sign-offs. Ensure all IP is legally assigned to your business. Confirm that any NDA or confidentiality clauses remain in force.
Knowledge Transfer Sessions
Hold handover meetings and code induction sessions. The outgoing developers (if cooperative) should walk the new team through architecture, non-obvious code areas, and current issues. Include client stakeholders in this process where possible.
Communication
Inform all stakeholders (management, end users, other vendors) about the change. Manage expectations: minor outages might occur during cutover, so ensure customers have received prior notice.
All of the above should be managed under a clear timeline with buffer time for unexpected delays. Further risk mitigation can include running both teams in parallel briefly, or having temporary backup support contracts with the old team.
Finding a Better Partner: How to Evaluate a Replacement
A new developer or agency can seem fresh and shiny, but having already experienced what can go wrong, being diligent is critical to avoid jumping from the frying pan into the fire.
First, narrow the field to well-established agencies: not one or two people shuffling development offshore, or a developer moonlighting for extra cash. From there, evaluate depth of team and maturity of process using these green and red flags:
Technical Fit
Green: Concrete case studies in your specific tech stack. Red: Vague examples or "black box" processes.
Capacity
Green: Stable team size with low churn. (LinkedIn profiles can provide clues.) Red: High staff turnover or "key person" risk.
NZ Context
Green: NZ-based with awareness of the NZ Privacy Act 2020. Red: No local presence or understanding of NZ compliance requirements.
AI Use
Green: Clear and honest about how and where AI is used, and the guardrails in place. Strong engineering and QA practices to validate AI outputs. Red: Vague or evasive about AI use. No clear QA processes. Claims of "10x" speeds that seem unrealistic.
Project Governance
Green: Strong agile practices and a project manager for larger projects. A thorough approach to uncovering project details, with clear budget management processes. Red: Unclear communication plans or siloed development where you only see results at the very end. Unrealistic "low-ball" bids that likely hide future "additional costs."
QA Process
Green: Use of CI/CD, code reviews, staging environments, and automated tests. Red: Skipping some or all of these steps.
If you're unsure, bringing in a third-party who truly understands the development scene is well worth the investment.
Summing It All Up
Breaking up is painful: first there's whatever caused the problem, then there's the time and cost of the transition. All of this points to the importance of finding the right development partner from the outset.
However, not all relationships work out, and in the end it can be better to deal with the pain of a breakup rather than let a bad situation drag on.
No matter how much your team has learnt through a difficult experience, sometimes the most important lesson is recognising the limits of people who aren't in the software development industry to evaluate vendors. Software is a deeply complex world with layer upon layer of quality factors to understand. Unless you have serious in-house capability, getting professional input to provide code reviews and vendor expertise will still be key to avoiding future problems.
John Halvorsen-Jones spent over sixteen years running his own software development agency (Applicable) and, prior to that, founded and taught in the Diploma of Web Development at Yoobee, as well as teaching in two degree programmes at AUT. His IT career spans hands-on technical roles through to consulting and management. As senior product consultant at Applicable and then Putti (which acquired Applicable in 2024), John has been closely involved in numerous large software projects from inception through to maturity, including several large project rescues for 8 to 9 figure businesses and four crown entities.