Siete preguntas para hacerle a un proveedor de software antes de firmar
Ninguna es técnica. Todas se pueden hacer sin saber una línea de código, y las respuestas te dicen más que cualquier propuesta.
Seven questions to ask a software vendor before you sign
None of them technical. You can ask them without knowing a line of code, and the answers tell you more than any proposal.
Cuando contratás un sistema hay un problema de fondo: no podés evaluar el trabajo técnico. No sabés si el código es bueno, si lo que te prometen es realista, si dentro de un año se va a poder sostener. Y está bien —no tenés por qué saberlo—. Pero eso te deja eligiendo casi a ciegas, y el precio no alcanza para decidir.
La salida no es aprender a programar. Es cambiar qué evaluás: en lugar del trabajo, evaluá al proveedor. Estas siete preguntas no requieren ningún conocimiento técnico, y lo que revelan las respuestas dice bastante más que un PDF de propuesta.
Y sí: hacéselas a nosotros también.
01
"¿De quién son los datos, y me los puedo llevar?"
El día que quieras cambiar de proveedor, tus datos son lo único que no se puede rehacer. Un sistema se reescribe; años de información de tus clientes, tus ventas y tu operación, no. Si esa información queda atrapada en un formato que solo entiende su sistema, no estás contratando un servicio: estás quedando preso.
Buena señal
"Los datos son tuyos. Te los exportamos cuando quieras, en un formato estándar, sin cargo."
Señal de alarma
Respuestas vagas, "eso lo vemos más adelante", o un costo por sacar tu propia información.
02
"¿Quién va a escribir el código, y quién lo mantiene después?"
En muchas empresas hablás con un vendedor pulido y el trabajo lo termina haciendo otro que nunca viste, a veces tercerizado en otro país. Y un sistema no termina el día que se entrega: alguien tiene que arreglarlo cuando se rompe y adaptarlo cuando tu negocio cambia.
Buena señal
Te dicen con nombre y apellido quién hace el trabajo, y qué pasa con el mantenimiento después de la entrega.
Señal de alarma
No queda claro quién ejecuta, o el interés se evapora apenas se firma la entrega.
03
"¿Qué pasa si a mitad de camino cambia lo que necesito?"
Va a cambiar. Siempre cambia: arrancás pidiendo una cosa y a las tres semanas entendés mejor tu propio problema. Lo que importa no es evitarlo, es si eso ya está previsto o si cada ajuste se convierte en una pelea y una factura sorpresa.
Buena señal
Te explican cómo manejan los cambios de alcance antes de que ocurran, y con qué criterio.
Señal de alarma
Un precio cerrado sospechosamente bajo —lo van a recuperar en "extras"— o cobrar por hora sin ningún techo.
04
"¿Hay algo que ya exista que resuelva esto sin construir nada?"
Esta es la pregunta trampa, y la más reveladora de todas. Muchos problemas se resuelven con una herramienta que ya existe y cuesta una fracción de lo que sale construir a medida. Un proveedor que, para todo, siempre te propone desarrollar algo nuevo, te está vendiendo horas —no soluciones.
Buena señal
"Para esto no hace falta que construyamos nada; con tal herramienta lo resolvés más barato y más rápido."
Señal de alarma
La respuesta nunca, jamás, es "no lo construyas".
05
"¿Con quién puedo hablar de un trabajo parecido que ya hayan hecho?"
Una referencia con la que puedas hablar cinco minutos vale más que cualquier portfolio. Y no tanto por lo que hicieron, sino por lo que vas a poder preguntar: cómo fue trabajar con ellos cuando algo salió mal, si cumplieron los plazos, si aparecieron después de cobrar.
Buena señal
Te conectan con un cliente real sin poner peros.
Señal de alarma
Excusas, demoras, o solo una fila de logos sin nadie detrás con quien hablar.
06
"¿Qué van a necesitar de mi lado?"
Ningún proyecto de software sale bien si del lado del cliente no hay alguien con tiempo y con autoridad para decidir. El que mejor conoce tu problema sos vos y tu gente; sin ese acceso, el proveedor termina adivinando. Quien te promete que no vas a tener que hacer nada, o no entendió el problema, o te está diciendo lo que querés escuchar.
Buena señal
Te piden un referente, decisiones a tiempo y acceso a la gente que hace el trabajo hoy.
Señal de alarma
"Vos no te preocupés por nada, nosotros nos encargamos de todo."
07
"¿Qué pasa el día que algo se rompe?"
Se va a romper —todo software se rompe alguna vez—. La pregunta no es si pasa, es qué tan rápido lo resuelven y cuánto te cuesta. La respuesta define si el sistema termina siendo un activo o simplemente un dolor de cabeza nuevo, distinto del que tenías antes.
Buena señal
Hay un acuerdo claro de soporte: a quién llamás, en cuánto tiempo responden y qué incluye.
Señal de alarma
No hay respuesta concreta, o queda en "escribinos un mail y vemos".
Ninguna de estas siete preguntas es técnica. Se pueden hacer sin saber una línea de código, y lo que revelan es lo único que de verdad podés evaluar antes de firmar: si del otro lado hay alguien dispuesto a responder por lo que hace.
Hacéselas a cualquiera que te quiera vender un sistema. A nosotros incluidos —de hecho, si querés, empecemos por ahí.
When you hire a system there is a problem underneath: you cannot judge the technical work. You do not know whether the code is good, whether what they promise is realistic, whether it will hold up in a year. And that is fine —you should not have to know—. But it leaves you choosing almost blind, and price alone is not enough to decide.
The way out is not to learn to program. It is to change what you evaluate: instead of the work, evaluate the vendor. These seven questions require no technical knowledge, and what the answers reveal says far more than a proposal PDF.
And yes: ask them of us too.
01
"Whose data is it, and can I take it with me?"
The day you want to switch vendors, your data is the one thing that cannot be rebuilt. A system can be rewritten; years of information about your clients, your sales and your operation cannot. If that information is trapped in a format only their system understands, you are not buying a service: you are getting locked in.
Good sign
"The data is yours. We export it whenever you want, in a standard format, at no charge."
Red flag
Vague answers, "we'll look at that later", or a fee to get your own information out.
02
"Who writes the code, and who maintains it afterward?"
At many companies you talk to a polished salesperson and the work ends up done by someone you never met, sometimes outsourced to another country. And a system does not end the day it ships: someone has to fix it when it breaks and adapt it when your business changes.
Good sign
They tell you by name who does the work, and what happens with maintenance after delivery.
Red flag
It is unclear who actually builds it, or the interest evaporates the moment delivery is signed.
03
"What happens if what I need changes halfway through?"
It will change. It always does: you start asking for one thing and three weeks in you understand your own problem better. What matters is not avoiding it, but whether it is already accounted for or every adjustment turns into a fight and a surprise invoice.
Good sign
They explain how they handle scope changes before they happen, and on what basis.
Red flag
A suspiciously low fixed price —they will make it back on "extras"— or hourly billing with no ceiling.
04
"Is there something that already exists that solves this without building anything?"
This is the trick question, and the most revealing of all. Many problems are solved by a tool that already exists and costs a fraction of building custom. A vendor who, for everything, always proposes developing something new is selling you hours —not solutions.
Good sign
"You don't need us to build anything for this; with such-and-such tool you solve it cheaper and faster."
Red flag
The answer is never, ever, "don't build it".
05
"Who can I talk to about similar work you've done?"
A reference you can talk to for five minutes is worth more than any portfolio. And not so much for what they did, but for what you get to ask: what it was like to work with them when something went wrong, whether they hit the deadlines, whether they stuck around after getting paid.
Good sign
They connect you with a real client without hesitation.
Red flag
Excuses, delays, or just a row of logos with no one behind them to talk to.
06
"What will you need from my side?"
No software project goes well if there is no one on the client side with time and the authority to decide. The person who knows your problem best is you and your team; without that access, the vendor ends up guessing. Anyone who promises you will not have to do anything either did not understand the problem or is telling you what you want to hear.
Good sign
They ask for a point person, timely decisions, and access to the people doing the work today.
Red flag
"Don't you worry about a thing, we'll take care of everything."
07
"What happens the day something breaks?"
It will break —all software breaks eventually—. The question is not whether, it is how fast they fix it and what it costs you. The answer decides whether the system becomes an asset or just a new headache, different from the one you had before.
Good sign
There is a clear support agreement: who you call, how fast they respond, and what it covers.
Red flag
No concrete answer, or it stalls at "email us and we'll see".
None of these seven questions is technical. They can be asked without knowing a line of code, and what they reveal is the one thing you can actually judge before signing: whether there is someone on the other side willing to answer for what they do.
Ask them of anyone trying to sell you a system. Us included —in fact, if you like, let's start there.