Servicio
Tienda en línea en Laravel
La tienda creció y la plataforma no le sigue el ritmo. Los precios mayoristas se calculan a mano, las existencias no cuadran y cada cambio cuesta una semana y el riesgo de romper lo vecino. Tienda desde $1900 y 5–12 semanas.
Qué incluye
Laravel — cuándo se justifica y qué hacemos con él
Cuándo hace falta Laravel y cuándo no
- Laravel se justifica cuando la lógica de la tienda se sale de lo estándar. El precio depende del cliente, del volumen y de la moneda. Las existencias viven a la vez en tres almacenes y en un marketplace. El mayorista entra en su área y ve su propia lista de precios, su aplazamiento y su historial de envíos. Una solución estándar aquí, o se reescribe con plugins hasta que actualizarla se vuelve un riesgo, o choca contra un techo en el primer requisito no estándar.
- Y al revés. Si tiene 200 productos, un precio, un envío y ganas de vender, se lo diremos claro en el brief y le propondremos una plataforma ya hecha. Saldrá más rápido y más barato, y el dinero ahorrado irá a tráfico. Hacemos tiendas en línea en WooCommerce y no lo consideramos un compromiso: es simplemente otra clase de tarea.
- El motivo más habitual con el que llegan buscando Laravel no es «queremos un framework», sino «el sistema actual no deja hacer lo que el negocio necesita». Es un punto de partida razonable. Entonces la conversación no empieza por la tecnología, sino por la lista de lo que ahora se hace a mano.
La lógica por la que se escribe esto
- Precios que no caben en la configuración de una plataforma estándar: listas de precios por cliente, descuentos por volumen, condiciones personalizadas, varias monedas con tipo de cambio, precio por unidad de medida, mecánicas promocionales con límites. Las reglas se definen en el panel, no en el código.
- Varios almacenes y reservas: las existencias se ven por almacén, la reserva se mantiene para el pedido y el producto se toma del almacén más cercano al comprador. Vender lo que no hay deja de ser una historia diaria.
- Área B2B: precio propio, límite de crédito, aplazamiento, repetir pedido en un clic, factura y documentos de cierre, historial de envíos. Si hay muchas áreas y con sus propios roles, por volumen eso ya se acerca a una aplicación web; se lo diremos antes de firmar, y no a mitad del trabajo.
- Catálogo grande y filtros: un subsistema de búsqueda aparte (Meilisearch o Elasticsearch) en lugar de la búsqueda SQL, tolerancia a erratas en la consulta, filtros por facetas según características. Cómo se ve esto en el caso más pesado está en la página de la tienda de recambios.
- Procesos en segundo plano: colas para importar listas de precios, recalcular precios y enviar documentos y correos. Una lista grande se importa en segundo plano: el sitio no se cae y el gestor no se queda mirando la pantalla.
Integraciones
- 1C y BAS: intercambio bidireccional de artículos, precios, existencias y pedidos. El formato lo acordamos con su especialista del sistema contable antes de empezar el desarrollo, porque es la causa más frecuente de desvío en los plazos.
- Pago: LiqPay y Fondy, tarjetas, Apple Pay y Google Pay, pago a plazos, transferencia bancaria para empresas con factura desde el sitio.
- Nova Poshta: cálculo del coste, elección de oficina o buzón en el mapa, creación de albaranes desde el panel, seguimiento en el área del comprador.
- Marketplaces y feeds: exportación a Rozetka, Prom, Google Merchant Center y Meta, con reglas propias de precios y existencias por canal.
- CRM y avisos: envío de pedidos a su CRM o a Apros CRM, el lead y el estado del pedido en Telegram, correos al cliente y al gestor.
El código y los accesos le pertenecen
- Laravel estándar en la última versión mayor estable, sin un framework propio encima del framework. Estructura de carpetas, nomenclatura, Eloquent, colas, eventos: tal como está escrito en la documentación oficial. Cualquier desarrollador de Laravel abre el proyecto y se orienta sin nuestra ayuda.
- El esquema de la base, solo con migraciones y en el repositorio. Nada de cambios de tablas a mano en el servidor de producción que después no se puedan repetir.
- El repositorio es suyo desde el primer día y nosotros somos participantes en él. Los accesos al servidor, al dominio, a las pasarelas de pago y a la analítica están a nombre de su empresa. El alojamiento lo elige usted, no hay dependencia del nuestro.
- En la entrega: un README con el despliegue, la descripción de las variables de entorno, el esquema de integraciones y los formatos de intercambio, y un manual para el gestor de contenidos. Además, una llamada con su desarrollador, si lo tiene, o con quien contrate después.
- Pruebas en las rutas críticas: carrito, pedido, cálculo del precio e intercambio con 1C. El porcentaje de cobertura no nos interesa. Nos interesa otra cosa: que la siguiente persona cambie el código y vea que no ha roto nada.
Cómo trabajamos
De la lista de requisitos a una tienda funcionando
Brief técnico
Una hora de conversación con su desarrollador o su director técnico. Qué hay ya, cuántos SKU, de dónde salen los precios y las existencias, qué versión del sistema contable, qué roles hay en las áreas, cómo están el tráfico y las URL actuales. Al final: especificaciones con la arquitectura, la lista de integraciones, el reparto por etapas y una horquilla de plazo y presupuesto.
Arquitectura y maquetas
Modelo de datos, esquema de intercambio con 1C y con las pasarelas de pago, escenarios del área B2B. En paralelo: maquetas del catálogo, la ficha, el carrito y el área de cliente. Al final: arquitectura aprobada, maquetas de escritorio y móvil y precio cerrado para el alcance acordado.
Desarrollo por sprints
El staging se levanta la primera semana y a partir de ahí ve el trabajo cada semana, no el día de la entrega. Primero el núcleo: catálogo, precios, carrito, pedido. Después las áreas y las integraciones. Al final de cada sprint: una versión en staging que se puede clicar.
Datos, pruebas, entrega
Traslado del catálogo y de la base de clientes, redirecciones desde las direcciones antiguas, transacciones reales, prueba de carga del catálogo e intercambio con 1C con datos reales. Al final: la tienda en producción, el repositorio y los accesos en su poder, documentación, formación del gestor y 30 días de soporte. Después, según acuerdo: soporte periódico o su propio equipo.
Preguntas frecuentes
Desarrollo en Laravel — respuestas honestas
Hablemos
Diga la plataforma, los SKU y las integraciones — lo calculamos por etapas
En detalle
Una tienda en línea en Laravel — qué significa en la práctica
Laravel es un framework de PHP, no una tienda ya hecha. La diferencia es de fondo. Una plataforma estándar da un conjunto de ajustes en los que hay que encajar. Un framework da una herramienta con la que usted describe su propia lógica de venta. Por eso el desarrollo de una tienda en línea en Laravel no empieza por elegir una plantilla de diseño, sino por el modelo de datos: qué es un producto en su contabilidad, de dónde sale el precio, cómo viven las existencias, quién es el comprador y en qué se diferencia el mayorista del minorista. Todo lo demás es consecuencia de esas respuestas.
La palabra «a medida» asusta a los propietarios con razón: detrás suele esconderse código que nadie salvo el autor entiende. Ese riesgo lo quitamos con mecánica, no con promesas. Estructura estándar de Laravel sin añadidos, esquema de la base con migraciones, pruebas en el carrito, en el cálculo del precio y en el intercambio con la contabilidad, README con el despliegue, y repositorio y accesos a nombre de su empresa. Su desarrollador puede mirar el proyecto antes de firmar el contrato. Compruébenos justo así.
El intercambio con el sistema contable es donde estos proyectos se atascan más a menudo. 1C o BAS está configurado a su manera en cada empresa, y el «intercambio estándar» solo existe en las presentaciones. Fijamos el formato en la fase de especificaciones junto con su especialista del sistema contable: qué campos, con qué frecuencia, qué es la fuente de verdad para el precio y la existencia, qué hacer con los conflictos. A partir de ahí ya es una tarea de ingeniería con un plazo previsible. El resto de integraciones de la tienda, pago, envío, marketplaces y CRM, están descritas en la página del servicio. Tiendas en línea llave en mano →
Aparte, sobre la mudanza. Una tienda que ya tiene tráfico no se puede relanzar sin más con código nuevo: la estructura de direcciones, el marcado, la velocidad y el mapa de redirecciones influyen en las posiciones tanto como el propio desarrollo. Por eso en cada proyecto de migración incluimos redirecciones página a página, traslado de metadatos y revisión de la indexación tras el lanzamiento. Encargar un sitio en Laravel y perder la mitad del orgánico al arrancar es un escenario totalmente real si no se trabaja con antelación.
Laravel no va solo de tiendas. Con él se hace también la parte interna que el comprador no suele ver: áreas de distribuidores, paneles para gestores, gestión de solicitudes, informes, generación de documentos. A menudo todo empieza por el catálogo y, medio año después, resulta que la parte más valiosa del sistema es aquella en la que trabaja el departamento de ventas. Desarrollo de sitios web →
Una tienda en línea en Laravel tiene sentido cuando su lógica de venta vale más que el ahorro en una plataforma estándar. En los demás casos, no lo tiene. Cuál de esos dos casos es el suyo se lo diremos en la primera conversación, aunque la respuesta no nos favorezca. Describa la plataforma actual, el número de SKU y las integraciones, y volvemos con una estimación por etapas. Pedir presupuesto →