Socios y equipo
Cómo elegir socio técnico si no sabes programar
Socios y equipoLectura estimada: 6 min
Por Equipo editorial de Brotaria
La idea que te llevas
No necesitas fingir que sabes revisar código. Puedes observar cómo entiende el problema, explica decisiones y entrega una prueba; para valorar seguridad o calidad técnica, pide ayuda independiente.
Elegir un socio técnico sin saber programar no consiste en reconocer el lenguaje de moda. Consiste en reunir pruebas de cómo trabaja esa persona y reconocer qué no puedes comprobar tú. Una conversación clara y una demostración ayudan, pero no certifican que el producto sea seguro ni fácil de mantener.
Esta guía parte de que ya conoces a una posible persona con quien emprender. Si todavía no tienes candidatos, empieza por la guía para encontrar socio sin contactos. Aquí el objetivo es distinto: decidir qué observar, qué probar juntos y qué revisar con ayuda antes de comprometer una colaboración mayor. Los ejemplos son hipotéticos.
1. Define qué necesitas antes de evaluar a nadie
Escribe qué tendría que poder hacer una primera versión y qué duda resolvería. «Necesito una app» deja demasiadas decisiones escondidas. «Necesito probar si un taller puede confirmar una cita sin intercambiar varios mensajes» permite discutir una tarea concreta. Anota también qué puedes aportar tú: conocimiento del sector, acceso autorizado a entrevistas, operaciones o ventas.
Aclara el vínculo que propones. ¿Buscas compartir decisiones y construir un proyecto a largo plazo, contratar una entrega definida o recibir asesoramiento puntual? Son conversaciones diferentes. Llamar socio a quien solo esperas que ejecute instrucciones genera expectativas confusas. No uses una promesa imprecisa de participación futura para evitar hablar de compensación y dedicación.
2. Pide una explicación de un trabajo concreto
En lugar de contar tecnologías en un currículum, pide que explique una entrega anterior que tenga permiso para enseñar. ¿Qué problema resolvía? ¿De qué parte fue responsable? ¿Qué decidió no construir? ¿Qué cambiaría ahora? Una descripción precisa de límites aporta más información para la conversación que una lista de herramientas.
No exijas publicar código privado ni datos de clientes. Puede usar una demostración autorizada, un proyecto propio o un ejemplo preparado. Si menciona un trabajo de equipo, separad su contribución de la del resto. Con su permiso, una referencia profesional puede ayudar a entender cómo comunica retrasos y recibe comentarios; no es un sustituto de trabajar juntos.
Observa si puedes reformular lo que te ha explicado sin repetir siglas que no entiendes. Pide aclaraciones y comprueba que ambos habláis de lo mismo. Comunicar con claridad importa, pero una persona convincente también puede equivocarse: no conviertas la facilidad de palabra en una certificación técnica.
3. Separa lo que puedes observar de lo que no
Usa este mapa durante la demostración para anotar evidencias y preguntas pendientes. No es una puntuación para aprobar personas. Su función es evitar que una pantalla que funciona te lleve a dar por comprobadas otras cosas que no has revisado.
| Área | Puedes observar | Pide revisión técnica para |
|---|---|---|
| Problema | Explica para quién sirve la entrega y qué queda fuera. | Contrastar si las limitaciones técnicas cambian la propuesta. |
| Funcionamiento | Recorres una tarea y ves qué ocurre ante un error previsto. | Comprobar pruebas y fallos que la demostración no cubre. |
| Datos | Te muestra con ejemplos ficticios quién ve cada información. | Revisar permisos, accesos y tratamiento técnico de los datos. |
| Continuidad | Identificáis dónde está el trabajo y quién puede acceder. | Valorar si otra persona podría mantenerlo o recuperarlo. |
| Coste | Distingue servicios, frecuencia de pago y supuestos. | Revisar qué gastos pueden variar con el uso y por qué. |
Si una respuesta sigue abierta, escríbela como pendiente. Un «todavía no lo he comprobado» acompañado de un siguiente paso concreto es diferente de una garantía sin explicación. Tú puedes pedir evidencias comprensibles; no tienes por qué adivinar lo que hay detrás de una interfaz.
4. Acordad una prueba pequeña con responsabilidades de ambos
Y Combinator propone, cuando procede, una colaboración de prueba con tiempo y objetivos delimitados para explorar la compatibilidad. La aplicación práctica aquí es elegir una entrega que permita observar decisiones y comunicación, no encargar gratis el producto entero. Acordad alcance, dedicación, condiciones, materiales utilizables y fecha de revisión antes de empezar.
Ejemplo hipotético: para el problema de las citas de un taller, tú preparas tres situaciones ficticias y explicas qué necesita comprobar el responsable. La otra persona propone un flujo pequeño que permita solicitar una hora y mostrar qué pasa cuando ya no está disponible. Lo probáis con datos inventados, sin introducir información de clientes ni presentarlo como un servicio listo para usar.
Al revisar, cambiad una condición sencilla del ejemplo y preguntad cómo la abordaría, sin exigir que lo programe todo en directo. Observa si pregunta antes de asumir, explica consecuencias y distingue una solución temporal de una definitiva. Tu parte también cuenta: entregar contexto y revisar a tiempo permite evaluar una colaboración real, no solo a la otra persona.
5. Encarga una revisión técnica con una pregunta concreta
Antes de usar datos reales o depender de la entrega, pide a una persona técnica independiente que revise el alcance que acordéis. Evita una petición vaga como «dime si es buen programador». Pregunta qué se ha podido verificar, qué riesgo queda abierto y qué trabajo haría falta antes de una prueba con usuarios. Una revisión limitada tampoco acredita todo el producto.
Compartid solo materiales autorizados y los accesos mínimos necesarios. Un repositorio permite organizar cambios y revisiones: GitHub documenta cómo comentar, aprobar o solicitar modificaciones en una propuesta de cambio. Eso deja conversaciones consultables, pero tener un repositorio o una aprobación no demuestra por sí solo seguridad, autoría ni calidad de todo el sistema.
Si no puedes conseguir esa revisión, reduce el compromiso: mantén la prueba aislada y los datos ficticios. No conviertas la falta de revisión en la conclusión de que todo está bien. Si aparecen condiciones legales o un acuerdo societario, tratadlos aparte con asesoramiento adecuado a vuestro país; esta guía no propone porcentajes ni contratos.
6. Decide el siguiente paso, no toda la sociedad
Al terminar, separad tres cosas: lo entregado, cómo os habéis coordinado y las dudas que siguen abiertas. El cuestionario de Y Combinator sobre posibles cofundadores ayuda a hablar de responsabilidades, expectativas y desacuerdos, pero advierte que las preguntas no reemplazan conocerse trabajando. No hace falta convertir una prueba breve en un sí definitivo.
- Continuar: hay una entrega comprensible y ganas de repetir. Definid la siguiente tarea y las comprobaciones pendientes.
- Ajustar: el alcance o la dedicación no estaban claros. Corregidlos antes de interpretar el resultado como falta de capacidad.
- Parar: no podéis aclarar riesgos o expectativas importantes. Cerrad lo acordado sin prometer una relación futura.
Tu tarea de hoy: escribe el problema, una entrega pequeña y tres preguntas que no sabes responder técnicamente. Úsalas para preparar la conversación y buscar la ayuda adecuada. Elegir socio técnico no exige saber hacerlo todo: exige no confundir confianza personal con comprobaciones que aún faltan.
