I certainly did throughout my career as a software engineer, CTO, and startup cofounder.
This might make you think working with outsourced IT companies is a mistake. Building an in-house team is a hassle and requires lots of time and effort… but could it be a better choice?
Hiring in-house or outsourcing can be good or bad, depending on your organization's circumstances. You would likely benefit from a combination of both.
The only way to identify how much of each option is right for you is to conduct a clear-minded assessment – not just go with what a salesperson or HR executive would prefer.
I'm here to help you make an informed decision.
The first step is to address the elephant in the room: most software houses have allowed bad practices to become an industry standard.
Let's go over three of the main ones.
3 common bad practices among software houses
1. Multiple projects per developer
Software houses are usually stuck between being forced to offer the lowest possible rates while maintaining a well-paid, high-churn workforce. Combine this with poor time and budget estimations, and you get the perfect incentives for assigning multiple concurrent projects to each developer.
Every new project adds a different context and new lines of communication competing for attention. When a developer has just one project, it gets 100% of their time and effort. Two projects will get less than 50% each. For every additional project, there’s a diminishing return on productivity.
The outcome is predictable: missed deadlines, growing tech debt, invoice spikes due to overtime and pressure to expand the squad, dissatisfaction from the client who now (understandably) wants to cut costs, leading to the same amount of work being assigned to fewer people… and the cycle continues.
It’s tough to detect this issue while it’s happening. Even if you track each developer’s timesheets, they can easily log 8 hours for your project and the same 8 hours for another, proving it would be nearly impossible.
So, let’s focus on preventing it in the first place. Here are a few things you can do:
- Conduct in-depth research on platforms like Glassdoor or Gowork, where previous employees evaluate the employer transparently (instead of official company channels like their website or LinkedIn profile).
- Speak with former clients and specifically ask about their experience with developer dedication and potential overcommitment. Avoid the clients who provided quotes for the vendor's website – they might have a quid pro quo deal.
- Try to find out if the company is going through legal issues with clients.
- Engage a third-party firm to audit the company or, if possible, obtain anonymous feedback from former employees about the company’s practices.
2. Low-quality code
A common outcome of the above scenario is low-quality code, which comes with its own set of problems.
When a developer barely has enough time to code, you can bet they won’t do a lot of testing or write proper documentation.
The growing adoption of AI tools, like Copilot, is a futile attempt to mitigate this situation and increase each developer's productivity. This is a short-term fix that creates long-term problems.
AI tools can be part of a solid developer’s toolkit, but they’re a serious liability in the hands of an inexperienced, pressured, or overworked dev. The generated code will probably work well enough to justify sending you an invoice. However, within 3 – 6 months, bugs, scalability, and maintainability issues will start multiplying.
Low-quality code erodes quickly, and the cost of fixing it is much higher than what it would have taken to build it correctly from the start. Sometimes, the code is so unreadable that even its creator can’t fix it, let alone someone else.
Here's how to avoid paying for shoddy code:
- Ask about their testing procedures, including the types of tests they conduct (unit tests, integration tests, etc) and their frequency. The more specific questions you ask, the better.
- Ask them to send you a snapshot of their Github analytics to evaluate metrics such as velocity and throughput.
- Research their reputation in the industry. If a company has hundreds of very short projects, you can assume that their code doesn’t stand the test of time and clients have to switch after a short period. Look for companies with proven, long-standing partnerships.
By the way, here’s what measuring quality in software development should look like.
3. Fake seniority and unverified skills
If you're not careful, you might pay for senior-level rates and get a junior-level service.
To prevent churn and maximize the spread between rates and salaries, some software houses will rush promotions of less experienced developers before they’ve acquired the skills expected of a senior.
Additionally, some companies draw from a “collective bench” of freelancers when they find themselves short-staffed for a given project – often without doing their due diligence in hiring.
Don’t overlook the CVs being presented to you. Did the developer jump from junior to senior in a magically short period? Do they claim to be an expert in a wide variety of technologies or industries? Are they a good match for the role? Don't take seniority and qualifications at face value. Verify them.
If you want some tips about evaluating developer seniority, listen to this podcast episode.
Let’s raise the bar
With all these flaws in the industry, you might be wondering why I transitioned from being a frustrated client to building my own IT Consulting company.
The answer is simple: I refused to accept that "this is just the way things are". There is a better way and I’m determined to follow practices that respect both the clients and the workers while still thriving as a business.
So far, so good.