A forma máis efectiva de reducir esa asimetría non é converterse en experto técnico antes de pedir un orzamento. É facer as preguntas correctas. As que revelan como traballa realmente o provedor, que prioriza e que vai pasar cando as cousas non saian exactamente como estaban previstas.
— A maioría dos problemas en proxectos de desenvolvemento web son predicibles se se fan as preguntas correctas antes de asinar.
— Estas cinco preguntas non requiren coñecementos técnicos pero revelan con claridade o nivel de madurez do provedor.
— Un bo provedor responde a todas con precisión e sen incomodidade. Un que as evita ou xeneraliza xa che está dicindo algo.
Pregunta 1: De quen será o código cando remate o proxecto?
Esta pregunta parece obvia. A resposta non sempre o é.
Hai provedores que traballan con frameworks propietarios, con construtores visuais de licenza privada ou con compoñentes que son seus e non se transfiren co proxecto. Neses casos, o cliente recibe unha web que funciona pero que non pode manter, modificar nin traspasar a outro desenvolvedor sen perder funcionalidades ou pagar licenzas adicionais.
A resposta que buscas é inequívoca: o código desenvolvido especificamente para o teu proxecto é teu. Podes levalo a outro provedor, podes modificalo, podes facer con el o que necesites. Sen condicións nin asteriscos.
Se a resposta inclúe matices do tipo “depende dos compoñentes” ou “hai partes que son da nosa plataforma”, afonda antes de asinar. Eses matices poden converterse en dependencias custosas a longo prazo.
Pregunta 2: Que documentación entregades co proxecto?
Un proxecto de desenvolvemento web sen documentación é un proxecto que só pode manter quen o construíu. Se ese provedor non está dispoñible no futuro —porque cambia de prezo, porque desaparece, porque simplemente non tedes tempo de coordinarvos— empezades practicamente de cero.
A documentación mínima que debería acompañar calquera proxecto serio inclúe: descrición da arquitectura do sistema, instrucións para o contorno de desenvolvemento, documentación das integracións e APIs usadas, e guía para as tarefas de mantemento máis habituais.
Un provedor que non documenta non é necesariamente deshonesto. Pode ser simplemente que traballa rápido e sen procesos. Pero o resultado para o cliente é o mesmo: dependencia.
O que a resposta revela
Se o provedor responde con precisión —”entregamos un documento de arquitectura, un README con instrucións de contorno e un manual de usuario para as funcionalidades á medida”— estás a falar con alguén que traballa con procesos. Se a resposta é vaga ou o tema parece incómodo, é un sinal de que a documentación non é parte habitual da súa forma de traballar.
Pregunta 3: Como xestionades os cambios de alcance durante o proxecto?
En case todos os proxectos de desenvolvemento, o cliente pide algo que non estaba no briefing inicial. Non por falta de planificación, senón porque é imposible anticipar todos os detalles antes de ver o proxecto tomar forma. A pregunta non é se vai ocorrer, senón como se xestiona cando ocorre.
Un provedor maduro ten un proceso definido: o cambio avalíase, orzamentase e apróbase antes de executarse. Hai transparencia sobre o impacto en prazo e custo antes de que ninguén empece a traballar no novo.
Un provedor sen proceso definido absorbe os cambios sen dicir nada ata que o proxecto remata e a factura final non se parece á inicial, ou vaise rexeitando un a un xerando tensión co cliente.
Ningunha das dúas situacións é boa. O que queres é un proceso claro acordado antes de empezar.
Pregunta 4: Que inclúe o soporte despois da entrega e durante canto tempo?
O lanzamento non é o final do proxecto. É o momento en que o proxecto empeza a vivir en condicións reais, con tráfico real, con usuarios reais que fan cousas que ninguén anticipou nas probas.
Sempre aparece algo despois do lanzamento. Un comportamento inesperado nun dispositivo concreto. Un erro que só ocorre baixo certas condicións. Unha integración que falla con datos reais que non existían no contorno de probas. O que diferencia aos provedores non é se isto ocorre, senón como responden cando ocorre.
Que deberías agardar
Un período mínimo de garantía pos-lanzamento —habitualmente entre 30 e 90 días— no que os erros atribuíbles ao desenvolvemento se corrixen sen custo adicional. E unha proposta clara de que pasa despois dese período: se hai un contrato de mantemento, con que tempos de resposta e a que custo.
Se o provedor non ten unha resposta clara a esta pregunta, estás asumindo un risco que non orzamentaches.
Pregunta 5: Podedes mostrarme un proxecto similar ao meu que entregásedes?
Non un portafolio xenérico. Un proxecto concreto, cunha descrición honesta dos retos que tivo e como se resolveron, e a poder ser coa posibilidade de falar co cliente dese proxecto se tes dúbidas.
Isto filtra rapidamente aos provedores que teñen experiencia real no tipo de proxecto que necesitas dos que teñen experiencia xeral pero nunca resolveron algo parecido ao teu.
Un provedor que fixo integracións con ERP pode mostrar como o fixo, que problemas apareceron e que se aprendeu. Un que nunca o fixo pode presentalo como se fose sinxelo porque non sabe exactamente con que se vai atopar.
Como interpretar a resposta
A mellor resposta é un exemplo concreto con contexto real. A segunda mellor é honestidade: “non fixemos exactamente isto, pero resolvemos problemas similares nestes proxectos e isto é o que aprendemos.” O que non queremos é unha resposta xenérica que evita a pregunta ou un portafolio de capturas de pantalla sen ningún contexto sobre como se construíu o que se ve.
Checklist: sinais dun provedor técnico maduro
- Responde a todas as preguntas anteriores con precisión e sen incomodidade.
- Fai preguntas antes de orzamentar, non despois.
- O orzamento detalla o alcance con suficiente precisión para saber exactamente que inclúe e que non.
- Propón un proceso de validación antes do lanzamento, non só unha entrega final.
- Ten referencias de clientes dispostos a falar sobre a súa experiencia.
- É capaz de dicirche cando algo non ten sentido ou cando hai unha solución mellor á que pediches.
Preguntas frecuentes
É normal que o provedor non queira revelar detalles técnicos antes de asinar?
Ata certo punto, si. Ningún provedor vai compartir a súa metodoloxía completa antes de que haxa un acordo. Pero as cinco preguntas deste artigo non piden segredos técnicos: piden información sobre procesos, condicións contractuais e experiencia previa. Un provedor que se nega a responder a estas preguntas antes de asinar está a poñer os seus intereses por riba dos teus dende o principio.
Que pasa se o provedor máis barato responde ben a todas as preguntas?
Que probablemente é unha boa opción. O prezo non é o único indicador de calidade, e hai provedores que traballan ben e cobran menos porque teñen estruturas de custo máis eficientes ou porque están nunha fase de crecemento onde priorizan construír carteira. As preguntas non están deseñadas para eliminar aos provedores económicos, senón para eliminar aos que non teñen procesos claros independentemente do seu prezo.
Cando é o mellor momento para facer estas preguntas?
Antes de pedir o orzamento, se é posible. Moitas destas preguntas pódense facer na primeira conversa ou reunión exploratoria. Facelas nese momento ten dúas vantaxes: axúdache a decidir se vale a pena seguir adiante con ese provedor antes de investir máis tempo, e indícalle ao provedor que es un cliente que sabe o que pide, o que adoita traducirse nun trato máis profesional dende o principio.
En Baqueiro respondemos a estas cinco preguntas antes de que as fagas, porque forman parte de como explicamos como traballamos dende o primeiro contacto. Se tes un proxecto en mente e queres comezar co pé dereito, falamos.
Tamén pode interesarche: O custo real dunha web barata · Como estruturar un acordo white-label · Que é a débeda técnica e por que destrúe proxectos
La forma más efectiva de reducir esa asimetría no es convertirse en experto técnico antes de pedir un presupuesto. Es hacer las preguntas correctas. Las que revelan cómo trabaja realmente el proveedor, qué prioriza y qué va a pasar cuando las cosas no salgan exactamente como estaban previstas.
— La mayoría de los problemas en proyectos de desarrollo web son predecibles si se hacen las preguntas correctas antes de firmar.
— Estas cinco preguntas no requieren conocimientos técnicos pero revelan con claridad el nivel de madurez del proveedor.
— Un buen proveedor responde a todas con precisión y sin incomodidad. Uno que evita o generaliza ya te está diciendo algo.
Pregunta 1: ¿De quién será el código cuando termine el proyecto?
Esta pregunta parece obvia. La respuesta no siempre lo es.
Hay proveedores que trabajan con frameworks propietarios, con constructores visuales de licencia privada o con componentes que son suyos y no se transfieren con el proyecto. En esos casos, el cliente recibe una web que funciona pero que no puede mantener, modificar ni traspasar a otro desarrollador sin perder funcionalidades o pagar licencias adicionales.
La respuesta que buscas es inequívoca: el código desarrollado específicamente para tu proyecto es tuyo. Puedes llevarlo a otro proveedor, puedes modificarlo, puedes hacer con él lo que necesites. Sin condiciones ni asteriscos.
Si la respuesta incluye matices del tipo “depende de los componentes” o “hay partes que son de nuestra plataforma”, profundiza antes de firmar. Esos matices pueden convertirse en dependencias costosas a largo plazo.
Pregunta 2: ¿Qué documentación entregáis con el proyecto?
Un proyecto de desarrollo web sin documentación es un proyecto que solo puede mantener quien lo construyó. Si ese proveedor no está disponible en el futuro —porque cambia de precio, porque desaparece, porque simplemente no tenéis tiempo de coordinarnos— empezáis prácticamente desde cero.
La documentación mínima que debería acompañar cualquier proyecto serio incluye: descripción de la arquitectura del sistema, instrucciones para el entorno de desarrollo, documentación de las integraciones y APIs usadas, y guía para las tareas de mantenimiento más habituales.
Un proveedor que no documenta no es necesariamente deshonesto. Puede ser simplemente que trabaja rápido y sin procesos. Pero el resultado para el cliente es el mismo: dependencia.
Lo que la respuesta revela
Si el proveedor responde con precisión —”entregamos un documento de arquitectura, un README con instrucciones de entorno y un manual de usuario para las funcionalidades a medida”— estás hablando con alguien que trabaja con procesos. Si la respuesta es vaga o el tema parece incómodo, es una señal de que la documentación no es parte habitual de su forma de trabajar.
Pregunta 3: ¿Cómo gestionáis los cambios de alcance durante el proyecto?
En casi todos los proyectos de desarrollo, el cliente pide algo que no estaba en el briefing inicial. No por falta de planificación, sino porque es imposible anticipar todos los detalles antes de ver el proyecto tomar forma. La pregunta no es si va a ocurrir, sino cómo se gestiona cuando ocurre.
Un proveedor maduro tiene un proceso definido: el cambio se evalúa, se cotiza, se aprueba antes de ejecutarse. Hay transparencia sobre el impacto en plazo y coste antes de que nadie empiece a trabajar en lo nuevo.
Un proveedor sin proceso definido absorbe los cambios sin decir nada hasta que el proyecto termina y la factura final no se parece a la inicial, o los va rechazando uno a uno generando tensión con el cliente.
Ninguna de las dos situaciones es buena. Lo que quieres es un proceso claro acordado antes de empezar.
Pregunta 4: ¿Qué incluye el soporte después de la entrega y durante cuánto tiempo?
El lanzamiento no es el final del proyecto. Es el momento en que el proyecto empieza a vivir en condiciones reales, con tráfico real, con usuarios reales que hacen cosas que nadie anticipó en las pruebas.
Siempre aparece algo después del lanzamiento. Un comportamiento inesperado en un dispositivo concreto. Un error que solo ocurre bajo ciertas condiciones. Una integración que falla con datos reales que no existían en el entorno de pruebas. Lo que diferencia a los proveedores no es si esto ocurre, sino cómo responden cuando ocurre.
Qué deberías esperar
Un período mínimo de garantía post-lanzamiento —habitualmente entre 30 y 90 días— en el que los errores atribuibles al desarrollo se corrigen sin coste adicional. Y una propuesta clara de qué pasa después de ese período: si hay un contrato de mantenimiento, con qué tiempos de respuesta y a qué coste.
Si el proveedor no tiene una respuesta clara a esta pregunta, estás asumiendo un riesgo que no has cotizado.
Pregunta 5: ¿Podéis mostrarme un proyecto similar al mío que hayáis entregado?
No un portfolio genérico. Un proyecto concreto, con una descripción honesta de los retos que tuvo y cómo se resolvieron, y a poder ser con la posibilidad de hablar con el cliente de ese proyecto si tienes dudas.
Esto filtra rápidamente a los proveedores que tienen experiencia real en el tipo de proyecto que necesitas de los que tienen experiencia general pero nunca han resuelto algo parecido a lo tuyo.
Un proveedor que ha hecho integraciones con ERP puede mostrar cómo lo hizo, qué problemas aparecieron y qué se aprendió. Uno que nunca lo ha hecho puede presentarlo como si fuera sencillo porque no sabe exactamente con qué se va a encontrar.
Cómo interpretar la respuesta
La mejor respuesta es un ejemplo concreto con contexto real. La segunda mejor es honestidad: “no hemos hecho exactamente esto, pero hemos resuelto problemas similares en estos proyectos y esto es lo que aprendimos.” Lo que no queremos es una respuesta genérica que evita la pregunta o un portfolio de capturas de pantalla sin ningún contexto sobre cómo se construyó lo que se ve.
Checklist: señales de un proveedor técnico maduro
- Responde a todas las preguntas anteriores con precisión y sin incomodidad.
- Hace preguntas antes de presupuestar, no después.
- El presupuesto detalla el alcance con suficiente precisión para saber exactamente qué incluye y qué no.
- Propone un proceso de validación antes del lanzamiento, no solo una entrega final.
- Tiene referencias de clientes dispuestos a hablar sobre su experiencia.
- Es capaz de decirte cuándo algo no tiene sentido o cuándo hay una solución mejor a la que pediste.
Preguntas frecuentes
¿Es normal que el proveedor no quiera revelar detalles técnicos antes de firmar?
Hasta cierto punto, sí. Ningún proveedor va a compartir su metodología completa antes de que haya un acuerdo. Pero las cinco preguntas de este artículo no piden secretos técnicos: piden información sobre procesos, condiciones contractuales y experiencia previa. Un proveedor que se niega a responder estas preguntas antes de firmar está poniendo sus intereses por encima de los tuyos desde el principio.
¿Qué pasa si el proveedor más barato responde bien a todas las preguntas?
Que probablemente es una buena opción. El precio no es el único indicador de calidad, y hay proveedores que trabajan bien y cobran menos porque tienen estructuras de coste más eficientes o porque están en una fase de crecimiento donde priorizan construir cartera. Las preguntas no están diseñadas para eliminar a los proveedores económicos, sino para eliminar a los que no tienen procesos claros independientemente de su precio.
¿Cuándo es el mejor momento para hacer estas preguntas?
Antes de pedir el presupuesto, si es posible. Muchas de estas preguntas pueden hacerse en la primera conversación o reunión exploratoria. Hacerlas en ese momento tiene dos ventajas: te ayuda a decidir si vale la pena seguir adelante con ese proveedor antes de invertir más tiempo, y le indica al proveedor que eres un cliente que sabe lo que pide, lo que suele traducirse en un trato más profesional desde el principio.
En Baqueiro respondemos a estas cinco preguntas antes de que las hagas, porque forman parte de cómo explicamos cómo trabajamos desde el primer contacto. Si tienes un proyecto en mente y quieres empezar con el pie derecho, hablamos.
También puede interesarte: El coste real de una web barata · Cómo estructurar un acuerdo white-label · Qué es la deuda técnica y por qué destruye proyectos
There is an information asymmetry that greatly complicates purchasing decisions in web development. The client knows what they want to achieve. The provider knows how it’s done. And in between, there is a space where most misunderstandings occur, projects don’t go as expected, and invoices skyrocket without anyone really understanding why.
The most effective way to reduce that asymmetry is not to become a technical expert before requesting a quote. It is to ask the right questions. The ones that reveal how the provider really works, what they prioritize, and what will happen when things don’t go exactly as planned.
— Most problems in web development projects are predictable if the right questions are asked before signing.
— These five questions do not require technical knowledge but clearly reveal the provider’s level of maturity.
— A good provider answers all of them precisely and without discomfort. One who avoids or generalizes them is already telling you something.
Question 1: Who will own the code when the project ends?
This question seems obvious. The answer isn’t always.
Some providers work with proprietary frameworks, private-license visual builders, or components that belong to them and are not transferred with the project. In those cases, the client receives a website that works but cannot be maintained, modified, or transferred to another developer without losing functionality or paying additional licenses.
The answer you are looking for is unequivocal: the code developed specifically for your project is yours. You can take it to another provider, you can modify it, you can do whatever you need with it. No conditions or asterisks.
If the answer includes nuances like “it depends on the components” or “there are parts that belong to our platform,” dig deeper before signing. Those nuances can turn into costly long-term dependencies.
Question 2: What documentation do you deliver with the project?
A web development project without documentation is a project that can only be maintained by the person who built it. If that provider is unavailable in the future—because they change their pricing, because they disappear, or simply because you don’t have time to coordinate—you start practically from scratch.
The minimum documentation that should accompany any serious project includes: a description of the system architecture, instructions for the development environment, documentation of the integrations and APIs used, and a guide for the most common maintenance tasks.
A provider who doesn’t document isn’t necessarily dishonest. It might simply be that they work fast and without processes. But the result for the client is the same: dependency.
What the answer reveals
If the provider answers precisely—”we deliver an architecture document, a README with environment instructions, and a user manual for custom features”—you are talking to someone who works with processes. If the answer is vague or the topic seems uncomfortable, it’s a sign that documentation is not a regular part of their workflow.
Question 3: How do you manage scope changes during the project?
In almost all development projects, the client asks for something that was not in the initial brief. Not out of poor planning, but because it’s impossible to anticipate every detail before seeing the project take shape. The question isn’t whether it will happen, but how it’s managed when it does.
A mature provider has a defined process: the change is evaluated, quoted, and approved before being executed. There is transparency about the impact on time and cost before anyone starts working on the new feature.
A provider without a defined process absorbs the changes without saying anything until the project ends and the final invoice looks nothing like the initial one, or rejects them one by one, generating tension with the client.
Neither situation is good. What you want is a clear process agreed upon before starting.
Question 4: What does post-delivery support include and for how long?
The launch is not the end of the project. It’s the moment the project starts living in real conditions, with real traffic, with real users doing things no one anticipated in testing.
Something always comes up after launch. An unexpected behavior on a specific device. An error that only occurs under certain conditions. An integration that fails with real data that didn’t exist in the staging environment. What differentiates providers isn’t whether this happens, but how they respond when it does.
What you should expect
A minimum post-launch warranty period—usually between 30 and 90 days—during which errors attributable to development are fixed at no additional cost. And a clear proposal for what happens after that period: if there is a maintenance contract, with what response times and at what cost.
If the provider does not have a clear answer to this question, you are assuming a risk you haven’t budgeted for.
Question 5: Can you show me a project similar to mine that you have delivered?
Not a generic portfolio. A specific project, with an honest description of the challenges it faced and how they were solved, and ideally with the possibility of speaking to the client of that project if you have doubts.
This quickly filters out providers who have real experience in the type of project you need from those who have general experience but have never solved anything like yours.
A provider who has done ERP integrations can show how they did it, what problems arose, and what was learned. One who has never done it might present it as if it were simple because they don’t know exactly what they are going to encounter.
How to interpret the answer
The best answer is a concrete example with real context. The second best is honesty: “we haven’t done exactly this, but we have solved similar problems in these projects and this is what we learned.” What we don’t want is a generic answer that avoids the question or a portfolio of screenshots with no context on how what you see was built.
Checklist: signs of a mature technical provider
- Answers all the above questions precisely and without discomfort.
- Asks questions before quoting, not after.
- The quote details the scope with enough precision to know exactly what it includes and what it doesn’t.
- Proposes a validation process before launch, not just a final delivery.
- Has references from clients willing to talk about their experience.
- Is capable of telling you when something doesn’t make sense or when there is a better solution than the one you asked for.
Frequently Asked Questions
Is it normal for the provider to not want to reveal technical details before signing?
To some extent, yes. No provider is going to share their complete methodology before an agreement is in place. But the five questions in this article don’t ask for technical secrets: they ask for information about processes, contractual conditions, and previous experience. A provider who refuses to answer these questions before signing is putting their interests above yours from the beginning.
What if the cheapest provider answers all the questions well?
Then they are probably a good option. Price is not the only indicator of quality, and there are providers who work well and charge less because they have more efficient cost structures or because they are in a growth phase where they prioritize building a portfolio. The questions are not designed to eliminate economical providers, but to eliminate those who lack clear processes regardless of their price.
When is the best time to ask these questions?
Before requesting the quote, if possible. Many of these questions can be asked in the first conversation or exploratory meeting. Asking them at that time has two advantages: it helps you decide if it’s worth moving forward with that provider before investing more time, and it tells the provider that you are a client who knows what they are asking for, which usually translates into more professional treatment from the start.
At Baqueiro, we answer these five questions before you ask them, because they are part of how we explain how we work from the first contact. If you have a project in mind and want to start on the right foot, let’s talk.
You may also be interested in: The real cost of a cheap website · How to structure a white-label agreement · What is technical debt and why it destroys projects