Print Platform

Print Platform started from a printing problem that appeared in several of my own business web applications. I previously worked mainly on desktop software, where direct access to printers was much simpler. With web applications, printing may need to be started from a phone, tablet or another computer, while the actual printer is connected to a local Windows machine.

The first concrete use case appeared in a catalogue project I was developing in parallel. I needed a quick way to print labels for products being prepared for sale, including from a mobile device. I first built a working Brother printing prototype inside a separate branch of that project. It also became clear that similar printing requirements would appear in my other business systems.

During Build Week, I therefore separated the printing capability into its own project. I did not want to build different printer handling into every application, or require users to understand Windows queue names, printer drivers or specific printer models.

With Print Platform, an application selects a business destination such as Warehouse label, rather than a printer such as Brother QL-700. The Laravel application creates and stores the print job. A browser-based Print Station running on the computer connected to the printer collects the job and routes it to the correct local printer using a previously saved configuration.

I chose QZ Tray for the local printing layer because it already supports a wide range of printers and works with the Windows printing system. This avoided the need to build a complete local printing application and separate integrations for every manufacturer during Build Week. The business logic, permissions and durable print jobs remain inside my own application. QZ Tray is only the local execution layer, so it can later be replaced or extended without redesigning the business applications.

In the demonstrated workflow, a user creates a warehouse-label print job from a mobile device. The application validates the job and its saved destination configuration. The Print Station downloads and verifies the print data, then submits it once through QZ Tray. The Windows spooler observed the job, QZ Tray accepted it, and the application recorded the submission. Automatic retry was intentionally disabled because I did not want an uncertain print result to be silently submitted a second time.

I used GPT-5.6 in ChatGPT throughout the project for research, planning and review. Most of the initial problem exploration and architecture comparison happened through the ChatGPT web and mobile applications. Several broader designs were considered, but I repeatedly reduced the scope to a smaller reusable solution that addressed the real requirement.

I started the repository-level work with Codex through the CLI. After the new Codex experience became available in the Windows ChatGPT application, I moved almost entirely to that interface. During the final part of the project, nearly all active repository work was done through the Windows application. I remained responsible for the product direction, use cases, scope decisions and every decision involving physical printing.

Print Platform is currently a working Build Week prototype, not a finished production product. Final distribution, production certificate management, support for additional operating systems and broader printer compatibility still require further work. The demonstrated Print Station runs on Windows 10 and Windows 11 x64 with QZ Tray 2.2.6.

Built With

• codex
• docker
• ffmpeg
• gpt-5.6
• javascript
• laravel
• mariadb
• php
• playwright
• qz-tray