Skip to content

~/project

Iris: Print-Shop Operations App

An operations management suite for a print shop client, built as a monorepo with a Vite React web app, Electron desktop client, and shared Go/SQLite API.

  • Go
  • SQLite
  • Docker
  • Vite
  • Electron
  • React
  • TypeScript
  • Tailwind CSS v4
  • shadcn/ui
  • React Hook Form
  • Zod
  • Recharts
  • Vitest
  • electron-builder

Role: Freelance · full-stack · Year: 2026 - Present · Status: in development

tldr: Print-shop operations across web, desktop, and API. The web client handles work orders, customers, locations, dashboards, and public tracking; the Electron app gives shop terminals a typed IPC path to the same Go backend. What I took from it: shared contracts matter more than pretending every runtime is the same product.

Iris handles role-based auth, work orders, customers, locations, public order tracking, dashboard reporting, typed desktop IPC, and Docker deployment.

Executive summary

  • Project Role: Freelance Full-Stack Developer
  • Tech Stack: Electron, React, TypeScript, Go, SQLite, Tailwind CSS, Recharts
  • Challenge: Building a cross-platform desktop application handling complex enterprise workflows, role-based access, and client-side data analytics with absolute data correctness.

The problem

Print shop terminals require high-availability desktop applications to process heavy operational work orders without server-side render delays. Creating cross-platform desktop products that integrate with legacy printing hardware while retaining sync with web dashboards is historically error-prone. The application must guarantee that state modifications, billing details, and printer commands flow reliably across process boundaries without data degradation.

Constraints

  • Data Integrity Requirements: Orders move through complex lifecycle states (from new to completed and invoiced). State-machine transitions must be verified locally and enforced via the backend API.
  • IPC Security Boundaries: Electron main and renderer processes must remain strictly decoupled to avoid exposing Node.js system calls directly to the UI layer.
  • Localization Constraints: The UI must display content for Serbian-speaking operators, meaning all status and currency calculations require localized formats (sr-Latn-RS) while keeping database schemas clean.

Technical decisions

  • Strict Typed IPC Bridge: Configured Electron’s contextBridge to expose only explicitly typed IPC endpoints, wrapping them in TypeScript contracts to eliminate runtime serialization errors.
  • React 19 + Vite 8 for Desktop Renderer: Leveraged React’s latest architecture for responsive state synchronization on the frontend, using Vite for ultra-fast incremental builds.
  • Go + SQLite Backend: Chose Go for the companion API due to its compilation speed and zero dependency footprint. Backed by SQLite for transactional reliability and trivial file-based backups.
  • Recharts for Aggregations: Performed client-side analytics aggregates (revenue, order volume, operator queues) using specialized memory buffers, avoiding expensive repeated database queries.

Trade-offs and results

  • Local Client Computations vs. Server Aggregations: Opted to fetch paginated raw work orders and perform financial aggregations client-side using pure JS utilities. This significantly reduced server CPU usage and simplified the API endpoints, at the cost of marginally higher client-side memory footprint (approx. 12MB additional runtime heap).
  • Results: Packaged and delivered Iris for macOS, Windows, and Linux via electron-builder. Frontend test suites achieved high coverage on critical login and payment actions, ensuring robust day-to-day operations.