How to choose a software development company in Colombia: 7 questions before you sign
Choosing the wrong team to build your system costs more than the system. Seven concrete questions to ask any vendor, the answers you should expect and the warning signs we see repeated.
There is an uncomfortable truth about software projects: most of the ones that fail do not fail because of technology but because of the relationship. Poorly defined scopes, impossible promises, weeks of silence, a system that gets delivered and nobody knows how to maintain. Choosing the vendor well is, by far, the decision that weighs most on the outcome. These are the seven questions we recommend asking before signing, with what you should expect to hear.
1. "How will you understand my business before proposing anything?"
What you should hear: a concrete process. Meetings with the people who do the work (not only management), a review of how they operate today, uncomfortable questions about exceptions and edge cases. For large projects, a short, fixed-cost discovery phase before the final quote.
Warning sign: a detailed proposal that arrives in a day without having spoken to anyone in operations. It means they are selling what they already have, not what you need.
2. "Who will own the code and the data?"
What you should hear: you, unconditionally, in writing in the contract. With access to the code repository from the start of the project, not at the end. The database in an account belonging to your company or fully exportable at any time.
Warning sign: "the code is ours but you have a license to use it", or vagueness about what happens if the relationship ends. This turns your operation into a hostage.
3. "How will I see progress?"
What you should hear: regular demonstrations of the working system, every two to four weeks, where you can use it and give feedback. A direct channel to the team. A visible list of what is done, what is in progress and what comes next.
Warning sign: "we'll show you when it's finished". Projects that are only seen at the end are the ones delivered late and different from what was expected.
4. "What happens when something changes mid-project?"
What you should hear: that changes are normal and there is a process: the impact on time and cost is evaluated, you decide together whether it goes into this phase or the next, and it is put in writing. A good vendor helps you tell the change that is worth it from the one that only delays.
Warning sign: either "everything is included" (nobody can promise that and they will end up charging for it some other way), or every change is an argument and a surprise invoice.
5. "What does delivery include?"
What you should hear: the system tested, installed in a production environment, with data migrated if applicable, the team trained, user documentation and enough technical documentation for another team to be able to continue. A support period after launch, when the real adjustments appear.
Warning sign: "we deliver the code". A system without go-live, training and follow-up is a half-finished project.
6. "And after delivery?"
What you should hear: clear support and evolution options (a bank of hours, a monthly fee or on demand), with response times defined by severity. Who is in charge of hosting, backups and security updates. A living system needs care; this should be planned from the start.
Warning sign: no answer, or the answer is "message us if something breaks". A vendor without a support plan probably does not have one for its own team either.
7. "What have you built that is similar to this?"
What you should hear: an honest description of projects of the same kind: what the system did, for what kind of operation, what was hard and what they learned. You do not need to see other clients' code or confidential data; you need to know the problem is not new to them. And if it is new, they should say so.
Warning sign: "we've done everything". Nobody has done everything. A portfolio full of logos without being able to explain what they did for each one is also a warning.
Three things that should not decide for you
- The lowest price. If a proposal costs half of the others, it is almost always because it describes half of the work. Compare scopes, not totals. In another article we explain what drives the cost of custom software.
- The fashionable technology. A good vendor chooses technology according to the problem, the expected life of the system and how easy it is to find people to maintain it. If the conversation revolves around tool names instead of your operation, be careful.
- The vendor's size. A huge company may assign you its least experienced team; a very small one may disappear. What matters is who will work on your project and what happens if that person is not there.
A way to reduce the risk
If you are torn between two or three vendors, propose the same thing to all of them: a short first phase, with closed scope and price, that delivers something already usable. A module, a flow, an integration. In four to eight weeks you will see how they work, how they communicate and what quality they deliver, with little money at stake. It is the best possible interview, and a vendor that refuses it is telling you something.
In short
Choosing a development company is choosing a relationship of years. Ask about the process, code ownership, how you will see progress, changes, delivery and what comes after. The answers, and the candor with which they arrive, say more than any portfolio.
At Arista we have been building systems for companies in Colombia from Medellín for more than 10 years, and we answer these seven questions in the first conversation, before you ask them. If you are choosing a vendor, message us on WhatsApp and we will tell you how we work.
Frequently asked questions
Is a company better than a freelance developer?
It depends on size and duration. For something small and one-off, a good freelancer can be perfect. For a system your operation will depend on for years, a company offers continuity: if one person leaves, the project continues, there is documentation and someone to answer.
Should I ask for client references?
Yes, but understand that many projects are confidential. A serious vendor can describe what kinds of systems they have built, for which industries and with what results, even if they do not show other clients' code or data. What they should have no problem showing is their process.
What happens if the project runs late?
Delays exist in every software project; what matters is that they are seen coming. Ask how they report progress (regular demos, not only reports) and what they do when something drifts. A vendor that is never late on paper usually has surprises at the end.
Sign a long contract or start with something small?
Starting with a short, well-defined phase is the best way to evaluate a vendor at low risk. If the first phase goes well, the relationship continues; if not, you learned with little money at stake.