M-03 / software_engineering.ts

// CLASSIFICATION
print-preflight, not ai art. leverage: 8/10

// STACK
next.js — fast intake, upload, and status UI. one trap: people will try to turn it into a design tool and wreck the scope.
python + pydantic — hard validation for file specs, sizes, and metadata. one trap: fuzzy ai outputs sneak in where strict rules should live.
libreoffice + imagemagick — boring file conversion and raster checks nobody wants to build twice. one trap: font chaos and missing assets will bite hard.
qpdf + ghostscript — pdf inspection, bleed checks, and page-level fixes. one trap: postscript weirdness is ugly and expensive.
s3 + queuing — store files, retry jobs, keep the pipeline from dying on one bad upload. one trap: ignoring queues turns the app into a timeout machine.

// HARD PROBLEMS
1. print-readiness is not one problem; it is ten rules across dpi, trim, bleed, color space, fonts, and page box logic, and each rule has edge cases that will eat the schedule.
2. ai cannot safely “fix” bad print files without making them worse, so the core product is deterministic preflight plus guided repair, not generative nonsense.
3. every printer has slightly different standards, and normalization across pdf, png, jpg, and psd workflows will become a support swamp fast.

// 6-WEEK CUT
ship a file intake page, instant preflight report, and a red/yellow/green pass-fail status for the four failures customers actually hit: low resolution, wrong dimensions, no bleed, and unsafe fonts.
ship one-click auto-fix for the dumb stuff: convert to pdf, pad bleed, resize canvases, and flatten transparency where safe.
ship a human review queue for anything ambiguous so staff can approve or reject in under a minute.
what to delete: text-to-image generation, prompt chat, brand brainstorming, multi-user collaboration, and any claim that the model “makes designs print-ready.”

// THE QUESTION WE'D ASK FIRST
*who is the buyer: the print shop drowning in bad uploads, or the customer who needs a clearer upload gate?*