El desarrollo de plugins WordPress a medida consiste en escribir un plugin para las reglas de un solo negocio, y no para un mercado general. Es la decisión correcta cuando tu proceso es específico, cuando un plugin de marketplace te obliga a torcer el proceso para adaptarte a él, o cuando la lógica es demasiado importante para vivir en un tema o en una pila de complementos de terceros.
Esta guía es para dueños, directores y responsables de área que deben elegir entre instalar un plugin más o encargar un desarrollo. Encontrarás los criterios de decisión, el proceso desde el alcance hasta el mantenimiento, los factores que mueven el costo y el plazo, las bases de seguridad que aplica un buen desarrollador y las preguntas que conviene hacer antes de firmar.
Aquí no damos precios, porque un precio sin tu alcance es ficción. Si ya sabes que quieres un desarrollo, nuestra página de servicios de desarrollo de plugins WordPress a medida explica cómo trabajamos. Este artículo es la versión neutral.
Puntos clave
- Un plugin a medida compensa cuando la lógica es específica de tu negocio y un plugin de marketplace te obligaría a cambiar tu proceso.
- El código del tema es el lugar equivocado para la funcionalidad: todo lo que deba sobrevivir a un rediseño pertenece a un plugin.
- El costo sigue al alcance, a las integraciones y a la revisión, no a las líneas de código, así que un alcance escrito con exclusiones importa más que un presupuesto rápido.
- La seguridad y la compatibilidad con las actualizaciones de WordPress, PHP y WooCommerce forman parte del desarrollo, no son extras opcionales.
- La propiedad del repositorio y de la documentación debe quedar escrita en el contrato antes de empezar.
Qué significa el desarrollo de plugins WordPress a medida
Un plugin de WordPress es un paquete de PHP, y a menudo de JavaScript y CSS, que modifica WordPress mediante actions y filters. Desarrollar un plugin a medida es escribir ese paquete para una sola organización: su modelo de datos, sus roles, sus integraciones y su flujo de aprobación. El Plugin Handbook oficial es la referencia sobre cómo se estructuran los plugins y cómo se comunican con el core.
Qué es y qué no es un plugin a medida
Un plugin a medida es código que encargas, guardas en un repositorio que es tuyo y mantienes frente a las versiones de WordPress. No es un plugin de marketplace con tu logo. No es un fragmento pegado en functions.php. Tampoco significa construirlo todo desde cero: uno bueno reutiliza las APIs del core en lugar de reescribirlas.
Esa distinción define el presupuesto. Pagas por la parte que es específica de ti, no por rehacer lo que WordPress ya hace.
Por qué la funcionalidad va en un plugin y no en el tema
Usa una sola regla: dónde vive. La funcionalidad que debe sobrevivir a un rediseño va en un plugin. La presentación va en el tema.
Si tus custom post types, tus reglas de precios o la sincronización con el CRM están en el tema, cambiar de tema los rompe. El sitio sigue viéndose bien, pero los datos desaparecen del administrador. Además, un plugin se activa, se desactiva y se prueba por separado, algo que un tema lleno de lógica de negocio no permite.
Plugin a medida, plugin comercial o código en el tema
Hay tres lugares donde puede vivir una funcionalidad, y cada uno encaja en una situación distinta. La tabla los compara en los seis criterios que resuelven la mayoría de los casos.
Tabla de decisión: tres opciones, seis criterios
| Criterio | Plugin a medida | Plugin comercial | Código en el tema |
|---|---|---|---|
| Ajuste a tu proceso | Construido en torno a tus reglas | Configurable dentro del modelo del proveedor | Encaja con el diseño actual, poco más |
| Costo inicial | El más alto | El más bajo, a menudo una licencia | Bajo para cambios pequeños |
| Costo a largo plazo | Mantenimiento que planificas y controlas | Renovaciones, más soluciones improvisadas a medida que crecen las necesidades | Sube con cada rediseño |
| Riesgo en actualizaciones | Controlado, probado contra tu propio código | Depende del proveedor y de tu mezcla de plugins | Las actualizaciones del tema pueden pisar los cambios |
| Portabilidad si cambias de tema | Total, sobrevive a un rediseño | Total | Ninguna, se va con el tema |
| Propiedad | Tuya, si el contrato lo dice | Una licencia, sin control sobre la hoja de ruta | Tuya, pero enredada con el diseño |
Léela por filas, no por totales. Una empresa regulada puede valorar sobre todo la propiedad y el riesgo en actualizaciones, mientras que una tienda pequeña quizá solo mire el costo inicial. Pondera las filas que te importan. Para los riesgos más amplios de apilar plugins, lee nuestro ensayo sobre el problema de los plugins.
Señales de que basta un plugin comercial
Compra antes de construir. Un plugin maduro, instalado en muchos sitios, ha enfrentado más casos límite que la primera versión de cualquier código a medida. Un plugin comercial basta cuando:
- La necesidad es común: formularios, metadatos SEO, caché, copias de seguridad, redirecciones.
- El plugin tiene mantenimiento activo, con versiones recientes y una versión "tested up to" actual.
- Puedes aceptar su flujo de trabajo sin cambiar cómo trabaja tu equipo.
- Un plugin hace un trabajo, y no estás combinando tres para imitar un único flujo.
Señales de que necesitas un plugin a medida
Construye cuando el costo de torcer tu proceso supera el costo del código. Señales típicas:
- Alguien copia datos a mano entre WordPress y una hoja de cálculo, un ERP o un CRM.
- Varios plugins aproximan un solo flujo y cada actualización rompe la unión.
- La lógica codifica una regla importante para el negocio: niveles de precios, aprobaciones, residencia de datos.
- Un sistema del que dependes tiene API pero no un plugin de WordPress mantenido.
- Los editores rodean el CMS porque el modelo de contenido no coincide con tu contenido.
Una señal es una conversación. Tres señales suelen ser un desarrollo.
Casos de uso típicos de un plugin WordPress a medida
Cuatro trabajos concentran la mayoría de los plugins a medida que nos piden los equipos. Cada uno parte de un detonante distinto, resumido abajo y detallado después.
Integración
Sincronización con ERP y CRM
Los pedidos o leads se reescriben en otro sistema y el stock o los datos de clientes quedan desactualizados en el sitio.
Modelo de contenido
Custom post types
Tu contenido no son entradas y páginas: sedes, fichas técnicas, cursos o casos de estudio necesitan su propia estructura.
Comercio
Extensión de WooCommerce
Los precios, envíos o reglas de pedido siguen tus contratos, y las pantallas de ajustes no pueden expresarlos.
Edición
Bloques de Gutenberg
Los editores rehacen a mano el mismo diseño y el resultado se aleja de tu marca.
Integraciones con ERP y CRM
WordPress guarda los pedidos, los leads y las entradas de formularios. El ERP o el CRM guarda la verdad sobre stock, clientes y facturas. Un plugin a medida los conecta mediante REST APIs y webhooks, encola las llamadas para que un ERP lento nunca ralentice el checkout y registra los fallos para que alguien pueda reintentar.
La primera petición es fácil. Lo difícil es la idempotencia, los reintentos y qué pasa cuando los dos sistemas no coinciden.
Custom post types y modelos de datos
Cuando tu contenido no son entradas y páginas (fichas de producto, sedes, cursos, casos de estudio), lo modelas con custom post types, taxonomías y campos registrados en un plugin. Registrarlos en un plugin significa que los datos sobreviven a un rediseño. Planifica de antemano roles, permalinks, exposición REST y columnas del administrador, porque añadirlos después, con miles de entradas, sale caro.
Extensiones de WooCommerce
Precios por grupo de clientes, reglas de pedido mínimo, flujos de cotización, envíos específicos por transportista y estados de pedido que coincidan con tu almacén pertenecen a una extensión. WooCommerce expone hooks y filters para esto, de modo que el plugin cambia el comportamiento sin editar WooCommerce y la tienda sigue siendo actualizable. Una buena extensión también declara compatibilidad con funciones como High-Performance Order Storage.
Bloques de Gutenberg para editores
Si tu equipo de marketing rehace a mano el mismo diseño cada semana, los bloques a medida dan a los editores un componente acotado y fiel a la marca. Los bloques usan la API de bloques: un archivo block.json, una interfaz de editor en React y renderizado en servidor cuando hace falta. Los editores insertan una tabla de precios en lugar de doce columnas anidadas.
Cómo funciona el proceso de desarrollo de un plugin
El proceso tiene seis etapas y un bucle. Saltarse las dos primeras es el motivo más común de que los plugins a medida se pasen de presupuesto.
Proceso de desarrollo de plugins
- 01AlcanceEntregable: especificación escrita
- 02ArquitecturaEntregable: modelo de datos y hooks
- 03DesarrolloEntregable: código probado
- 04Revisión en stagingEntregable: aprobación del cliente
- 05LanzamientoEntregable: versión etiquetada
- 06MantenimientoEntregable: pruebas de compatibilidad
Seis etapas de desarrollo de un plugin, del alcance al mantenimiento, con bucle al alcance si cambian los requisitos
Cada etapa termina con un entregable que puedes inspeccionar. Eso es lo que pagas en cada paso.
Alcance y descubrimiento técnico
El descubrimiento produce una especificación escrita: el problema, los usuarios y roles, los datos implicados, los sistemas tocados, lo que queda fuera del alcance y cómo sabrás que funciona. Leemos el sitio existente, listamos los plugins activos, revisamos la versión de PHP y los límites del hosting, y obtenemos la documentación de la API y un acceso sandbox a cualquier sistema de terceros.
Tú aportas a quien decide, acceso a los sistemas y ejemplos reales de los datos, incluidas las filas desordenadas. Un planteamiento del problema de una página vale más que un documento de requisitos de cuarenta.
Arquitectura, desarrollo y revisión en staging
La arquitectura decide el modelo de datos, los hooks que usa el plugin, dónde viven los ajustes, cómo falla y cómo se prueba. Después el desarrollo avanza en incrementos pequeños, cada uno integrado mediante pull request en un repositorio Git y desplegado en una copia de staging de tu sitio con contenido realista.
Revisas en staging contra los criterios de aceptación del descubrimiento. Un malentendido cuesta poco en staging y mucho en producción.
Lanzamiento, traspaso y mantenimiento
Un lanzamiento es una versión etiquetada, un despliegue con vía de vuelta atrás y un periodo corto vigilando los logs. El traspaso es el repositorio, la documentación y una explicación de cómo extenderlo.
Después empieza el mantenimiento: las versiones de WordPress, PHP y dependencias siguen llegando y tu negocio sigue cambiando. Un nuevo requisito devuelve el plugin al alcance, y por eso el diagrama hace un bucle.
Qué impulsa el costo del desarrollo de plugins WordPress a medida
El costo sigue al alcance y al riesgo, no a las líneas de código. Un plugin corto que toca pagos puede costar más que uno largo que renderiza un bloque. Para presupuestos de un sitio completo, lee nuestro desglose de lo que cuesta un sitio WordPress a medida. Aquí nos quedamos en el plugin y en los cuatro factores que mueven su precio.
Alcance y número de roles de usuario
Cada rol distinto (administrador, editor, comercial, cliente, socio) multiplica las pantallas, las reglas de permisos y los casos de prueba. Una línea como "gestionar pedidos" esconde una docena de decisiones sobre quién puede ver, editar, exportar y borrar. Escribe los roles y las acciones en una tabla antes de pedir un presupuesto.
Integraciones de terceros y volumen de datos
Una integración es una dependencia que no controlas. El esfuerzo crece con la calidad de la otra API (documentación, sandbox, límites de peticiones), con la dirección de la sincronización (en un sentido es más simple que en dos) y con el volumen de datos, que obliga a usar colas, lotes y paginación. Migrar datos históricos suele ser un proyecto dentro del proyecto.
Estas barras muestran esfuerzo relativo, no dinero. Toma dos solicitudes que suenan pequeñas. Un conjunto de bloques para miembros del equipo necesita un desarrollador, un archivo de diseño y un par de revisiones en staging. Una sincronización bidireccional con un ERP necesita documentación de la API, credenciales de sandbox, una cola de reintentos, una pantalla de administración para sincronizaciones fallidas y pruebas con pedidos reales: reembolsos, envíos parciales y distintas reglas de impuestos. La misma palabra, un trabajo muy distinto.
Revisión de seguridad, QA y documentación
Una revisión de nonces, comprobaciones de capacidades, sanitización y escapado, comprobaciones automáticas de estilo, pruebas manuales con cada rol y documentación escrita no son extras. Un presupuesto que los omite es más barato porque omite trabajo, y ese trabajo lo pagas después en forma de incidentes.
Actualizaciones y propiedad a largo plazo
Presupuesta el segundo año: actualizaciones de compatibilidad, nuevos requisitos y cambios de hosting. Trata el plugin como software que operas, no como una compra que termina.
El plazo sigue los mismos factores. El descubrimiento depende de cuánto esté ya escrito, y el desarrollo, del alcance y de las integraciones. El retraso más largo suele ser esperar credenciales de terceros o una decisión de tu lado.
Calidad de código y seguridad en el desarrollo de plugins WordPress a medida
La mayoría de las vulnerabilidades de los plugins no son exóticas. Son un nonce ausente, una comprobación de capacidades ausente, una entrada sin sanitizar o una salida sin escapar. Las WordPress Security APIs documentan las cuatro, y un desarrollador competente las aplica por costumbre.
Estándares de código de WordPress y estructura
Los WordPress Coding Standards definen nombres, espaciado, documentación y convenciones de PHP. Se pueden hacer cumplir con PHP_CodeSniffer en integración continua, así que "seguimos los estándares" pasa a ser una afirmación que puedes comprobar. Un plugin bien estructurado tiene un archivo principal con cabecera, una carpeta includes para las clases, funciones con prefijo o namespaces para evitar colisiones, un text domain para la traducción y una rutina de desinstalación.
Nonces, capacidades y sanitización
Un nonce demuestra que la petición viene de un formulario que renderizó tu sitio. Una comprobación de capacidades demuestra que el usuario puede ejecutar la acción. La sanitización limpia la entrada antes de guardarla. Ni el nonce ni la comprobación de capacidades sustituyen al otro. El ejemplo guarda un ajuste mediante admin-post.php.
<?php
/**
* Plugin Name: Acme Quote Settings
* Description: Saves a default quote note from an admin form.
* Version: 1.0.0
* Text Domain: acme-quote
*/
defined( 'ABSPATH' ) || exit;
/**
* Registra la página de ajustes.
*/
function acme_quote_register_menu() {
add_options_page(
__( 'Quote settings', 'acme-quote' ),
__( 'Quote settings', 'acme-quote' ),
'manage_options',
'acme-quote',
'acme_quote_render_page'
);
}
add_action( 'admin_menu', 'acme_quote_register_menu' );
/**
* Renderiza el formulario. El campo nonce se envía junto con los datos.
*/
function acme_quote_render_page() {
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
$note = get_option( 'acme_quote_note', '' );
?>
<div class="wrap">
<h1><?php echo esc_html__( 'Quote settings', 'acme-quote' ); ?></h1>
<?php if ( isset( $_GET['saved'] ) ) : ?>
<div class="notice notice-success"><p><?php echo esc_html__( 'Saved.', 'acme-quote' ); ?></p></div>
<?php endif; ?>
<form method="post" action="<?php echo esc_url( admin_url( 'admin-post.php' ) ); ?>">
<input type="hidden" name="action" value="acme_quote_save">
<?php wp_nonce_field( 'acme_quote_save', 'acme_quote_nonce' ); ?>
<input type="text" name="acme_quote_note" class="regular-text" value="<?php echo esc_attr( $note ); ?>">
<?php submit_button( __( 'Save note', 'acme-quote' ) ); ?>
</form>
<p><?php echo esc_html( $note ); ?></p>
</div>
<?php
}
/**
* Gestiona el POST: nonce, capacidad, sanitizar, guardar, redirigir.
*/
function acme_quote_handle_save() {
check_admin_referer( 'acme_quote_save', 'acme_quote_nonce' );
if ( ! current_user_can( 'manage_options' ) ) {
wp_die( esc_html__( 'You are not allowed to do this.', 'acme-quote' ), '', array( 'response' => 403 ) );
}
$note = isset( $_POST['acme_quote_note'] )
? sanitize_text_field( wp_unslash( $_POST['acme_quote_note'] ) )
: '';
update_option( 'acme_quote_note', $note );
wp_safe_redirect( admin_url( 'options-general.php?page=acme-quote&saved=1' ) );
exit;
}
add_action( 'admin_post_acme_quote_save', 'acme_quote_handle_save' );Léelo de arriba abajo. check_admin_referer verifica el nonce y detiene la petición si falla. current_user_can comprueba el permiso. wp_unslash y sanitize_text_field limpian la entrada, update_option escribe mediante la API de WordPress y wp_safe_redirect devuelve al usuario a la página. El orden es lo importante: un fallo en cualquier paso termina la petición antes de que cambien los datos.
Ruta de la solicitud del formulario
- 01POST del navegadorEl formulario se envía al servidor
- 02admin-post.phpDirige al controlador del plugin
- 03Verificación del noncecheck_admin_referer valida el token
- ALas verificaciones pasanLa solicitud continúa
- Verificación de permisoscurrent_user_can confirma el permiso
- Sanear y guardarLimpiar datos, update_option, redirigir
- BFalla alguna verificaciónLa solicitud termina, datos intactos
- Bloqueo 403wp_die finaliza la solicitud
Ciclo de un formulario de plugin: nonce, permisos, sanitización, guardado y redirección; los fallos terminan en un 403
Tres controles, en orden
Toda petición que cambia datos necesita una comprobación de nonce, una comprobación de capacidades y sanitización, en ese orden. Toda salida necesita escapado. Si una propuesta no los menciona, pregunta.
Escapado de salida y acceso seguro a la base de datos
Sanitiza al entrar, escapa al salir. esc_html, esc_attr, esc_url y wp_kses_post sirven cada uno para un contexto, y usar el equivocado es un bug. Para consultas personalizadas, usa $wpdb->prepare con marcadores de posición, y prefiere WP_Query y las APIs de opciones y metadatos cuando encajen.
Para las rutas REST, register_rest_route necesita un permission_callback real. Nunca uses __return_true en una ruta que cambia datos.
Mantenimiento y compatibilidad con las actualizaciones de WordPress
El lanzamiento es el día más barato en la vida de un plugin. El costo a largo plazo es mantenerlo compatible mientras se mueven WordPress, PHP, WooCommerce y cada dependencia. La mayoría de los compradores lo pasa por alto, y es la razón por la que operamos sitios WordPress a largo plazo, como describimos en nuestra página de la plataforma WordPress.
Qué se rompe tras una actualización de WordPress o PHP
El core trabaja mucho para mantener la compatibilidad hacia atrás, pero las deprecaciones se acumulan. El código que ignora los avisos de deprecación falla más tarde. Las víctimas habituales:
- Funciones y hooks que el core depreca y acaba eliminando.
- Cambios de versión de PHP que endurecen el comportamiento o eliminan funciones.
- Cambios de WooCommerce en plantillas, almacenamiento de datos o checkout.
- Cambios en el editor de bloques y en la REST API que afectan a bloques y endpoints a medida.
- APIs de terceros que retiran una versión o cambian la autenticación.
Pruebas, staging y disciplina de lanzamiento
Las pruebas automáticas (PHPUnit para la lógica, pruebas end-to-end para los flujos críticos) se ejecutan en cada cambio. Un sitio de staging replica producción y las actualizaciones aterrizan primero allí. Los lanzamientos llevan una versión semántica, un changelog y una vía de vuelta atrás. Un equipo cuidadoso también ejecuta el plugin contra la siguiente beta de WordPress antes de publicarlo, para que los problemas aparezcan cuando aún es barato corregirlos.
Quién es dueño del código y del repositorio
Pon la propiedad en el contrato: el repositorio en la cuenta de tu organización con todo el historial, los términos de licencia, la documentación y cualquier credencial. Evita plugins que dependan de una librería privada a la que solo accede el desarrollador. Si el desarrollador desaparece, otro desarrollador competente debe poder continuar el lunes.
Un plan Care mensual convierte las pruebas de actualización en rutina en lugar de emergencia.
Cómo evaluar a un desarrollador de plugins a medida
Un buen desarrollador de plugins a medida te vende un proceso y evidencia, no solo un presupuesto. Las propuestas se parecen en la superficie. Las diferencias aparecen en lo que está escrito sobre seguridad, pruebas y propiedad.
Preguntas antes de firmar
Convierte los puntos siguientes en preguntas para una llamada. Cómo responde un desarrollador te dice más que lo que responde.
- Pide ver código de un plugin anterior y lee cómo trata la entrada y la salida
- Comprueba que el desarrollador sigue los WordPress Coding Standards y los ejecuta en CI
- Pregunta cómo se prueban las actualizaciones de WordPress, PHP y WooCommerce antes de cada lanzamiento
- Exige que el repositorio Git sea tuyo, con todo su historial
- Confirma staging, lanzamientos versionados y una vía de vuelta atrás
- Pregunta quién mantiene el plugin después del lanzamiento y en qué condiciones
- Solicita un alcance escrito con exclusiones explícitas
- Pregunta cómo se reporta y se corrige un problema de seguridad hallado más tarde
Empieza por la muestra de código. Un desarrollador que ha entregado plugins para otras organizaciones suele poder mostrar un ejemplo sanitizado o explicar cómo se estructuró uno anterior. Quien no puede mostrar código, o no sabe decir qué haría distinto, te vende horas en lugar de criterio.
Señales de alerta en las propuestas
Estos patrones suelen anticipar problemas:
- Un precio cerrado sin etapa de descubrimiento.
- Ninguna mención de revisión de seguridad, pruebas o staging.
- Código entregado como un zip sin repositorio.
- Ediciones en el core de WordPress o en archivos de plugins de terceros en lugar de usar hooks.
- La promesa de que el plugin no necesitará mantenimiento.
Ninguna prueba mala fe. Cada una es un motivo para hacer una pregunta más antes de comprometerte.
Cómo es un buen traspaso
Un buen traspaso incluye el repositorio con su historial, un README que cubra instalación, configuración y despliegue, documentación de los hooks y filters que expone el plugin, un changelog, instrucciones de pruebas y una sesión de recorrido. La prueba es simple: ¿podría otro desarrollador tomar el relevo sin llamar al primero?
Por dónde empezar
Escribe un planteamiento del problema de una página: qué pasa hoy, qué debería pasar, quién participa y qué sistemas se tocan. Después lista tus plugins activos y marca los que usas para una fracción de sus funciones y los que rodeas con apaños. Esa página y esa lista son la mayor parte del descubrimiento.
Con ambas en mano, escríbenos para una opinión técnica sobre si necesitas un desarrollo. Nuestra página de servicios de desarrollo de plugins WordPress a medida explica cómo definimos el alcance y ejecutamos uno. Si prefieres el detalle del servicio en español, consulta la página de desarrollo de plugins WordPress. Cuando el plugin esté en producción, el plan Care mensual cubre las actualizaciones y las comprobaciones de compatibilidad.
Preguntas frecuentes
¿Cuánto cuesta el desarrollo de un plugin WordPress a medida?
Depende del alcance, del número de roles de usuario, de las integraciones, del volumen de datos, de la revisión de seguridad y de la documentación, no de las líneas de código. Un conjunto de bloques es un proyecto pequeño y una sincronización bidireccional con un ERP es uno grande. Un desarrollador serio da un rango solo después de una etapa de descubrimiento y con un alcance escrito.
¿Cuánto tarda en desarrollarse un plugin WordPress a medida?
Un plugin acotado, como un conjunto de bloques o un custom post type, es un proyecto corto. Las integraciones con sistemas de terceros llevan más tiempo. Los mayores retrasos suelen venir de esperar accesos a la API o decisiones, no de escribir código, así que un plazo realista sale del descubrimiento.
¿Cuándo conviene un plugin a medida en vez de comprar uno?
Construye cuando la lógica es específica de tu negocio, cuando necesitas varios plugins para imitar un solo flujo o cuando debes conectar un sistema sin plugin mantenido. Compra cuando la necesidad es común y un plugin mantenido encaja con tu proceso sin cambios.
¿Es un plugin de WordPress a medida más seguro que uno gratuito?
No automáticamente. La seguridad depende de la práctica: nonces, comprobaciones de capacidades, sanitización, escapado, revisión y actualizaciones. Un plugin a medida no carga funciones sin usar, pero lo inspeccionan menos personas, así que necesita revisión y mantenimiento deliberados.
¿Se romperá un plugin a medida cuando WordPress se actualice?
Puede pasar si nadie lo mantiene, porque WordPress, PHP y WooCommerce deprecan funciones con el tiempo. Con pruebas automáticas, un sitio de staging y comprobaciones de compatibilidad antes de cada lanzamiento, las actualizaciones pasan a ser rutina en lugar de emergencia.
¿Quién es dueño del código de un plugin WordPress a medida?
Lo decide tu contrato, no un valor por defecto. Especifica que el repositorio, la licencia y la documentación se te entregan, y haz que un abogado revise la cláusula. Sin ella, quizá no puedas cambiar de desarrollador más adelante.
