Thinking of Breaking Up With Your Developer?

If you’re struggling with your current software developers, you’re not alone. Our senior product consultant, John Halvorsen-Jones speaks to past situations we’ve been brought into, the warning signs and how to manage a transition.

---

Many times over its history Putti has been called upon to rescue failing software or app projects.

What has become clear from this is that innovative Kiwi businesses with custom digital projects all too commonly experience budget, service, quality or delivery issues, which then seriously hamper their otherwise exciting product development journey.

And, although professional AI driven development is now helping to bring dev costs down, the flakey use of AI “vibe coding” is only increasing the number of quality problems we’re seeing.

With this in mind we’ve put together the following tips on how to read the warning signs, navigate a “breakup”, and find a partner who actually delivers on your vision.

The Warning Signs: Why Relationships Sour

Many issues probably stem from software development being an unregulated industry and, in the NZ context, operating in a country with a shallow investment environment. This combination means that budgets are often pressured, relative to what’s being aimed for, while the software development industry itself is full of people willing to just 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. Adding to many difficult situations is that 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, or even a complete failure to deliver.

But great NZ development agencies do exist; it’s just a matter of identifying them, and then being willing to invest sufficient funds to enable them to produce, and maintain, a high quality product; or rescue an existing project and make it so.

When Should You Make Up vs. Break Up?

Like any breakup, it’s a big step and not to be taken lightly.

So it’s always a good first step to properly identify whether issues are really just about some minor things that can be sorted out, or whether there’s simply no way forward with the existing developers.

The best approach to figuring this out is to meet in person, or at least over video call, and dig deeply into the situation, listening carefully to what’s coming back. Consider whether or not:

• 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?

Perhaps you’ll just know, but often this will also require bringing in a third-party with a sufficient skill set to understand the developer’s world. If even they are unsure, it may then be necessary to get a professional code audit done; this will uncover the quality, or otherwise, of what’s been built, and provide expert feedback on what is required to finish the job and close any gaps.

If delving into everything ends up suggesting that 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 break up is where you find yourself; here’s a checklist to help make it as unmessy as possible. If it seems like a lot, that’s because a lot can go wrong and 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? If you have had setbacks, at least you also have a clearer, more grounded, understanding of what it takes to deliver a software project. You can also remind your internal team that, just by attempting to do something unique, you’re already ahead of most competitors. Overall the business needs to re-find its excitement about moving forward.

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. Make sure to document the termination details in writing.

Finalize Outstanding Items

Clarify what work will still be completed before the handover date (if any). Agree on a final payment or dispute resolution if needed. Make sure final deliverables are handed over before any final payment.

Documentation

This should include all requirement documents, design notes, user manuals, runbooks, test plans, API docs, etc. These contextualize the codebase for the new team.

Source Code and Assets

Make sure you have control of the full code repository, including branches, binary assets (images, fonts, etc.), database schema, DevOps scripts, seed data, libraries and licenses. 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, servers, cloud services, CI/CD tools, domain registrars, SSL certs, analytics, and any third-party services. (After transition, revoke your previous developers credentials promptly.)

Deployment Pipelines

Ensure the build and deployment processes are documented and functional. This includes build scripts, container images, VM images or infrastructure-as-code. Ensure that the new team is able to deploy the latest build.

Data and Migrations

If data must be migrated (e.g. database, 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/Issues

List any known defects or technical debt items. Provide the new team with bug reports, logs, and current issue tracker. Clarify which issues the old dev 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).

Intellectual Property/Legal

Complete any contractual sign-offs. Ensure all IP is legally assigned (by contract) to your business. Confirm 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 developers through architecture, non-obvious code areas, and current issues. Include client stakeholders in this process where possible to build relationships.

Communication

Inform all stakeholders (management, end users, other vendors) about the change. Manage expectations: for instance, minor outages might occur during cutover. If this is the case ensure customers have received prior notice.

All of the above should be managed under a clear timeline, with buffer time for unexpected delays. Ultimate best practice would also be to have a contingency plan and to track progress with milestones.

Further risk mitigation can include running both teams in parallel briefly, or having temporary backup support contracts in place with the old team.

Finding “The One”: Evaluating a Replacement

A new developer or agency can seem fresh and shiny but, having already experienced what can go wrong, what’s most important is being diligent to ensure that you’re not jumping from the frying pan into the fire.

The first step is to understand what good looks like in a general sense. Are you talking to an agency with proven history, depth, NZ team and mature processes, or is it one or two people who then shuffle all development to offshore agencies; or a developer just moonlighting for some extra cash? Obviously narrowing the field down to well-established agencies is a great first step.

From there it’s about evaluating agencies to gauge the relative depth of their team and maturity. This isn’t easy when evaluating a skill set that’s usually different to your own, however here are some green and red flag items that may help.

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 some 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.

AI Use

GREEN: Clear and honest about how and where AI is used, and the guardrails they have in place. There should be strong engineering and QA practices to validate AI outputs.
RED: Vague or evasive about AI use. No clear QA processes. Talk of “10x” speeds that seem unrealistic.

Project Governance

GREEN: Strong agile practices and a project manager for larger projects. An obviously thorough approach to uncovering all the necessary project details. Able to explain clear budget management processes.
RED: Unclear communication plans or siloed development where you only see results at the very end. Lack of time and effort to genuinely understand the details of your project. Unrealistic “low-ball” bids that likely hide future “additional costs” or mismanagement.

QA Process

GREEN: Use of CI/CD, code reviews, staging environments and automated tests.
RED: Skipping some or all of these.

If you’re unsure, bringing in a third-party who really understands the dev scene would be well worth the investment. Otherwise, at least drill into case studies and look for opportunities to speak to past customers.

Obviously we believe Putti ticks all these boxes, and we’ve been 100% successful in project rescues that we’ve taken on to date, however we still welcome your due diligence.

Summing It All Up

Breaking up is painful. First, there’s whatever the pain was that leads to it; second there’s the time and cost involved in the transition.

All of this points to the importance of finding the right development partner from the outset. However, inevitably not all relationships work out and, in the end, it can be better to deal with the pain of a breakup rather than have a bad situation drag on and on.

Where a breakup is necessary, the best thing that can be done is to carry the lessons from it forward; applying them to finding a better alternative.

Nevertheless, no matter how much your team has learnt, sometimes the most important learning is the limitations 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 and properly evaluate. 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.

About the Author

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 complete IT and software career spans hands-on technical roles, through to consulting and management. As the senior product consultant at Applicable and then Putti (who acquired Applicable in 2024), John has been closely involved in numerous large software projects from inception through to maturity. He has also been a key person in several large project rescues. His cumulative tech experience spans delivering projects to a wide range of 8-9 figure businesses and four crown entities.