3 Red Flags When Choosing a Software House

The first conversation with a software house usually goes smoothly. The vendor talks about experience, standards, and process, while you try to assess how much of that talk reflects the way they actually work and how much is a well-rehearsed sales pitch. The problem starts when you ask for examples from previous projects and hear generalities. That is the easiest time to check who you are really talking to: whether the vendor can show how they delivered quality, handled a crisis, and started working with a client.

The Vendor Can’t Show Quality Standards in Practice

Every vendor will say they care about code quality. The question is: how will they prove it? An answer like “we have seniors,” “we do code reviews,” or “we write tests” is not enough. Those are empty slogans, not standards. Ask for the specific quality rules the team followed on previous projects. If the vendor cannot name them, quality depends on the goodwill of particular people. And goodwill quickly loses out to pressure, scope creep, and a looming deadline. The basics of quality are no secret. A vendor should be able to describe how code reviews, automated tests, and the Definition of Done (a shared definition of a completed task) worked on previous projects. They should also clearly explain CI/CD (automated integration and deployment of changes), documentation, monitoring, and security standards. Dodging specifics is the biggest red flag here. If you hear “we’ll tailor the process after we start” or “standards depend on the project,” ask about the previous project. What exactly was required before code could be merged? Did automated tests block deployment? Did the Definition of Done include documentation and clear acceptance criteria? If the vendor cannot answer at that level of detail, they are selling a promise, not a standard.

The Vendor Can’t Describe How They Handle Project Crises

Sooner or later, something will go off track in every IT project. A decision gets delayed, a key person at the client is unavailable, or a demo reveals that the team misunderstood the requirements. That is why the promise “we won’t have problems” is worthless. What matters is how the vendor talks about problems they have faced and how they solved them.

Ask: “Tell us about a project where something went wrong. What happened, when did you tell the client, and how did you solve the problem?” That question quickly separates experience from a sales pitch. A strong answer gets down to specifics: what the problem was, when it came to light, who decided to escalate, how the conversation with the client went, and what changed in the process afterward. An answer without a story is a red flag. A claim about “ongoing communication” is not enough if the vendor cannot describe a difficult conversation with a client. A weekly status meeting does not solve the problem either. Someone at the vendor has to be able to say plainly: we have a problem, we know how big it is, and we propose this action plan. That is why you do not stop at the sales conversation. Ask to speak with a technical person. Only then can vetting the development team reveal whether anyone at the vendor can talk about mistakes without hiding behind excuses.

The Vendor Has No Standardized Plan for the First Weeks of Collaboration

A company that regularly starts new projects should have a consistent client onboarding process: gathering information, setting up communication, sorting out the requirements, and getting the team up and running. The details will differ, but the structure should be predictable. Ask the vendor what the first two to four weeks looked like on a similar project: not the plan from the proposal, but what actually happened. What did the team do in week one? When was the repository created? When did the team agree on the Definition of Ready (the rules a task has to meet before it goes into development)? When did the first demo take place? An answer like “we’d start with workshops, followed by sprints and regular communication” is generic. Ask for specifics: what materials the vendor will prepare, who they will need on the client’s team, and what should be ready after the first month. If the vendor cannot reconstruct how the first weeks unfolded on a similar project, it is hard to call their onboarding repeatable. And if a project starts in chaos, that chaos usually does not fade over time. It escalates.

What to Ask Before Your Next Conversation With a Software House

During the first conversation, do not judge whether the vendor sounds professional. Check whether they can show how they worked on previous projects. Quality standards, crisis communication, and client onboarding should exist before your project. These are only three red flags. Before you sign a contract, you also need to check the team, maintenance, risks, access to the code, and the terms for ending the collaboration. We have gathered them into a practical list of questions to ask an IT vendor that helps you talk about specifics instead of sales promises.