As the customer, you can’t always evaluate whether the IT team is following the right path. Without a technical background, it’s hard to tell whether the code is clean, reliable, and maintainable. Hidden yet vital aspects of development can be invisible to you.
How can you know you’re not wasting your time and money on working with this developing team?
Mad Devs Customer University offers 5 red flags reliably showing that most probably your contractor isn’t going to build a product that will meet your business needs.
Red flag: The IT team makes promises that they don’t deliver on.
A professional team is always careful with what they promise the customer. It’s definitely alerting to hear a contractor say “We will complete your project by this date” before they ask you any questions. It shows that they probably don’t care about your business goals or the viability of your product in the market.
Planning. If the team does promise you something, it must be based on a clear vision of the result you need and on the ways to arrive at it. In other words, they have a roadmap of what needs to be done, a list of tools to do it, and an estimate of how long the development of each component will take. A deadline is thus a commitment.
Meeting deadlines. Even committed professionals can miss deadlines. It’s not necessarily because of developers’ incompetence or irresponsibility. Business needs are continuously changing in the market. To meet them, it may be needed to revise initial plans. There can be unpredictable complications, too, so estimates can turn out to be wrong.
In case plans change the committed team communicates changes in estimates to the customer immediately. In this case, they specify what exactly will be developed by the initially agreed-upon deadline and what will have to be postponed. They also explain what is blocking their progress (legal restrictions, need for approvals, a team member’s sick leave, etc.) and how to resolve it.
With a responsible IT contractor, you never end up learning about problems when it’s too late. A professional team always knows they won’t be making it by a deadline well before it comes. And they can clearly explain the reasons for the delay to the customer.
If promises are not delivered on, reconsider your choice to work with that team.
How to find the right software team and make the hiring processes as efficient as possible? Click here to consider what to look at in the proposals provided by different IT vendors.
Red flag: You aren’t invited to see internal team communications.
It’s suspicious when the team members don’t openly communicate about blockers and problems. Throughout the development process, it is practically impossible to encounter zero issues.
Another important aspect of active communication is your direct involvement.
Software development is a collaborative process that involves all stakeholders. Ideally, you as a customer should be welcomed into all group chats, where you can answer questions, provide feedback, and participate in team discussions.
In the task tracking system that your team uses, you should also be able to participate in task discussions instead of being an “overseer” and merely watch the tasks move from one column to the next.
Being in the same task tracking system with your contractor also means you can see the problems they are facing in the development process. If your team shields you from the problems they’re having, you have every right to suspect that they’re not sure how to handle your project.
“If you don’t see them having any obstacles, you’re entitled to ask: Are you even working, guys?”
The lack of transparency can mean that:
- Your contractor doesn’t have a system for tracking and reporting progress
- Worse still, they may be pretending to have more expertise than they actually do
Perhaps the company you’re working with simply doesn’t have the culture of sharing the details of their work with the customer. Ask them to share. If they refuse, it’s definitely a red flag right there.
Glossing over problems
Red flag: The team understates the problems they’re having and fails to explain the causes of those problems.
The way your contractor responds to mistakes is even more important than what mistakes they make. A bad way to respond to mistakes is to say things like “It was a minor complication that we fixed in no time,” or “It won’t happen again”—or simply not to respond at all.
If the team doesn’t respond to even the smallest incidents of malfunctioning, they probably don't understand that each such incident results in business losses and ruined user experience. In other words, they aren’t engaged in your product quite to the degree that they should.
A wiser way to respond to problems is to analyze root causes and come up with a solution to avoid the same mistake in the future. Trustworthy vendors are honest about the things they screw up; they take responsibility for those and fix whatever went wrong in the first place.
A common practice in software engineering is postmortem analysis: the study of why a project/task/feature failed or suffered serious damage. The point here is to regard failures as opportunities to fix existing problems and to improve.
Complex projects naturally pose difficulties. Teams that work on a complex project but report no serious difficulties whatsoever raise valid suspicion.
No long-term plans
Red flag: The team doesn’t think about the product’s future in the market.
If you want your product to last, you need to collaboratively with an IT consultant to develop a long-term vision and think about the product’s future growth and scalability. It doesn’t mean they’re building a large system right away. But it does mean that, while developing a system designed for the current business needs, they’re considering how these needs can change.
Those providers who do NOT care about your product’s future build a product that just works fine today. Their position is that whatever happens in the future is a future problem and not their responsibility.
Such contractors cut costs where possible. Thus, you’ll receive a working MVP with poor test coverage, no documentation, no software architecture, and accumulated technical debt. However, if you later decide to further develop this MVP, the costs will be overwhelming (i.e., the development will be much more expensive than it could be if the team had initially planned to scale things up in the future).
- What load will the product have to handle in the future?
- How may the product’s functionality need to be altered when the load grows?
- Will it be possible (and how much will it cost) to scale the product up?
- Will it be difficult for new team members to onboard and read the code?
Scalable solutions are only applicable when you expect the load to grow as your project progresses. A good team thus keeps in mind these questions:
The product’s prospects may be unclear, but these questions need to be negotiated with the customer nonetheless.
If a software development company wants to prove that their product is reliable, they put themselves into the shoes of end-users. This practice is known as “dogfooding.” Practically, this is the only way an IT team can understand end-users’ pain points and have an early glance at bugs/ problems before everybody else.
Not all companies simulate user experience for products they develop. Since some solutions require a specific background in order to use it. However, there are always creative ways to adopt the dogfooding practice.
Dogfooding gives the company an opportunity to test their product in real-life use and see what can be improved.
For example, if a team develops a system for online purchases, it can have its members actually buy things there every week. Now working with the system from the users’ perspective, the developers can generate ideas on how to make the user experience better.
Clearly, an organization that could use what it develops for their business but doesn’t do it raises suspicion. It doesn’t necessarily mean that the product is bad. But without dogfooding, the development team won’t be able to profoundly understand the users and resolve their problems.
Extra: External software audit
If you specifically want to check if the solutions produced by your team are good from the technical perspective, often your ultimate instrument is external auditing. Some teams initiate auditing without the customer’s request, too.
Let’s narrow it down and say that you need to check if your team’s code is good. First, flawless code is a myth. Yet, code can be better or worse depending on:
- Developers’ seniority level
- The development process
- Quality assurance processes in the team
Modern development teams almost invariably include quality assurance specialists who continuously check the functionality of what’s being built. Peer reviewing and external-expert auditing are widely used for quality checks, too. If a team doesn’t include revision stages to their project timelines, it probably couldn’t care less if the product will work as intended.
Having third-party specialists examine your team’s work is virtually the only way you can confirm that the current team is on the right track. Naturally, an IT contractor who knows what they’re doing won’t object to being audited.
A customer who isn’t a developer still can tell if a development team is trustworthy. That’s why a reliable team provides details on how they’re working, what problems they’re facing, what blocks their progress, how they’re solving them, and what they base their estimates on. That’s how contractors prove they know what they’re doing and how your budget is spent.
If your contractors don’t meet deadlines (without explaining what went wrong), hide problems from you, and don’t seem to care about the future scalability of your product in the market, they might not be right for you. Look out for these red flags to avoid wasting your resources.