Hai termos que se usan moito e se entenden pouco. White-label é un deles.
No desenvolvemento web fálase de white-label para describir situacións moi distintas: desde un freelance que traballa sen aparecer nos créditos ata acordos estruturados entre axencias e partners tecnolóxicos, con contratos, procesos e condicións claras.
A diferenza entre unha cousa e outra non é menor. E se diriximes unha axencia, entendela ben pode cambiar bastante a forma en que formulas o teu modelo de negocio.
O que significa white-label de verdade
Na súa forma máis simple, o desenvolvemento white-label consiste en que unha axencia contrata un equipo técnico externo para executar o desenvolvemento, e ese traballo entrégase ao cliente final baixo a marca da axencia.
O cliente non sabe quen escribiu o código. Tampouco necesita sabelo. O que ve é que a súa axencia de confianza, a que leva a súa estratexia, a súa identidade visual e a súa comunicación, tamén lle entregou unha plataforma tecnicamente sólida.
Desde fóra, todo é coherente. A axencia é a responsable, a axencia é o interlocutor e a axencia é quen factura.
Por detrás hai un partner técnico que fixo o traballo pesado: as integracións, a arquitectura, o código a medida, as automatizacións. Ese partner non aparece na factura do cliente nin no seu contrato. Traballa nun segundo plano e, se todo vai ben, o seu nome nunca chega á conversa.
Por que isto protexe a marxe
A primeira obxección que adoita aparecer cando unha axencia se propón traballar cun partner externo é o custo: “Se teño que pagarlle a alguén máis, onde queda a miña marxe?”
É unha pregunta razoable. E a resposta depende de como esteas a calcular a marxe agora mesmo.
Se estimas proxectos tecnicamente complexos sen ter claro cantas horas van levar, a marxe que aparece no papel non é real. É unha ilusión que se desfai en canto empeza o proxecto e xorden as complicacións que non previras.
Un exemplo habitual: orzamentas unha integración co ERP do cliente en 40 horas porque che parece razoable. A metade do proxecto descobres que o ERP non ofrece por API os datos que necesitas, hai que buscar unha alternativa e acabas dedicándolle máis do dobre. O cliente paga o pactado; a diferenza sae da túa marxe.
Un partner técnico con experiencia nese tipo de proxectos pode darche unha estimación máis axustada antes de que asines nada, porque sabe que preguntar e onde adoitan estar as trampas. Iso por si só xa cambia moito: orzamentas mellor, propós prazos máis realistas e, cando o proxecto remata, a marxe real parécese bastante máis á que calculaches.
Ademais, hai outro tipo de marxe que poucas veces se conta: a de tempo. Cada hora que o teu equipo dedica a pelexar cunha integración complexa para a que non está preparado é unha hora que non dedica ao que si sabe facer ben. Ese custo de oportunidade é real, aínda que non apareza en ningunha folla de cálculo. E cando a saída é rexeitar o proxecto para non meterse nese lío, o custo é aínda maior, aínda que tampouco se vexa: explicámolo en por que a túa axencia perde proxectos sen sabelo.
O que inclúe un bo acordo white-label
Non todo o que se chama white-label funciona igual. A diferenza entre un acordo que protexe a axencia e outro que a deixa exposta está nos detalles.
Un acordo ben estruturado cobre, como mínimo, estes puntos:
Confidencialidade en ambas as direccións. O partner técnico non revela que traballa para a túa axencia nin contacta directamente cos teus clientes, nin durante o proxecto nin despois. Pola túa parte, a información do partner (tarifas, ferramentas internas, forma de traballar) tampouco sae da túa axencia.
Propiedade do código. O código desenvolvido para un proxecto do teu cliente é do teu cliente (ou da túa axencia, segundo o que pactases con el), non do partner técnico. Importa porque hai provedores que traballan con compoñentes propietarios que xeran dependencia. Un bo partner entrega o código limpo, documentado e sen ataduras, coas licenzas de terceiros a nome de quen corresponda. En cláusulas técnicas que o teu contrato de desenvolvemento debería incluír tes máis detalle sobre como deixalo por escrito.
Proceso de comunicación definido. Quen fala con quen? Como se xestionan os cambios de alcance? Quen toma as decisións técnicas cando o cliente pide algo que non estaba previsto? Estes fluxos teñen que acordarse antes de que comece o proxecto, non improvisarse a metade.
Prazos reais. Un partner técnico serio non acepta prazos imposibles para gañar o proxecto e despois renegocia cando xa non hai marxe de manobra. Se o prazo non é viable, dío desde o principio e propón unha alternativa.
Condicións económicas claras. Prezo pechado ou por horas, que inclúe e que non, cando se factura e como se valoran os cambios de alcance. Se isto queda no aire, o primeiro imprevisto convértese nunha discusión sobre diñeiro en lugar dun problema técnico que resolver.
Que pasa se algo falla. Os erros existen. As integracións rompen. O contorno de produción dá sorpresas que o de desenvolvemento non daba. Un acordo maduro define como se xestiona o soporte despois da entrega, con que tempos de resposta e quen é responsable de que.
O modelo que máis sentido ten para unha axencia en crecemento
Hai axencias que traballan con distintos partners segundo o tipo de proxecto: un para WordPress, outro para desenvolvemento a medida, outro para integracións con ERP. En teoría, iso dá flexibilidade. Na práctica, xera fricción constante, porque cada proxecto empeza de cero con alguén diferente.
O modelo que mellor funciona a medio prazo é construír unha relación estable con 1 ou 2 partners técnicos que coñezan ben a túa forma de traballar, os teus clientes habituais e o nivel de calidade que esperas.
Iso non se constrúe nun proxecto, senón en varios. Con cada entrega, o partner entende mellor que tipo de briefings preparas, como te comunicas co cliente, que nivel de documentación esperas e como reaccionas ante un imprevisto. E ti entendes como traballa, cales son os seus puntos fortes, en que proxectos brilla e en cales é mellor buscar outra solución.
Ese contexto acumulado ten un valor que non se consegue cun orzamento puntual.
Como afecta isto á relación co cliente final
Hai axencias que se senten incómodas coa idea de que o cliente non saiba que parte do traballo o fai un terceiro. É un escrúpulo lexítimo e merece pensarse con honestidade.
A realidade é que o cliente non compra horas de persoas concretas. Compra un resultado: a garantía de que a súa axencia vai entregar algo que funcione, que resolva o seu problema e que estea á altura do acordado.
Cando contratas un despacho de avogados, non esperas que o avogado que te atende redacte persoalmente cada escrito. Ten asociados, colaboradores e provedores externos. O que esperas é que o resultado sexa bo e que el responda de que así sexa.
Unha axencia que traballa cun partner técnico de confianza está exactamente nesa posición: é a responsable do resultado, e o partner forma parte do equipo que o fai posible. Non hai contradición.
O que si sería un problema é atribuírte capacidades que non tes, prometer prazos que non podes cumprir ou entregar un traballo que non está á altura só para manter a aparencia de que o fas todo internamente. Iso non é un problema do modelo white-label. É un problema de honestidade, e existe traballes ou non con partners.
Cando ten sentido empezar
Non fai falta agardar a ter un proxecto enorme para establecer unha relación cun partner técnico. De feito, empezar cun proxecto de tamaño medio, con certa complexidade pero sen a presión dun cliente estratéxico, é a mellor forma de construír a confianza que vas necesitar cando cheguen os grandes.
O ideal é ter esa conversa antes de necesitala. Antes de que entre o proxecto que te supera. Antes de ter que dicirlle que si a un cliente coa esperanza de que todo saia ben.
Porque nese momento, co cliente agardando resposta e o prazo correndo, xa non estás a escoller un partner. Estás a buscar alguén que estea dispoñible. E iso poucas veces remata ben.
En Baqueiro traballamos con axencias en formato white-label en proxectos que requiren desenvolvemento a medida, integracións e automatización. Se queres ver como podería funcionar no teu caso concreto, falamos sen compromiso.