Saltar al contenido
Caso · 08 / 09← Todos los trabajos

Copiados Norte

Landing, backoffice y app de pedidos para una copiadora y gestoría de trámites en Villa Gesell.

Rol
Único desarrollador: landing, backoffice, app cliente y núcleo compartido
Stack
Next.js 16, React 19, TypeScript, Tailwind CSS 4, Recharts, Expo
Landing
LandingUn paquete core para precios, tipos y máquinas de estado
(01) El problema

El local hace copias, trámites de ANSES y AFIP, pagos de impuestos y librería. Pedidos, turnos, stock, impresoras y caja necesitan seguimiento. El cliente tiene que poder pedir y cotizar sin llamar. El dueño necesita números que el mostrador no tiene que ver.

Mi rolConstruí las tres apps a partir de prototipos hi-fi, junto con el paquete compartido que usan.
(02) ResultadosContados en el código
3apps en un mismo dominio: landing, backoffice y app cliente
12vistas en el backoffice, tres solo para el dueño
5pestañas en la app cliente
(03) Arquitectura

Tres decisiones que lo definieron.

  1. 01

    Un paquete core para precios, tipos y máquinas de estado

    Por qué. El cotizador de la landing, el POS del mostrador y la app leen la misma tabla de precios. Un pedido sigue el mismo flujo en todos lados.

    El costo. Compartir código no es compartir datos. Sin backend, la app tiene su propia copia del seed y sus pedidos no llegan al backoffice.

  2. 02

    Un único reducer, guardado en una clave versionada de localStorage

    Por qué. Toda acción del backoffice pasa por un reducer, así que sumar una base solo cambia el origen de los datos. Lo guardado se lee después de montar para no romper la hidratación.

    El costo. Cada navegador tiene sus propios datos. Subir la versión de la clave descarta lo guardado antes.

  3. 03

    El reporte mensual es HTML imprimible, no una librería de PDF

    Por qué. Tres hojas A4 con @page conservan las tipografías de marca, el texto vectorial y las tramas que hacen legibles los gráficos en blanco y negro.

    El costo. El PDF sale del diálogo de impresión. El dueño tiene que elegir "Guardar como PDF" y el resultado puede variar según el navegador.

(04) GaleríaSeguí scrolleando →
Landing
Landing · Servicios, pedido online en tres pasos y un cotizador que lee la tabla de precios compartida.
Mi negocio
Mi negocio · La vista de entrada del dueño. Barras de Recharts con un tooltip propio en los tokens de la marca.
Cola de pedidos
Cola de pedidos · Un botón lleva cada pedido a su siguiente estado. Al marcarlo listo, queda registrado el aviso al cliente.
App cliente
App cliente · Hecha con Expo, exportada a web y servida en /app desde el mismo deploy.
(05) Qué haría después
01Sumar backend y base de datos para que los pedidos de la app lleguen al backoffice, y pasar el login al servidor.
02Agregar un endpoint de subida. Hoy el flujo de pedido solo manda el nombre del archivo por WhatsApp.
03Oscurecer los cinco pares de colores que no llegan al contraste AA de WCAG, ya listados en el README.
Próximo proyecto · 09 / 09
Trading analytics dashboard →Heatmaps, gráficos y tablas en vivo para traders
Caso · 08 / 09

Copiados Norte

Landing, backoffice y app de pedidos para una copiadora y gestoría de trámites en Villa Gesell.

Rol
Único desarrollador: landing, backoffice, app cliente y núcleo compartido
Stack
Next.js 16, React 19, TypeScript, Tailwind CSS 4, Recharts, Expo
Copiados Norte
(01) El problema

El local hace copias, trámites de ANSES y AFIP, pagos de impuestos y librería. Pedidos, turnos, stock, impresoras y caja necesitan seguimiento. El cliente tiene que poder pedir y cotizar sin llamar. El dueño necesita números que el mostrador no tiene que ver.

Mi rolConstruí las tres apps a partir de prototipos hi-fi, junto con el paquete compartido que usan.
(02) Resultados
3apps en un mismo dominio: landing, backoffice y app cliente
12vistas en el backoffice, tres solo para el dueño
5pestañas en la app cliente
(03) Arquitectura

Tres decisiones que lo definieron.

01

Un paquete core para precios, tipos y máquinas de estado

Por qué. El cotizador de la landing, el POS del mostrador y la app leen la misma tabla de precios. Un pedido sigue el mismo flujo en todos lados.

El costo. Compartir código no es compartir datos. Sin backend, la app tiene su propia copia del seed y sus pedidos no llegan al backoffice.

02

Un único reducer, guardado en una clave versionada de localStorage

Por qué. Toda acción del backoffice pasa por un reducer, así que sumar una base solo cambia el origen de los datos. Lo guardado se lee después de montar para no romper la hidratación.

El costo. Cada navegador tiene sus propios datos. Subir la versión de la clave descarta lo guardado antes.

03

El reporte mensual es HTML imprimible, no una librería de PDF

Por qué. Tres hojas A4 con @page conservan las tipografías de marca, el texto vectorial y las tramas que hacen legibles los gráficos en blanco y negro.

El costo. El PDF sale del diálogo de impresión. El dueño tiene que elegir "Guardar como PDF" y el resultado puede variar según el navegador.

(04) Galería
Landing
Landing · Servicios, pedido online en tres pasos y un cotizador que lee la tabla de precios compartida.
Mi negocio
Mi negocio · La vista de entrada del dueño. Barras de Recharts con un tooltip propio en los tokens de la marca.
Cola de pedidos
Cola de pedidos · Un botón lleva cada pedido a su siguiente estado. Al marcarlo listo, queda registrado el aviso al cliente.
App cliente
App cliente · Hecha con Expo, exportada a web y servida en /app desde el mismo deploy.
(05) Qué haría después
01Sumar backend y base de datos para que los pedidos de la app lleguen al backoffice, y pasar el login al servidor.
02Agregar un endpoint de subida. Hoy el flujo de pedido solo manda el nombre del archivo por WhatsApp.
03Oscurecer los cinco pares de colores que no llegan al contraste AA de WCAG, ya listados en el README.
Próximo proyectoTrading analytics dashboard →
Nahuel SantillánES