Qué incluye un proyecto de software a la medida
Definimos el trabajo según el brief real. La propuesta identifica entregables incluidos, quién aporta los materiales y cómo se acepta cada uno.
- Alcance de la primera versión: flujo principal, roles y lo que espera
- Pantallas clave con estados vacíos, de carga y de error
- Modelo de datos, reglas de acceso en el servidor y pruebas que intentan romperlas
- Cuentas, roles e invitaciones de equipo
- Pagos o suscripciones confirmados con notificaciones verificadas del proveedor
- Panel de administración, eventos de analítica y monitoreo de errores
- Despliegue, documentación y entrega del repositorio y las cuentas
¿Software a la medida, sitio web o diseño de producto primero?
Elige este servicio cuando clientes o empleados necesitan iniciar sesión y completar trabajo dentro del producto: comprar, reservar, enviar, aprobar o administrar algo. Si necesitas un sitio que explique y venda tu oferta, Desarrollo web encaja mejor. Si el flujo todavía no está definido, empieza por Diseño de producto y desarrolla cuando las pantallas clave se hayan probado con usuarios.
Cómo se construye la primera versión
Empezamos con una fase de alcance: usuarios y roles, el flujo que la primera versión debe completar, los datos que crea cada paso y las decisiones que cambian el costo, como pagos, integraciones y permisos. El resultado es un alcance escrito, pantallas clave navegables y un plan de lanzamiento que nombra lo que se aplaza.
Luego desarrollamos en ciclos cortos sobre un entorno de pruebas que puedes usar. El primer hito es una porción delgada del flujo principal funcionando de punta a punta, con inicio de sesión y reglas de datos reales, antes de completar las demás pantallas. El lanzamiento incluye monitoreo en producción, un plan para revertir cambios y la entrega a tu nombre del repositorio, alojamiento, base de datos y cuentas de pagos y analítica.
¿Qué debe incluir la primera versión de un MVP?
Una primera versión necesita lo que hace falta para que un usuario real complete un flujo, y nada que solo importe a una escala que todavía no tienes. En la práctica son cinco piezas: cuentas con los roles que el flujo exige, el flujo principal, un panel de administración para que tu equipo vea y corrija registros sin un desarrollador, pagos si el modelo de negocio cobra desde el primer día y eventos de analítica que muestren dónde se detienen los usuarios.
Lo que se puede hacer a mano o comprar después, espera: app nativa, inicio de sesión único para clientes corporativos, matriz de permisos configurable, una segunda integración, chat dentro de la app y reportes que nadie ha pedido. Cada pieza aplazada queda escrita en el alcance para que el modelo de datos le deje espacio.
Casi todo producto se arma con módulos conocidos. Dos merecen mención aparte: reservas y agendamiento, y un embudo de solicitudes para una pyme que hoy lleva sus contactos a mano. Ambos parecen simples y esconden decisiones sobre zonas horarias, estados y responsables que sale más barato resolver en papel.
| Módulo | Qué necesita | Qué decidir antes |
|---|---|---|
| Cuentas y roles | Registro, acceso, recuperación y verificación de rol en cada solicitud | ¿Qué roles existen y una persona puede pertenecer a varias organizaciones? |
| Invitaciones de equipo | Enlaces que vencen, cupos, traspaso de propiedad, retiro que corta el acceso al instante | ¿Quién puede invitar y qué pasa con los registros de quien sale? |
| Cobros y planes | Checkout alojado o suscripciones, notificaciones verificadas, límites del plan aplicados en el servidor | ¿Qué incluye cada plan y qué pasa cuando falla un pago? |
| Reservas y agendamiento | Disponibilidad, zonas horarias, tiempo entre citas, bloqueo de reservas dobles, recordatorios, reprogramación | ¿Quién define la disponibilidad y se aparta el cupo mientras el cliente paga? |
| Solicitudes y clientes potenciales | Formulario con protección contra spam, estados de nuevo a ganado o perdido, asignación, origen, autorización de datos | ¿Qué estados usa de verdad tu equipo y a dónde va cada solicitud después? |
| Administración y reportes | Búsqueda, historial de registros, correcciones manuales, exportaciones | ¿Qué cifras revisa el equipo cada semana y quién puede editar registros? |
| Dominios propios | Configuración del hostname, verificación DNS, estado del certificado, reglas por plan | ¿Qué planes incluyen dominio y qué límites tiene el proveedor? |
| Registro de auditoría | Historial que no se puede editar de quién cambió qué y cuándo | ¿Qué acciones deben poder rastrear tus clientes o auditores? |
| Notificaciones | Correo y avisos dentro de la app, plantillas, registro de envíos, preferencias | ¿Qué eventos avisan a quién y cuáles se pueden desactivar? |
¿Con qué tecnología trabaja Dardo y cuándo elige otra?
Por defecto usamos TypeScript de punta a punta: Astro para páginas renderizadas en el servidor e islas interactivas, Cloudflare Workers para alojamiento y APIs, Cloudflare D1 o Postgres para los datos y PostHog para analítica y experimentos. Superame funciona en Astro y guarda su ranking en Neon (Postgres). Un solo lenguaje y un solo destino de despliegue mantienen un producto pequeño fácil de operar y de entregar.
Elegimos otra cosa cuando el producto lo pide. Una interfaz densa que se usa abierta todo el día puede justificar una aplicación React del lado del cliente, como en el prototipo de Shiimain. Procesos largos, procesamiento pesado de datos o un equipo interno que ya usa otro framework también cambian la respuesta. Si tus desarrolladores mantendrán el código después del lanzamiento, su stack suele ganar.
El control de acceso es lo primero que probamos. El OWASP Top 10:2025 mantiene el control de acceso roto (Broken Access Control) en el primer lugar e informa que todas las aplicaciones evaluadas tenían alguna forma de esa falla. Aplicamos permisos en el servidor en cada solicitud, negamos por defecto, limitamos cada consulta a la organización de quien inició sesión y escribimos pruebas automáticas que intentan leer registros de otro cliente.
¿Cómo deben funcionar los pagos en una app web?
El proveedor de pagos confirma el pago en el servidor; el navegador que vuelve del checkout nunca lo hace. Superame, un ranking público de proyectos del trabajo publicado de Dardo, muestra el patrón. Quien compra paga en el checkout alojado de Dodo Payments, así que los datos de la tarjeta nunca llegan a la aplicación. Después el proveedor envía una notificación firmada, y el servidor verifica la firma y revisa los datos del pago antes de acreditar.
Reembolsos y disputas siguen el mismo camino. Cada evento del proveedor se aplica una sola vez, así que una notificación que llega dos veces, tarde o fuera de orden no puede sumar ni restar crédito dos veces. Superame no publica cifras de uso ni de ingresos; es evidencia de cómo está construida la lógica de pagos, no de ventas.
- Si quien compra cierra la pestaña antes de volver, igual recibe su crédito cuando llega la notificación.
- Una notificación repetida o falsificada se rechaza.
- Un reembolso o una disputa revierte exactamente lo que otorgó el pago original.
- Los límites del plan se verifican en el servidor, no solo se ocultan en la interfaz.
- Las llaves de prueba y de producción son secretos separados y nunca se guardan en el repositorio.
Permite que tus clientes usen sus propios dominios
Los clientes de un SaaS B2B suelen querer el producto en su propia dirección, como portal.suempresa.com. Cloudflare for SaaS lo resuelve con hostnames personalizados (custom hostnames): los planes Free, Pro y Business incluyen 100, cada uno adicional cuesta USD 0,10 y el máximo es 50.000. Los hostnames comodín (wildcard) son exclusivos del plan Enterprise.
Tu cliente agrega un registro CNAME que apunta a tu destino. Por defecto no se admite un registro A hacia ese destino, que es lo que necesitaría un dominio raíz, y el proxy del dominio raíz es un complemento de Enterprise, así que lo normal es usar un subdominio. Los certificados se validan por HTTP, TXT o correo, o con Delegated DCV, un registro que se crea una sola vez y permite que Cloudflare los renueve automáticamente. Los emite Let's Encrypt, Google Trust Services o SSL.com.
El trabajo de producto alrededor pesa igual: solo los planes pagos pueden conectar un dominio, una pantalla muestra el registro exacto que hay que crear, el estado de verificación explica en lenguaje claro si está pendiente o falló, y un monitoreo avisa a tu equipo cuando un certificado no puede renovarse porque el cliente cambió su DNS. Otros proveedores fijan otros límites: Vercel permite 50 dominios por proyecto en Hobby e ilimitados en Pro y Enterprise, con límites blandos de 100.000 y 1.000.000; Netlify recomienda no asignar más de 50 alias de dominio por sitio.
Preguntas antes de elegir
¿De qué depende el costo de una app web o un MVP?
Depende del número de roles, la complejidad del flujo principal, los pagos, las integraciones y cuántos datos hay que migrar. Los permisos y estados pesan más que el número de pantallas: una pantalla con cinco roles y un paso de aprobación cuesta más que cinco pantallas de solo lectura. Cotizamos un alcance escrito al cerrar la fase de alcance, no una tarifa por funcionalidad.
¿Cuánto tarda desarrollar una primera versión?
Depende de qué tan definido esté el flujo, de qué tan rápido llegan decisiones y contenido, y de si terceros como la pasarela de pagos o el área de TI de un cliente deben aprobar accesos. La propuesta fija hitos empezando por una porción funcional del flujo principal. La fecha del lanzamiento completo se fija cuando esa porción se aprueba.
¿Dardo puede continuar un desarrollo que hizo otro equipo?
Sí, después de una auditoría. Revisamos repositorio, dependencias, modelo de datos, controles de acceso, despliegue y quién controla cada cuenta, y te decimos qué puede quedarse, qué corregir primero y si conviene arreglar o reescribir. No prometemos conservar ni reemplazar un código antes de leerlo.
¿Desarrollan apps nativas para iOS y Android?
No. Dardo desarrolla para la web, incluidas apps web instalables que se abren desde un ícono en la pantalla de inicio del celular. Cuando un producto depende de funciones del dispositivo que el navegador no ofrece, de las tiendas de apps o de mucho uso sin conexión, una app nativa encaja mejor y te lo diremos. La app web y su API pueden servir de backend para un equipo nativo.
¿Quién es dueño del código y las cuentas?
Tú. Repositorio, alojamiento, base de datos, dominio y cuentas de pagos y analítica se crean a tu nombre o se transfieren en la entrega, y la propuesta lista cualquier dependencia con licencia que no se pueda transferir. Dardo conserva solo el acceso que le des para soporte.
¿Qué necesitan de nosotros?
Una persona con poder de decisión que responda preguntas de alcance en pocos días, acceso a los sistemas con los que el producto debe conectarse y ejemplos reales de los datos y documentos que usa el flujo. Abre pronto la cuenta de la pasarela de pagos a nombre de tu empresa, porque los proveedores revisan el negocio antes de habilitar pagos reales.
¿Qué pasa después del lanzamiento?
La propuesta puede incluir un periodo de soporte para errores, monitoreo y cambios pequeños mientras llegan usuarios reales. Después, el desarrollo continuo se acuerda como alcance mensual o como proyecto nuevo. Las actualizaciones de seguridad y de dependencias no son opcionales: necesitan un responsable en cualquier caso.
Fuentes y lecturas
Fuentes de esta página, con más detalles de sus publicaciones originales.
- OWASP Top 10:2025, A01 Control de acceso rototop10.owasp.org
- Cloudflare for SaaS: planes y límites de hostnames personalizadosdevelopers.cloudflare.com
- Cloudflare for SaaS: primeros pasos (destino CNAME y registros A)developers.cloudflare.com
- Cloudflare for SaaS: métodos de validación de certificadosdevelopers.cloudflare.com
- Cloudflare: autoridades de certificacióndevelopers.cloudflare.com
- Vercel: límites (dominios por proyecto)vercel.com
- Netlify: agregar un alias de dominiodocs.netlify.com
