Most SME owners we talk to have at least one bad IT-vendor story behind them. A project that was supposed to take three months dragged on for two years. Quotes that grew by half "because extra things came up". Software where, after go-live, it turned out nobody but the author could touch the code. Or the classic: "Krzysztof did it, but Krzysztof doesn't work here anymore."
This piece isn't about who counts as a "good" IT vendor. It's about six specific signals that, nine times out of ten, predict the project will end badly — and that you can almost always spot before signing the contract, if you know to look.
Red flag 1: a quote pulled out of thin air, with no audit
First meeting, an hour-long conversation, and already you hear a hard number: "Comarch-to-shop integration? 35,000 zloty, three weeks." It sounds confident. In reality it's a signal that the vendor doesn't yet know what they're signing up for — because to know, they'd need to see your data, your processes and your exceptions, of which there are usually more than rules.
A serious vendor, before naming a firm price on a bigger project, runs a short audit (usually paid, several thousand zloty) and only then issues the quote. A snap quote means one of two things: either the price is lowballed to win you, then grows through change orders, or it's padded with a fat buffer for the unknown. Neither works in your favour.
What to do: ask straight out — "what is this price based on, what else would you need to check to confirm it?". If the answer is "we have experience, we know", walk away.
Red flag 2: no references at your size and in your industry
"We've delivered projects for large companies" sounds impressive in a vendor's deck — until you start asking for detail. Rolling out SAP at an 800-person corporate and integrating Comarch Optima with a warehouse at a 25-person firm are two different worlds. The competencies don't translate well — different tools, different pace, different expectations. "Big IT" experience can even hurt in an SME setting: people used to a three-month sprint with ten testers don't know how to work with a company where the owner tests everything personally after hours.
Ask for at least two references from companies in the 10–60 person range, ideally in your industry or an adjacent one. Don't settle for a logo on a website — get a name and a phone number. Then call. The question that works best: "if you were doing it again, would you pick this vendor?".
Red flag 3: unclear rights to the code and the data
This is the most expensive trap we see. The contract doesn't spell out who owns the source code, who owns the data, where and in what form documentation will be handed over at project end. While everything works, nobody pays attention. The question only comes back when you want to change something — or change vendor.
At one of our clients — a 15-person engineering office in construction — this scenario played out almost word for word. The company paid around 90,000 zloty for a "custom CRM". They got a working application, but with no source code, no usable documentation, written in a niche framework known only to its author — a solo freelance developer. Two years later, the author switched industries and stopped picking up the phone. The application still runs today, but every change — even adding a new field on a form — would mean rewriting it from scratch. The company has been postponing the decision for three years, because every replacement quote starts with "90 thousand + 6 months".
The contract needs to say it plainly: the source code is yours, the data is yours, technical documentation is delivered in a format readable by people other than the author. Without those three clauses, you're not buying software — you're buying dependency.
Red flag 4: the one-person band
"Krzysztof will do it" sounds great — until Krzysztof goes on sick leave, switches jobs, or gets seriously ill. With a one-person vendor, your entire project depends on the availability and health of a single human being. This isn't theoretical risk — it's a scenario that recurs in our world every few months.
The point isn't that you should only work with big firms. A three- or four-person team works just fine, as long as every area of the project is known by at least two people. Ask: "who else, besides X, can maintain this code?", "what happens if X leaves tomorrow?". If the answer is fuzzy, assume that scenario will eventually find you.
The same applies to the vendor's internal documentation. A solid team has its own wiki, a version-controlled code repository, written-down configurations. A one-person vendor has it all in their head — and only in their head.
Red flag 5: selling technology instead of a solution
A meeting where, for 40 minutes, you hear about "microservices on Kubernetes with a RAG-based AI assistant and a vector backend" — and not once does anyone ask what your processes look like, where you're losing money today, how many orders you handle a month. That's a conversation where the vendor is selling themselves, not solving your problem.
In an SME, a correctly diagnosed problem is worth more than ten fashionable technologies. "You're manually re-keying data from Optima into the warehouse for four hours a day — let's stop that first" beats "let's deploy AI". A serious vendor starts with questions about processes, data, people and money. If they start with architecture, they're selling themselves the project they'll earn most from.
Red flag 6: no SLA, no exit plan
Two clauses whose absence in the contract costs you the most after go-live.
An SLA is just expectations written down: how fast the vendor responds to a ticket, how fast they resolve it, how out-of-hours work is billed. Without one, "urgent ticket" means whatever mood the vendor is in on a Friday afternoon. With one — you have a concrete 4, 8 or 24 hours, and consequences if they're missed.
An exit plan is a description of what happens when you want to end the relationship. What you get at the end (code, data, documentation), in what format, by when, for how much. Good vendors put this in writing up front — because they know that a client who can see a clean exit is more likely to stay. Weak vendors avoid the topic, because their business model rests on you not wanting to leave because you don't know how.
What due diligence actually looks like in an SME
You don't need a procurement department or a lawyer off LinkedIn. Five things, before you sign a larger contract:
- A short technical conversation with a second person on the vendor's side — not just the salesperson. If "the specialists are busy, you'll speak to them after signing", that's a red flag by itself.
- Two reference phone calls — with companies your size, not corporates. Ten minutes each is enough.
- Read the contract for three things: rights to code and data, exit plan, SLA. If they're missing, demand them. If the vendor refuses, you have your answer.
- A short paid pilot instead of jumping straight into a large contract. 20–30 thousand zloty for a small slice of the project will show you how the vendor works, communicates, and meets deadlines. It's the cheapest insurance you can buy.
- Ask about the team: how many people, what skills, who knows what. Vague answers = a one-person shop in team's clothing.
What next
Picking an IT vendor isn't a decision about one deployment. It's a decision about who, for the next two to three years, will have their hands inside your infrastructure, your customer data and the processes you make money on. Getting it wrong costs many times more than the time it takes to check the six items on this list.
If you have a vendor decision in front of you and you don't know how to assess the offer, we'll help you walk through it point by point. The first call is free and takes half an hour — we don't sell anything you don't need on it.
A good IT vendor starts the conversation with questions about your processes and your money. A weak one starts with stories about their technology. The difference shows up at the very first meeting.