Case Study
CLOSE-OUT PACKAGE MANAGEMENT SYSTEM
Role
Backend Engineer
Platform
Telecom Field Operations Platform
Core capabilities
- Chunked Uploads
- PDF Pagination
- Scoped RBAC
- Approval Workflows
.webp)
What is Close-Out Package?
An enterprise telecom construction platform for managing Verizon cell-site close-out documentation from field capture to customer delivery. It brings staged photo collection, GPS verification, manager approvals, document revisions, and automated PDF generation into a single workflow, replacing manual package assembly with a traceable, approval-driven process.
What I built
- Scalable close-out PDF generation. Reworked PDF generation for 300+ image packages — ~6× the previous 45–50 baseline, no hard photo cap. Replaced browser-driven page breaks with server-side budgeting in PHP: an 880px content box, four photos and twelve site details per page, thirty picture categories per page, checklist rows tiered by label length — so the renderer knows what page N holds before Chromium starts. That budget exposed a real integrity bug: page count was an unsignedTinyInteger, so a 1,000-photo package silently overflowed past 255 pages. Rendering is isolated on a supervisor capped at 2 processes and 512 MB, photos normalise to a 1200px JPEG that never upscales, and a decode failure falls back to the original file rather than failing a customer deliverable.
- Reliable bulk media uploads. Field batches run to hundreds of photos over cellular, and one monolithic request can’t survive a tunnel, a signal drop or a mid-batch navigation. So I built the four-phase protocol — initiate, chunk, finalize, abort — rather than assume a library covered those failure modes. Authentication is a stateless HMAC-SHA256 token (no session row can half-authenticate an upload). Duplicate chunks are idempotent, out-of-order arrival is tolerated through zero-padded filenames, finalization is row-locked, and a full disk returns 507 rather than a stack trace. Failed processing keeps its chunks so the retry can succeed.
- Customer-approved change orders. Managers propose scope changes, but a customer should not have to create an account to approve one. Change orders are delivered to explicitly listed recipients through a signed token route, so the customer can review and decide without signing in. Decision tokens are minted at delivery time and never stored, so a leaked link cannot be replayed against a decision that has already been recorded.
- Template-driven packages. Document structure is configuration, not code. Templates define per-stage sections, picture categories carrying a required count and a required flag, and checklist items that may request an explanation or permit N/A. That structure is instantiated per project, and when a template changes underneath an in-progress draft a drift service reconciles it — raising a conflict only where a picture bucket has shrunk below what has already been uploaded, and otherwise syncing new categories and checklist items into the live package.
- Project-scoped authorization. Four roles see the same objects at different lifecycle stages, so authorization was a design problem rather than a CRUD one: each ability resolves role, relationship scope and workflow state together. An open customer feedback round is the customer's private draft — staff see nothing at all, not even image counts, so nobody can watch a customer compose a review. I then wrote a 48-case adversarial probe from the domain rules before reading my own implementation; it caught boundary issues in role, scope, and feedback ownership, which I corrected before release.
- Reliable customer communication. A duplicate close-out document damages a client relationship permanently, so delivery is guarded four independent ways rather than one: atomic conditional status transitions, delayed jobs that snapshot the schedule they were dispatched with, an attachment policy re-evaluated at delivery so a link scheduled for next week is freshly signed instead of expiring in the queue, and idempotency keys sized to fit the column exactly. Email templates are configurable per type, and a suppressed send is retained as an audit record rather than silently dropped.
System scope
- Three-stage field operationsPre-Construction, Construction and Post-Completion workflows driving telecom site documentation from first capture to sign-off.
- Field media and library managementCapture, organise, review, replace and reuse project photos and their metadata, with GPS/EXIF validation and configurable per-category limits.
- Template builderConfigure close-out templates, their picture categories and reusable category presets, and the documentation requirements that decide how field submissions become a deliverable.
- Automated close-out packagesBranded Verizon-format PDF packages generated from submitted field documentation, with revision management and approval controls.
- Change-order managementCreate and submit change orders, request customer approval, and collect the decision through a signed link.
- Technician location trackingField-technician location visibility for operational coordination, with idle detection and stale-ping pruning.
- Customer email managementAuthorised managers and administrators send customer email manually, manage per-type templates, and track delivery activity through an audit log.
- Customer review portalCustomer-facing access to package documentation, review workflows and threaded feedback, granted per project.
- SOW and project administrationStatements of Work with annotated images, market-scoped projects, dashboards, and role-based access across the portfolio.
Inside the product
LET'S BUILD
YOUR NEXT SYSTEM
Whether you are hiring for a backend engineering role, architecting a multi-system SaaS platform, or automating complex operational workflows — let's connect.