When you decide to outsource software development, you definitely want to have a successful and productive partnership. Here are five common traps to avoid when you are starting your collaboration with a software development team.
Mistake 1: Chasing the lowest hourly rate
The bid with the smallest cost is hardly ever the one with the smallest total cost of ownership. What cheats in contestants that win by price is the type of corners they cut: corners you don’t see until it’s far too late – six months into the project, say, or six months after delivery. Those cuts are all logged as technical debt: decisions that were postponed, un-documented code, absent test cases, or extra complexity which turns every future modification into a moonshot.
You should be looking at the latter metric. It includes (but is not limited to) the refactoring you will have to perform, the delays you will experience, and the additional work you will ask for when the second vendor arrives. If the bid with the highest price steers clear of your budget, the most prudent decision is looking for your trusty whip and chair and getting another round of bids. If estimates from the Standish Group’s CHAOS Report are any indication, roughly 66% of software projects ultimately fail totally or in parts, with budgets and incompatibility with partners finding their way in lead causes.
Mistake 2: Leaving IP ownership undefined in the contract
This is the single biggest gotcha for non-technical founders. They assume you paid for it, you own it. Not the case by default. Without a clear statement in your contract, the agency likely has the rights to the code (and maybe the design assets).
And before a single line is written, you’ll need that clear statement in plain English that all repositories, source, and design files transfer to you upon payment. It’s also in your interest to get as much detail as possible on any code escrow conditions if your product is reliant on the agency’s infrastructure in any way.
Vendor lock-in is a brutal operational cost, and the time to safeguard yourself against it is before the SOW is signed, not after you realize you can’t export your product.
Mistake 3: Underestimating communication and cultural fit
Differences in time zones and languages do not become issues by default. Many offshoring and nearshoring situations actually function without problems. The real consistency in those arrangements that succeed, however, is the presence of specific communication processes: the Agile standups, sprint reviews, and async documentation practices that ensure your team stays linked with one another, even if you’re not in the same location or on the same clock.
When the cogs don’t do their sprint review as automatically expected, and you need to formally ask a week in advance for that status update, grounds for dissatisfaction are being set up. A lot of your passion and energy will start going into easy, manageable gripes like “Why don’t they do this right?” or “We just need to get everyone on the same page about that?” as opposed to building the right solutions for your customers. This is where a client/engineering partner relationship matters differently than a vanilla vendor/staffing situation – companies like Pilot West Studios operate with the kind of direct, collaborative workflow that keeps client stakeholders genuinely informed rather than periodically updated, and that difference compounds over a six-month engagement.
Mistake 4: Not asking how QA is handled
Many teams will request to view a portfolio. Fewer will inquire about the testing pipeline. Let’s bridge that divide.
A partner who is counting on manual testing as a backstop to catch everything will end up shipping faulty products. Not because manual testing isn’t careful – it’s just that the type of errors manual, post-development QA uncovers are those that could have already been discovered through automated testing. Automated QA – the type that is part of every stage of development, not tacked on at the end – is what separates the partners who are shipping stable software from the partners who are shipping software that ‘technically’ launches and ‘technically’ works but is a game of support whack-a-mole from day one.
Be specific: Do your developers write unit tests? What level of test coverage do you shoot for? Do you have a CI/CD pipeline that automatically kicks off tests with every commit? If the answers to these questions are non-committal, well, that’s saying something. A DevOps-inspired team that is actually using automated testing will be able to respond to all of these questions clearly.
Mistake 5: Agreeing to vague scopes with calendar-based payments
Committing to a vague deadline without a corresponding list of features to be included in the release is not a commitment. It’s an attempt to guess the future dressed as a promise. If payments are structured around dates rather than handoffs, you’re in real trouble. You lose any ability to ensure that completed work matches the standard of work you were expecting. And in reality, you’re frequently paying for work that shouldn’t be considered billable at all. The more grey area there is about what was supposed to be included in a sprint and what constitutes bug fixing versus an overspend, the more you’re at risk of a very disappointing project.
A better approach is to lock each sprint’s scope at its outset. Exactly what your programmer will deliver in the next two weeks should be in your inbox before the sprint has started. And it shouldn’t be vague paragraphs – it should be numbered, specific features. That deliverable, those features, constitutes what should be called done for this sprint, and what payment will be based on at the end of the two weeks.
This gets both of you on the same page about estimates versus commitments. An estimate is valued based on where you are now and if you’re getting more changes than the original spec could have predicted, that’s the process working as intended. A commitment is based on the idea that for this price, we will do this. If the sprint has not done what you needed, the commitment has not been met.
