Is it worth hiring the cheapest one?

Almost never. A 30-50% price variation between serious vendors usually comes down to scope, assigned team, or domain experience. Differences of 200-400% usually mean one of them is miscalculating: the cheap one is underestimating the scope and will pass it on later through scope changes, or the expensive one is hedging against uncertainty because they didn't understand the project. Cheap is expensive especially in software: what you don't pay upstream you pay downstream in maintenance, technical debt, and vendor rotation.

And if I choose wrong, can I change partners mid-project?

You can, but it costs. Changing mid-project adds between 30% and 60% to the original budget, because the new team needs weeks to understand what's been built and often discovers that part of it needs redoing. The way to minimise the risk is not to bet everything on the first long milestone: contract short phases (4-8 weeks), review real deliveries, and keep the option of not continuing if it isn't working. A serious partner isn't offended when you include a clean exit clause in the contract.

Who owns the code they build?

You do, no discussion. It's the first point you should lock down in the contract. What we sign with clients includes: full transfer of intellectual property of the code developed for the project, delivery of the repository in a Git you control (not the vendor's), and enough documentation for any other technical team to continue the work. If a vendor charges you extra to deliver your code or to give you repository access, walk away from that conversation.

How many vendors should I compare before deciding?

Three is the sweet spot. One is blindness: no contrast. Five or more is noise: proposals become indistinguishable, meetings drag on, and you end up deciding from exhaustion. Three lets you see different profiles (freelance, boutique, agency, for instance), compare approaches, and validate prices. Below those three, rule out vendors by red flags before asking for a formal proposal: you save everyone time.

How to choose a custom software development partner: red flags, what to ask and how to evaluate proposals

The question we get most often through referrals has nothing to do with technology. It’s this one: how do I know that the vendor I’m about to hire is the right one. It comes from someone who has never contracted custom software development, who has three proposals on the table with a 400% spread between cheapest and most expensive, and who has no idea what accounts for that difference. The fear is reasonable: paying 30,000 EUR and ending up with a system that doesn’t work is perfectly possible, and nobody wants to be the one who signed that.

This post isn’t trying to convince you to hire VisibleSoft. It’s trying to give you tools to rule out whoever you shouldn’t hire, whoever that is. Bad decisions are avoided with questions, not instinct. If after reading you decide you’d rather go with a competitor of ours because they fit your case better, this text will have done its job.

Information asymmetry, the underlying problem

The reason these contracts go wrong so often is structural: the client doesn’t know enough about the craft to evaluate what they’re being sold, and the vendor knows too well how to present it. The client compares prices. The vendor talks person-months, profiles, risks. When both sides speak different languages, whoever sells better wins, which isn’t always whoever executes better.

The only way to balance it is to walk into the negotiation with questions the vendor wasn’t expecting. They don’t need to be technical: they need to be specific about how they work, what they guarantee, and what happens when something goes wrong.

The 7 red flags that rule out a vendor in the first meeting

If you detect any of these signals in the first conversation, rule out. Don’t debate nuances, don’t sit with doubts, don’t ask twice. Each one has been repeated enough times in failed projects to count as an exit criterion.

They give you a closed budget on the first call. It’s impossible to honestly quote a software project without first understanding the problem. Whoever does it is either slapping a standard price that doesn’t fit your case, or putting in a low figure to win the deal and bumping it up later through scope changes. A serious partner starts with a paid discovery (short, scoped, with a concrete deliverable) and only then presents a proposal.
They commit to a technology before understanding the problem. “We’ll build it in Angular and .NET”, or “we’ll set it up with Laravel and MySQL”, said in the first meeting when they still don’t know what you need to do or how your infrastructure is set up. It means they’re choosing the tech because it’s the one they know, not because it’s what your case requires.
The proposal is long on marketing and short on technical content. 30 pages with proprietary methodologies, photos of smiling teams, quality seals, and diagrams of “our agile process”. Zero detail on the specific team they’ll assign, the real project phases, and weekly deliverables. The padding is hiding the fact that they haven’t thought the project through.
It’s not clear who will actually develop the work. “We have a senior team”, “we’ll assign qualified profiles”. If you ask for specific names and profiles and you don’t get them, it’s almost always because the salesperson you’re talking to isn’t who’s going to code, and whoever is going to code doesn’t know yet that they will be. On small and medium projects, this usually ends with your account covered by juniors while seniors handle bigger accounts.
They have no verifiable portfolio. No real websites you can visit, no client names you can contact, no case studies with measurable results. Serious vendors have confidentiality agreements with some clients, sure, but not with all. If the answer is “we can’t show you anything due to confidentiality”, be wary: there’s a middle ground between disclosing everything and having nothing to show.
They won’t let you talk to previous clients. Variant of the above, more severe. A partner who has delivered well in recent years has clients willing to spend 20 minutes telling you about it on the phone. If they make excuses to avoid that call, there’s something they don’t want you to know.
They insist that the code lives on their servers and they maintain it. This is pure lock-in. They want you to depend on them forever, not because they give better service, but because leaving costs more than staying. The code should be yours from day one, in a Git you control, with enough documentation for any other team to continue the work if you wanted to switch.

The green flags: how to recognise a serious partner

The flip side of the above, worth surfacing because good partners don’t always shine in a first meeting. Sometimes they’re quieter, they ask more questions, and they look less salesy than the competition. That’s usually a good sign.

