Cómo elegir un desarrollador web freelance en República Dominicana

Qué mirar en un portafolio, qué tiene que decir una propuesta, por qué pedir avances que puedas abrir desde el teléfono y qué preguntar sobre el dominio, el código y el después. Lo que yo pediría si fuera el cliente.

La página de servicios de este sitio: «Desarrollo web y móvil a medida», las condiciones de trabajo y el botón para contar un proyecto.

Cada cierto tiempo me escribe alguien que ya tuvo una mala experiencia: pagó por una página o un sistema, recibió algo a medias y ahora no tiene ni el código ni el acceso al dominio. Casi nunca es un problema de talento. Es un problema de cómo se contrató: sin alcance escrito, sin avances que ver y sin dejar claro de quién es cada cosa.

Soy desarrollador full-stack freelance en Santo Domingo y trabajo con clientes de aquí y de fuera. Esta guía es lo que yo pediría si estuviera del otro lado de la mesa. Sirve para contratarme a mí y sirve igual para contratar a cualquier otro.

Antes de buscar: qué problema quieres resolver

«Necesito una página web» es el punto de partida más común y el menos útil. Antes de hablar con nadie, intenta responder tres preguntas:

  1. ¿Quién la va a usar y para qué? No es lo mismo un sitio que presenta tu negocio, una tienda donde la gente paga, una aplicación interna donde tu equipo trabaja todos los días o una app en el teléfono de tus clientes.
  2. ¿Qué significa que salga bien? Más reservas, menos llamadas para preguntar lo mismo, un inventario que por fin cuadre. Si puedes decirlo en una frase, el desarrollador puede diseñar para eso.
  3. ¿Qué tienes ya? Un logo, fotos, un catálogo en Excel, una cuenta de Instagram que funciona. Todo eso ahorra tiempo y dinero.

No hace falta saber de tecnología. Hace falta saber qué quieres que pase cuando el proyecto esté listo.

Mira casos completos, no capturas

Un portafolio de capturas bonitas dice poco. Lo que de verdad informa es un caso contado entero: cuál era el problema, qué se decidió y por qué, con qué se construyó y qué pasó después. Si el desarrollador puede explicar sus decisiones, podrá explicarte las tuyas.

En mi caso, los proyectos están publicados así. OMSTA es el sistema de gestión de una agencia de viajes real, con su app móvil, y Delicaté es una tienda en línea que está en producción con su propio dominio. En cada uno puedes leer el alcance, las decisiones de diseño y la ingeniería, y en los que tienen demo, abrirla.

Dos preguntas que vale la pena hacer sobre cualquier caso: ¿está en uso hoy? y ¿qué parte hiciste tú? Las dos tienen respuestas honestas y respuestas evasivas, y se nota.

Pide una propuesta por escrito

«¿Cuánto cuesta?» es la pregunta que todo el mundo hace primero, y la respuesta honesta siempre es la misma: depende del alcance. Lo que sí puedes exigir es que ese alcance quede por escrito antes de pagar nada. Una propuesta seria tiene, como mínimo:

  • Qué se va a construir, en lenguaje que entiendas, pantalla por pantalla o función por función.
  • Qué no entra. Esta parte evita la mayoría de las discusiones.
  • Plazos con fechas o semanas, no «pronto».
  • Presupuesto y forma de pago, con qué se entrega en cada pago.
  • Qué necesita de ti y para cuándo: textos, fotos, accesos, decisiones.

Yo envío esa propuesta después de la primera conversación y antes de escribir una línea de código. Si alguien te da un precio cerrado en el primer mensaje, sin preguntarte casi nada, es que está adivinando.

Avances que puedas abrir desde el teléfono

La forma más sencilla de no llevarte sorpresas es ver el proyecto mientras se hace. No capturas de pantalla: un enlace real que puedas abrir desde tu ordenador o tu teléfono, tocar, y enseñarle a quien quieras.

