Project-first workspace
Contracts and projects keep metadata, QA pages, notes, and output together instead of scattering the work across unrelated documents.
Flagship product case study
F.A.T.
Factory Acceptance Testing, rebuilt as a controlled workflow.
One operational product across two implementations: a completed Python desktop application and a working React web MVP built to support shared projects, tablet inspections, roles, audit history, and server-generated PDFs.
ROLEProduct design & engineering
DESKTOPPython · PyQt6 · ReportLab
WEBReact · TypeScript · Node
FOCUSQA workflow & document control
01 · The problem
QA work was being managed as paperwork, not as a system.
Factory acceptance work involves repeated forms, project-specific details, approvals, and final records. A document-only process makes consistency, recovery, and controlled output harder than they need to be.
F.A.T. turns that work into a durable project lifecycle: create the project once, assemble its QA content, complete the inspection, generate the document, and preserve what happened.
02 · The Python foundation
A desktop tool built around the real workflow.
The Python version established the product model: projects, reusable QA content, PDF generation, recoverable storage, testing, and portable Windows and Linux delivery.
Reusable QA building blocks
Structured templates turn repeat inspections into consistent pages while still allowing project-specific notes and configuration.
Controlled document output
Preview and final PDF paths keep drafts separate from deliverables and preserve printable initials and date fields for physical signoff.
Recovery and audit trail
Autosave, backups, and soft deletion protect work. Removing a project requires a name, reason, and typed signature before it is archived.
03 · System design
Clear inputs. Controlled output.
The same core workflow survives both implementations. The desktop build proved the model; the web build centralizes it for shared access and concurrent work.
Projects & catalog
Project metadata, approved QA objects, notes, and inspection structure.
Build & inspect
Validation, autosave, revision checks, role controls, inspection progress, and audit events.
PDFs & records
Generated documents, project history, backups, and recoverable archives.
04 · User workflow
Four steps from setup to retained record.
- 01
Create
Start a project with required identifying information and a server-assigned owner and date.
- 02
Build
Organize approved QA items into sections and configure the package for the work.
- 03
Inspect
Complete checks from a workstation or tablet with resumable, revision-aware saving.
- 04
Release
Generate the current PDF and preserve the project, inspection, and audit record.
05 · Engineering decisions
Built to survive outside the development machine.
The application was treated as an operational product. Deployment, access, recovery, concurrency, documentation, and maintainability were part of the design.
- Shared data root
- The desktop executable is separated from operational data so Windows permissions and shared storage can control access cleanly.
- Revision protection
- The web MVP rejects stale writes so two sessions cannot silently overwrite the same project or inspection.
- Role boundary
- Viewer, inspector, editor, and administrator capabilities are enforced by the server instead of relying on hidden buttons.
- Supportable delivery
- User guidance, deployment instructions, recovery notes, validation checklists, and architecture documentation are treated as product work.
Completed desktop outcome
One maintainable workflow replaced a collection of disconnected tasks.
The desktop release proved the complete product lifecycle: process discovery, data modeling, interface design, document generation, protection of user work, packaging, deployment planning, and support documentation.
06 · Web evolution
The React version is now a working, tested MVP.
React is not a second project bolted onto F.A.T. It is the same product moved to a shared architecture: no workstation installation, responsive inspection screens, server-enforced roles, conflict protection, audit events, and centralized document generation.
React + TypeScript client
A responsive project and inspection workspace tested across desktop and tablet-sized viewports.
Node API + persistent storage
Express, SQLite, project inspection records, server validation, audit events, and generated PDFs.
Roles + concurrency controls
Server-enforced access levels, revision checks, atomic inspection writes, and recoverable project archiving.
07 · Product evidence
Working screens, not concept art.
Demo records and work orders are synthetic. The generated document preview is intentionally redacted so project and QA content are not published.
08 · Validation evidence
The workflow was tested as a system.
Automated coverage exercises authentication, roles, project creation, configuration, inspection, saving, reloads, PDF preview, responsive behavior, restart persistence, and repeated release acceptance.
- 50 / 50
- full release-acceptance cycles passed
- 63
- responsive viewport sizes exercised
- 326
- stress-suite assertions passed
- 24.5 req/s
- average authenticated test throughput
Accurate status
The main web workflow is working and heavily tested, but it is not presented as a finished production release. Windows authentication, HTTPS and service setup, backup and monitoring operations, finalization controls, and a few administrator screens remain production work.
The larger takeaway