Desarrollo web con Laravel para tiendas donde cada cliente tiene su propio precio

Cuándo compensa Laravel

Todo lo decide una operación que la plataforma ya hecha resuelve mal. Por ejemplo, el distribuidor hace un pedido con su tarifa y el gestor lo aprueba. Describimos esa operación desde el primer clic hasta el registro en la contabilidad, contamos las excepciones y comparamos ampliar un módulo de la plataforma con escribir código propio. Justificamos la elección con esa operación, porque las frases generales sobre flexibilidad no demuestran nada.

Si tienes unos cientos de productos y un único precio para todos, no necesitas Laravel. Una tienda así sale más barata en WooCommerce u OpenCart.

Cuánto cuesta el desarrollo con Laravel

Una tienda con Laravel cuesta desde 10.000 €. Es el precio de un proyecto con portal B2B o lógica a medida, como precios por cliente o aprobación de pedidos. El importe concreto depende del número de roles, de las reglas de descuento, del tamaño del catálogo y de los sistemas con los que hay que intercambiar datos.

La cifra exacta la damos en el presupuesto, tras el brief técnico. La carga del catálogo y la migración desde la tienda antigua se presupuestan aparte, igual que en otras plataformas. Una estimación aproximada te la da la calculadora.

Roles y portales

Cliente, distribuidor, gestor y administrador ven precios, documentos y acciones distintos. Por eso empezamos con una tabla de accesos donde se ve quién crea, aprueba, edita y cancela pedidos. De ella salen tanto las pantallas de los portales como las pruebas.

La tabla también recoge las prohibiciones. El distribuidor no ve documentos ajenos, el gestor no puede cambiar a escondidas un precio aprobado y una cuenta bloqueada no puede hacer pedidos. Probamos estas prohibiciones junto con los escenarios principales. Cada cambio de permisos que afecta a dinero, documentos o datos personales queda en un registro.

La primera versión cubre un ciclo de trabajo

Crear un sitio con Laravel con todas las funciones a la vez retrasa el lanzamiento. Por eso, para la primera versión dejamos un escenario completo y los datos de referencia que necesita. En ese escenario, el distribuidor entra, ve su precio y hace el pedido, el gestor lo aprueba y los datos confirmados pasan al sistema de gestión. La analítica, las bonificaciones complejas y los roles nuevos esperan a las siguientes versiones.

Al principio, a otros roles puede bastarles un proceso manual, si no frena a nadie. Dejamos constancia de esa decisión para que lo temporal no se vuelva permanente. Un margen «para el futuro» en el código no sustituye a las funciones que el equipo usará el día del lanzamiento.

Integración con la contabilidad y el CRM

Para el sistema de gestión, el CRM o el almacén acordamos los métodos de la API, los campos, la dirección del intercambio, la autorización, la frecuencia y los reintentos. El acceso de prueba y la documentación hacen falta antes del presupuesto final, porque sin ellos no se sabe si el sistema dará los datos necesarios.

Cada integración incluye ejemplos de peticiones y respuestas, una tabla de estados de ambos sistemas y el nombre del responsable de cada lado. Así, si el sistema externo cambia su API, enseguida se ve dónde buscar el fallo. Para cada error decidimos si la petición se puede repetir sin duplicar el pedido y a quién le llega el aviso. El intercambio entre varios sistemas fuera de la tienda lo presupuestamos como una automatización de procesos aparte.

Los datos, separados de las pantallas

Describimos el catálogo, los precios, los pedidos y los documentos sin depender de pantallas concretas. Así se puede rehacer un portal o añadir un nuevo canal de venta sin copiar las reglas en varios sitios. Para los registros principales guardamos identificadores estables y el historial de cambios. Esto importa cuando un precio llega del ERP, otro depende del contrato y un pedido pasa por varias aprobaciones.

Los esquemas de datos y la descripción de la API se entregan con el código, en el alcance acordado. Una interfaz nueva se conectará a las mismas reglas, pero cada paso así lo presupuestamos por separado. No prometemos un escalado ilimitado.

El código y el entorno pasan a tus manos

Recibes el repositorio con el código, la configuración de los entornos, las migraciones de la base de datos, los registros, las copias de seguridad y el método de despliegue. Las contraseñas, las claves y demás secretos se guardan fuera del repositorio. Las cuentas y licencias de terceros se entregan por un canal seguro. La documentación que se incluye queda escrita en la propuesta.

Comprobamos la entrega con una instalación limpia siguiendo las instrucciones, igual que desplegaría el proyecto otro equipo. Si el servidor lo mantiene tu gente, acordamos el límite de responsabilidades antes del lanzamiento.

Tras el lanzamiento, medimos el trabajo manual

Vigilamos los errores de intercambio, el tiempo de aprobación, la proporción de correcciones manuales y las preguntas que los gestores repiten una y otra vez. Estas cifras indican qué escenario automatizar después, aunque por sí solas no garantizan ahorro. Las ventas dependen también del surtido y de los precios, así que no atribuimos el resultado del negocio al framework. Para cada nueva versión anotamos una hipótesis, un criterio de aceptación y un presupuesto. Las actualizaciones, las copias de seguridad y los pequeños cambios tras el lanzamiento puedes encargarlos a nuestro soporte.

Cómo encargar un sitio con Laravel

Para el presupuesto, describe los roles y lo que ve cada uno, las reglas de precios y descuentos, tu sistema de gestión y el acceso a su documentación. Añade en qué funciona hoy la tienda y qué debe funcionar el día del lanzamiento. Con eso preparamos el brief técnico y después el presupuesto. El brief te ayudará a detallarlo todo. Si prefieres contarlo en una llamada, deja tu contacto en el formulario de arriba.

Un portal o un sistema interno con Laravel sin tienda ya entra en las aplicaciones web.