The challenge
Team Gearflow builds the machinery and technology that promotional-products reps and distributors use to process custom decorated-apparel orders from design through delivery. I joined the project, known internally as Flow, in April 2023, roughly eight months after it began. I worked on it through November 2023 and contributed 368 of the 1,081 commits made to the main branch during that period.
The platform had to model a large, evolving domain in a 44-entity Prisma schema. At the same time, supplier integrations needed to stay separate from the core application logic, and the full system had to be reliable enough for production order management.
What we built
The multi-app monorepo contains two Remix/TypeScript applications: the internal Flow app and a customer-facing rep portal. They handle the production and order-management workflows. Two dedicated Go services keep integration complexity out of the main apps. One is a PromoStandards/OrderMyGear supplier proxy. The other, aeoon, RIPs artwork files and drives Aeoon direct-to-garment (DTG) printers on the shop floor.
The 44-entity Prisma schema models the data. The database uses LiteFS, a distributed SQLite system, on Fly.io with its primary region in dfw (Dallas Fort Worth). This keeps reads close to the deployment while avoiding the operational complexity of a traditional clustered database. CI also checks every push and pull request with Prettier, ESLint, and a full TypeScript typecheck across both Remix apps.
Key features
Multi-app monorepo
Two Remix apps, the internal Flow production tool and a customer-facing rep portal, divide the work across the order lifecycle. They share conventions and tooling in one monorepo instead of duplicating the setup across separate repositories.
Go supplier proxy
A standalone Go service handles supplier integrations over standard PromoStandards protocols and OrderMyGear. Suppliers run different generations of the same PromoStandards services, so the proxy has parallel v1 and current-generation clients for product, inventory, and media services. Each client is generated directly from a supplier’s WSDL, such as SanMar’s. This keeps version sprawl and supplier-specific quirks out of the core Remix apps.
Aeoon printer daemon
A second Go service, aeoon, turns a customer order into a physical print job. It RIPs the artwork, puts the job into a hotfolder for the shop’s RIP software, and polls until the RIP completes. It then places the output on the network drive of the assigned Aeoon DTG printer. The shop runs two printers. The service polls again until the printer consumes the file.
Distributed SQLite
LiteFS replicates SQLite across Fly.io instances (primary region dfw, Dallas Fort Worth), giving the app distributed read access without the operational overhead of a traditional clustered database.
Architecture
Frontend and app layer: Two Remix applications written in TypeScript: the internal Flow app and a customer-facing rep portal.
Supplier integration layer: A Go service proxies supplier communication independently of the Remix apps. It generates parallel v1 and current-generation PromoStandards clients for each supplier from WSDL and also integrates with OrderMyGear.
Print production layer: A second Go service, aeoon, RIPs artwork through a hotfolder handoff and moves the output to the Aeoon DTG printers’ network drives. This connects the software directly to the physical production hardware.
Data layer: Prisma models a 44-entity domain in SQLite, replicated with LiteFS.
Infrastructure: The monorepo deploys to Fly.io. LiteFS distributes SQLite across regions, with dfw (Dallas Fort Worth) as the primary region.