They ask more questions than they give answers in the first meeting. A conversation with a serious partner ends with you exhausted from explaining your business, not with your head full of technical promises.
They document what they understood and send it to you in writing. Within 48-72 hours, a summary of the conversation arrives with your problem reformulated in their words. If you see they got something wrong, there’s time to correct it before any proposal.
They tell you “not this, because…” with specifics. Not every client is a good client for every vendor. If you fit what they do, they’ll tell you. If you don’t, also. That candour saves months of friction.
They lay out phases with deliveries, not a single final milestone. Every 2-4 weeks there’s something concrete to see and validate. It lets you stop the project at any point without losing everything you’ve invested.
They talk about code ownership without you having to drag it out. The topic of code and repository appears in the proposal, you don’t have to pry it loose during negotiation.
They acknowledge what they don’t know. “We haven’t done this before, we’re quoting it with a 20% uncertainty margin and we’ll refine it in the first sprint”. Far better than a “yes, we do that” that later translates into bugs and delays.

Types of partner depending on your need

Not every vendor serves the same purpose. Before searching, it’s worth knowing what type fits your project. This table is honest about the nuances, including where a profile like ours fits:

Type	When it fits	When it doesn’t
Freelance / solo dev	Small projects (under 3 months), well-scoped tasks, quickly validatable MVPs. Lower hourly rate.	Long projects with risk of illness leave or contact loss. Business-critical systems.
Large agency (50-200 employees)	Large projects (over 200,000 EUR), multiple parallel teams, 24/7 coverage needs. When the client is a corporate.	SMBs with mid-range budgets. They put you in the queue and assign the profiles that are left over from larger accounts.
Boutique / small studio (5-15 people)	SMBs with mid-sized projects (30,000-200,000 EUR), direct interlocution with decision-makers and executors. Real commitment to the outcome.	When you need guaranteed 24/7 coverage, huge parallel teams, or tech stacks the studio doesn’t handle.
In-house team	When software is your core business or when volume justifies 3+ full-time engineers for years.	When the project is one-off or you can’t retain technical talent against larger employers.

The most typical SMB mistake is hiring a large agency thinking “more employees = more guarantee” and ending up as the salesperson’s C-tier client. The second mistake is hiring the cheapest freelancer because they fit the budget, and discovering 4 months later that they’ve run out of time for your project.

The 8 questions worth asking in the first meeting

To rule out bad profiles before requesting a formal proposal:

Who will write the code? Give me specific names and profiles. If they can’t, they haven’t thought the project through.
What happens if that person leaves the company mid-project? How do they handle knowledge transfer. If they have no answer, assume it will be your problem.
Can I talk to two of your clients who finished a project similar to mine? The answer must be yes, and the contacts should arrive within a week.
How do you handle scope changes during the project? Any serious project has changes. What distinguishes a good partner is how they handle them: with a clear change-request process, not surprises on the invoice.
How does the project close if we decide to stop early? This is called an exit clause. If they don’t have one drafted, write it yourself. The contract shouldn’t bind you to continue against your will.
Who owns the code and how do you deliver it to me at the end? Yours, in a Git you control, with README and deployment guide. Any other answer is a problem.
Is it mandatory to contract maintenance with you after delivery? It shouldn’t be. They offer maintenance as an option, not as a condition.
What kind of projects do you turn down? Whoever says yes to everything is lying or desperate. A serious partner has criteria for not accepting certain clients.

How to evaluate a proposal properly

Once you have the formal proposals on the table, look beyond price. Compare these six blocks in each:

Scope clarity. Does the proposal describe the problem in your words, or in generic ones? Is there a specific list of features and what’s out of scope? Vague proposals translate into unexpected invoices.

Phases and deliveries. There should be at least 3-4 milestones with dates and deliverables. If there’s only “start - development - final delivery”, they haven’t broken down the risk.

Assigned team. Names, profiles, dedication (full time, part time). If it says “appropriate profiles will be assigned”, assume they haven’t thought about it yet.

Code ownership and delivery. Explicit clause on intellectual property transfer and repository delivery. If it’s not there, require it before signing.

Optional maintenance plan. Detailed, with independent pricing, with SLA if applicable. And, as we said, optional. Not conditioned.

Project exit. What happens if you decide to stop at milestone 2 of 5. What happens if you want to change vendors. What documentation do you receive and in what format.

If two proposals have very different prices but cover these six blocks equally, the difference is usually in the assigned team. Ask. It’s legitimate to request a price breakdown when you have a formal proposal in hand.

The selection stage: how to decide between 2-3 finalists

When you have finalists, what works best is a small paid trial. Not a free proposal (which is paid for somewhere else), but a real mini-phase with a bounded budget: 4,000-8,000 EUR, 2-3 weeks, with a verifiable deliverable. It can be an audit of the current system, a POC of a critical module, a written and defended architecture proposal.

In that phase you see things you don’t see in meetings: how they communicate, whether they meet small deadlines, whether the deliverable quality matches what they promised. Whoever passes that phase is the one you hire for the big project. Whoever fails, you rule out having lost 4,000 EUR instead of the 40,000 EUR you would have lost choosing blind.

The parallel question worth asking before selecting anyone is whether your case justifies a custom application or whether a specific SaaS covers it. We cover that in Custom software vs SaaS: when to choose each. If what you need is to modernise a legacy system, there are also specific nuances that affect the partner profile that suits you: Modernising a legacy ERP: when to migrate and when not to. And if your starting point is a central Excel, here we cover how we approach the migration.

If you want an honest conversation

If you’ve made it this far and think VisibleSoft might fit your case, let’s talk. If not, also: the post still serves to evaluate whoever you decide to hire. A good partner decision usually saves more money than negotiating a 10% discount with the wrong one.

Resources

Custom software vs SaaS: when to choose each: the decision worth making before searching for a partner.
Modernising a legacy ERP: when to migrate and when not to: if your case is modernisation, not greenfield.
Migrating from Excel to custom software: if you start from Excel and don’t know where to begin.
VisibleSoft services: what kind of projects we take on and under what conditions.
Book a free diagnostic