Choosing who to trust with your company's software development is one of the hardest decisions facing executives at mid-sized companies. Not because options are scarce — there are hundreds of agencies and freelancers available — but because quality is difficult to evaluate before the work starts.
Unlike buying machinery or hiring a cleaning service, software is intangible until it is already built. And by then, if you chose poorly, the cost of switching is very high.
This guide gives you seven concrete questions to ask during the evaluation process, and what to look for in each answer.
1. Can you show me projects similar to mine?
Not a generic portfolio. Projects similar to yours: same sector, same scale, same technical complexity.
If your project is a distribution management platform for a mid-sized company, knowing they built a startup's website or a mobile entertainment app is not useful. You need to see that they have solved problems similar to yours.
What to look for in the answer: concrete examples with a description of the business problem they solved, not just screenshots of pretty interfaces. If they only show design and cannot talk about operational impact, that is a warning sign.
2. Who will work on my project and what experience do they have?
Many agencies "sell" with senior profiles and "deliver" with juniors. The difference is not just speed: a developer with little experience makes poor architectural decisions that are very costly to fix later.
Ask to meet the specific team before signing. Not the sales director or CEO — the tech lead and developers who will write code.
What to look for in the answer: real profiles with verifiable experience, willingness to present the team before closing the contract, and clarity about what happens if a team member leaves the project.
3. How do you handle scope changes?
All software projects change. Requirements evolve, constraints appear that were not visible at the start, the business changes direction. The question is not whether there will be changes, but how the vendor handles them.
What to look for in the answer: a clear process. Each change should be evaluated for cost and time before execution, with your approval. If the answer is vague ("we adapt to what you need") or alarming ("any change doubles the price"), neither is a good sign.
4. What happens if the project is delayed?
Delays in software projects are the norm, not the exception. Most projects are delivered late. The difference between a good vendor and a bad one is not whether they run late, but how they communicate it and manage it.
What to look for in the answer: a weekly tracking process, proactive communication of risks, and honesty about their delivery track record. If they say they always deliver on time, they are either lying or lack the experience to know what they do not know.
5. Who owns the code and what access do I have during the project?
It seems obvious, but many contracts are ambiguous on this point. At the end of the project, you want:
- Full ownership of the code: no usage licenses that tie you to the vendor
- Repository access during development: not at the end — from day one
- Documented code: not perfectly (that does not exist), but enough for another developer to continue
What to look for in the answer: contractual clarity on intellectual property, and access to a shared repository from the start of the project. If the vendor is evasive on this point, it is a very serious warning sign.
6. How do you handle testing?
Code without tests is debt you pay with interest. Bugs in production, updates that break existing features, nights of operational crisis. Testing is not a luxury — it is part of doing the job well.
What to look for in the answer: mention of unit tests, integration tests, and some QA process before each delivery. It does not need to be perfect, but it needs to exist. If the answer is "the client does the testing," walk away.
7. What happens after delivery?
Software is not a product you deliver and forget. It needs maintenance, security updates, and small continuous improvements. You need to know who responds when something fails in production.
What to look for in the answer: a post-delivery maintenance proposal with clear response time terms, a distinction between bugs (which should be fixed at no additional cost within a warranty period) and new features (which are billed separately).
The most expensive mistake: choosing by price
The temptation is strong, especially when there is a proposal that costs half of the others. The problem is that the lowest price is rarely the lowest total cost.
A poorly executed project that needs rescuing or rebuilding usually costs between 2x and 5x more than doing it right from the start. And beyond the money: months lost, a worn-out team, operations that could not improve because the system never worked correctly.
Choosing by price without evaluating capability is like choosing the cheapest doctor for surgery.
What matters beyond price
There are three factors that, in our experience, better predict whether a project will succeed:
Clarity in communication. If during the evaluation process it is hard to understand how they work, how they communicate, and what will happen step by step, that does not improve once you sign. Clarity is either there from the start or it is not.
Honesty about limitations. The best vendor is not the one who says "we can handle anything." It is the one who says "this is what we do very well; that other thing is not our specialty." Knowing one's own limitations is a sign of maturity.
Genuine interest in your business. Code is a means, not an end. A good vendor understands what business problem you are solving and makes technical decisions accordingly. If in the first meeting they talk more about technologies than about your operation, that is a signal.
At Alternetica, we run exactly this process with our prospective clients: a diagnostic call where we explore whether we are the right team for your project. If we are not, we tell you. If we are, we explain how we work and what you can expect.
Schedule a no-commitment call. No sales pitch — just a conversation to understand your situation.