En mi flujo, cada avance se publica en un enlace de ese tipo. Sirve para dos cosas: tú ves que la cosa existe y avanza, y los dos detectamos pronto lo que hay que cambiar, cuando cambiarlo es barato.

La sección «Cómo trabajo» de la página de servicios, con los cuatro pasos: conversación, propuesta, construcción y lanzamiento.
Los cuatro pasos que sigo en cada proyecto. El tercero, construcción, es el que más tranquilidad da: avances en un enlace real, no en promesas.

Pregunta de quién es el dominio, el código y las cuentas

Aquí es donde más gente sale perdiendo. Antes de empezar, deja por escrito:

  • El dominio está a tu nombre. Tú tienes la cuenta donde se registró, no el desarrollador. Si él lo registra por ti, que lo transfiera o te dé el acceso al terminar.
  • El alojamiento y los servicios (correo, pasarela de pago, base de datos) están en cuentas tuyas o a las que tienes acceso de dueño.
  • El código es tuyo al terminar de pagar, y recibes una copia o el acceso al repositorio.
  • Hay una lista de accesos entregada al final, con todo lo que necesitas para que otra persona pueda seguir el trabajo mañana si hace falta.

Un desarrollador serio no se incomoda con estas preguntas. Es lo normal.

Qué pasa después del lanzamiento

Una web o una aplicación no se termina el día que se publica. Van a hacer falta ajustes, va a haber una renovación de dominio al año, y algún día querrás añadir algo. Pregunta:

  • ¿Quién se ocupa de publicarla y del dominio?
  • ¿Qué pasa si aparece un error en las primeras semanas?
  • ¿Cómo se cobran los cambios pequeños después?

En mi caso, me ocupo de la publicación y del dominio, y acompaño después de la entrega. Lo que importa es que lo sepas antes, no que lo descubras cuando algo falle.

Remoto o en persona, en español o en inglés

Trabajar con alguien en República Dominicana tiene una ventaja obvia si tu negocio está aquí: mismo horario, misma lengua, y reunirse en persona cuando hace falta. Pero contratar a un freelance ya no exige que esté en tu ciudad. Yo trabajo en remoto con clientes de cualquier país, en español o en inglés, y en Santo Domingo podemos vernos en persona.

Lo que sí exige el trabajo remoto es comunicación clara: un canal acordado, respuestas en un tiempo razonable y decisiones por escrito. Pregunta cómo va a ser esa comunicación antes de empezar.

Señales de alerta

Algunas cosas que, si las ves, conviene parar:

  • No hay nada por escrito, o el alcance es una frase.
  • No puede enseñarte un proyecto en uso, o no puede explicar qué hizo en él.
  • Todo estará «listo en una semana», sea lo que sea.
  • No te hace preguntas sobre tu negocio.
  • El dominio o el alojamiento «mejor lo pongo a mi nombre, es más fácil».
  • Pide el pago completo por adelantado.

Ninguna de estas señales demuestra mala fe por sí sola. Juntas, casi siempre.

Cómo trabajo yo

Para que no te quedes con la teoría, así es un proyecto conmigo, de principio a fin:

  1. Conversación. Entiendo el problema, quién lo usará y qué significa que salga bien.
  2. Propuesta. Alcance, plazos y presupuesto por escrito, antes de empezar.
  3. Construcción. Diseño la interfaz antes de programarla y publico cada avance en un enlace real que puedes abrir y probar.
  4. Lanzamiento. Publicación, dominio y acompañamiento después de la entrega.

Construyo aplicaciones web a medida con Django y React, tiendas en línea y sitios de negocio, apps móviles con React Native y, cuando el proyecto lo pide, experiencias 3D como las de este sitio. Todo con casos publicados que puedes abrir antes de escribirme.

Escríbeme

Si tienes un proyecto en mente, cuéntamelo en la página de servicios o directamente en Contacto. Leo cada mensaje y respondo personalmente. Y si lo que querías era sólo esta guía para contratar a otra persona, úsala: está escrita para eso.