If we’re being honest, most of us can look back with hindsight and identify the early red flags we noticed in a relationship that later became problematic – whether it’s a relationship with a colleague, a friend, a romantic partner, or other. Unfortunately, ignoring early signs of trouble in relation to a software development partner can lead to costly losses. Disregarding software developer red flags can result in blown budgets, serious delays, and ultimately, software project failure.
Luckily, you don’t have to try out a bunch of software developers to learn to recognize red flags. Below, we outline software developer red flags to help you choose the right partner or know when to end it with a dud!
This software developer red flag can appear from the beginning when they respond to your request for proposal or during their pitch. If they say yes to everything during the sales process and even into development, this is a problem. The reason they’re saying yes can happen for two reasons.
New software development companies don’t have a lot of experience. They may say yes during the sales process and plan to learn how to do it if the deal closes. While this may be understandable, it ends up being a costly mistake – for you. Essentially, you pay for them to learn. You’ll end up spending more and blowing through deadlines while they try to learn whatever it was they didn’t know how to do while developing.
During the sales process, they may avoid expressing caution or skepticism, because they’re afraid to lose the deal. During development, they may say yes to everything, because they aren’t experienced enough to be able to advise you or to appreciate the wisdom of advising a client when it leads to a better product. Either way: you and your product lose.
Another reason a software development company says yes to everything is because they aren’t a true partner. A true partner should push back on or amend client requests if they jeopardize the quality of the end product. The relationship between software developer and client should be one of collaboration, with the mutual end goal of a minimum lovable product.
Churn and burn dev shops are focused on building products and moving on, regardless of the product’s ultimate success. These dev shops may look flashy, and they can even create flashy products. But they don’t think through the complexities of user experience, your goals, your users’ needs, the market, and the best way to deliver on all of these by creating a lovable product. They lack the vision and foresight to help you succeed.
What you really need is a development company that brings significant expertise to the relationship so that you’re getting insights, suggestions, and recommendations that are going to help you think about things that you probably haven’t thought about yet or that you need to be thinking about. Sometimes this blurs the line between a simple yes and a simple no. But the answer they arrive at – with you – may be a “no” to your request but a “yes” in favor of your product’s success.
All clients ask developers how soon they can start. It’s a potential red flag if the answer is always, “Immediately!” Doing projects the right way requires highly skilled resources and also a variety of resources. It is possible that some companies just happen to have the resources all available in all sitting on the bench, but it’s very unlikely. Look out for development companies that seem to be available to your every whim right away. They may not have any other clients (not a good sign) or they may just be saying yes (refer to #1) and will then delay the software project while they wait on resources.
From the very first engagement, how transparent is the software developer? Some development companies will operate in a black box where you can’t really see what’s going on. Beware of the black box!
A true development partner doesn’t try to operate behind a magic curtain. They are very transparent.
Sometimes that means you see mistakes, you hear dumb questions, or you see some harried meetings. But when a software developer is truly transparent, even painfully transparent, they and the client can achieve alignment a lot quicker. Mistakes will arise and maybe they even are visible more often. But they’re smaller mistakes, and they can get addressed really quickly to get back on track. (You’ve heard us say before that mistakes are a good thing in software development, and here’s why.)
When a development company tries to operate in a black box, mistakes or misalignment can grow and turn into larger issues. By the time the client finds out about them, it’s really expensive and impactful to try to resolve the snowballed issue.
Signs you’re in a black box:
Does the software developer insist on controlling all of the assets and artifacts for your product? For example, do you know where the source code is stored? A surprising number of companies pay a developer to build a product or do development work and don’t even think to ask for the source code.
You, as the owner of the product, should maintain control of all of your assets and your artifacts at all times. That way, you’re set up to be vendor agnostic.
Note: This requires a lot of mutual trust in the developer-client relationship. Some developers will hold back artifacts until invoices get paid. But once a trusting relationship is established with on-time payments, the developer should give you access.
You should have full access to all of your artifacts at all given times. This includes things like
We recommend when building a product, have your vendor plug into your assets. Then you give them control over administering and facilitating the items above. But you need to be the owner, ultimately. If a developer pushes back on this, that’s a big red flag.
This may seem simple. But if you’ve never built software, and the software developer is really good at coming up with excuses for why things aren’t done, why problems weren’t anticipated, or why timelines are off, you might accept it as normal.
A development team that doesn’t do what they say they’re going to do when they say they’re going to do it is a red flag. This is a two-part process. First, they have to actually give you insight into what they are currently doing and planning to do. Do you have good visibility into their progress? Do you get clear status reports that tell you how they’re doing in terms of timeline and budget and scope? Do they have some kind of organized way of communicating potential risk?
Second, what do their actions tell you? Do they do the things they said they would do, even incrementally, such as sprint by sprint? If they say that they’re going to do these items in a sprint, do they come back completed and on time? Or is there always a story for why they aren’t done?
In any relationship, it’s critical to pay attention to actions over words. Here are some other behaviors to watch:
If you haven’t been on a dating app lately, there is a lot of talk on them about green flags. Green flags are the opposite of red flags; they’re early signs that a person, or company, will be a great partner. Software developers green flags reflect many of the green flags for a good romantic partner: they’ll communicate frequently and thoroughly, they’ll be above board and transparent, they’ll be true to themselves by saying no when it matters, they’ll be honest about when they can show up and when they need more time, and they’ll do what they said they were going to do.
We are sure our past and current clients would recommend us to anyone looking for a true partner in software development. If you’re looking to build a product, be sure to “swipe right” on us! Or, you know, fill out this contact us form.