Everything Boxed

The Problem

Everything Boxed is a product packaging and fulfilment business. They design, produce, and ship custom packaging for brands — gift boxes, subscription kits, promotional packaging, and branded unboxing experiences. Their business runs on relationships with large retail and e-commerce customers who place recurring, high-volume orders.

Their largest customer issued a mandate: switch to digital order processing and EDI-compliant invoicing, or the relationship ends. The deadline was fixed. There was no room for negotiation, no extension, and no fallback plan. Miss the deadline and the account — their single largest source of revenue — walks.

This is the kind of problem that breaks businesses. Not because the technology is impossibly complex, but because the stakes are high, the timeline is short, and failure is not a phased risk to be managed in a spreadsheet. Failure is binary. You either deliver or you lose the account.

Why Revitt

Everything Boxed had spoken to several technology providers. Most wanted to run a discovery phase, produce a specification document, and then estimate a delivery timeline that stretched well past the deadline. That approach works when you have time. They did not.

Revitt operates differently. We do not separate discovery from delivery. We start building on day one. The discovery happens in parallel with implementation — we learn the domain by writing the code that automates it. For a project with a hard deadline and no margin for delay, this is the only approach that works.

We came on as the sole technical team. No project managers, no business analysts, no intermediaries. The people who understood the problem were the same people writing the code.

Understanding EDI

Electronic Data Interchange (EDI) is not glamorous technology. It is a set of standards — EDIFACT, X12, and various industry-specific variants — for exchanging structured business documents between organisations. Purchase orders, invoices, shipping notices, and inventory updates flow between trading partners as formatted messages over secure transport protocols.

The standards are well-defined but unforgiving. A malformed invoice gets rejected. A missing field causes a processing failure on the customer's side. There is no "close enough" with EDI compliance — messages either conform to the specification or they do not. And when your largest customer's procurement system rejects your invoices, the conversation that follows is not a technical one. It is a commercial one.

Everything Boxed had been handling orders and invoicing manually — emails, spreadsheets, phone calls, and PDF invoices sent as attachments. The mandate required them to move to structured, machine-readable document exchange. Every order received electronically, every invoice sent in compliant EDI format, every transaction auditable and traceable.

Technical Approach

Integration Architecture

We designed the system around two integration paths: EDI and API. The primary path was EDI-compliant document exchange for the large customer that mandated it. The secondary path was a REST API for future customers who might prefer modern integration patterns over traditional EDI.

Both paths feed into the same internal processing pipeline. Inbound orders — whether they arrive as EDI messages or API requests — are normalised into a common internal format, validated, and routed to the operations team. Outbound invoices are generated from the same source data and formatted for the appropriate channel.

This dual-path design was deliberate. Building only the EDI integration would have solved the immediate crisis but left Everything Boxed dependent on a single integration pattern. By abstracting the internal processing from the transport layer, we gave them a system that could onboard new customers through either channel without re-engineering.

Event-Driven Processing

Order and invoice workflows are inherently event-driven. An order arrives, gets validated, gets accepted or flagged, triggers fulfilment, generates an invoice, and the invoice gets transmitted. Each step depends on the previous one, but the timing is unpredictable — an order might sit in validation for minutes or hours depending on whether it requires manual review.

We built the processing pipeline around an event-driven architecture. Each state transition — order received, order validated, order accepted, invoice generated, invoice transmitted — is an event that triggers the next step in the workflow. Events are persisted, which gives us a complete audit trail of every document that flows through the system.

This design has two advantages. First, it decouples the steps in the pipeline. If invoice generation is slow, it does not block order validation. If the EDI transport layer is temporarily unavailable, invoices queue up and transmit when the connection is restored. The system is resilient to partial failures.

Second, the audit trail is a natural byproduct of the architecture, not a bolt-on feature. Every event is timestamped, attributed, and stored. When the customer's procurement team queries why an invoice was sent at a particular time or with particular values, Everything Boxed can trace the complete history of that document from the original order through every processing step to the final transmission.

Operational Dashboard

Everything Boxed's operations team is not technical. They are packaging specialists, account managers, and logistics coordinators. They needed to see the status of orders and invoices without logging into a terminal or reading log files.

We built a dashboard that gives the operations team real-time visibility into the processing pipeline. They can see:

• Inbound orders — new, in validation, accepted, flagged for review.
• Outbound invoices — generated, pending transmission, transmitted, confirmed.
• Exceptions — orders that failed validation, invoices that were rejected, transmission errors.
• Audit history — the complete processing trail for any document.

The dashboard was designed for non-technical users. No jargon, no technical status codes, no raw data dumps. Each order and invoice has a clear status indicator. Exceptions surface with plain-language descriptions of what went wrong and what needs to happen next.

This was not a nice-to-have. The operations team needed to trust the system before they could rely on it. A black box that processes orders invisibly does not build trust. A dashboard that shows exactly what is happening, in real time, in language the team understands — that builds trust.

Data Integrity and Validation

Financial documents demand accuracy. An invoice with the wrong line item total, an incorrect tax calculation, or a mismatched purchase order reference creates reconciliation problems that cascade through both organisations' accounting systems.

We implemented multi-layer validation:

• Schema validation — every inbound and outbound document is validated against the relevant EDI or API schema before processing.
• Business rule validation — order quantities, pricing, product codes, and customer references are validated against Everything Boxed's internal data. Mismatches are flagged for manual review rather than silently processed.
• Cross-document validation — invoices are validated against the original purchase orders. Line items, quantities, and totals must reconcile. Discrepancies are caught before the invoice is transmitted, not after the customer's system rejects it.

This level of validation was essential. A system that transmits invalid documents is worse than no system at all — it creates problems faster than manual processing and erodes the customer relationship it was built to protect.

Delivery Under Pressure

The project ran on a compressed timeline. We did not have the luxury of iterating through multiple prototypes. The first version needed to work.

We prioritised reliability over features. The initial release supported the core workflow — receive orders via EDI, validate them, surface them to the operations team, generate compliant invoices, and transmit them back. Advanced features — analytics, reporting, customer self-service — were deliberately excluded from the first release.

This is a trade-off that teams under deadline pressure often get wrong. The instinct is to build everything the business might need. The reality is that a system which does three things reliably is infinitely more valuable than one which does ten things unreliably. We shipped the minimum viable system, confirmed it worked in production with real documents, and then expanded functionality in subsequent releases.

Testing was intensive. We validated document formatting against the customer's actual EDI specifications, ran end-to-end tests with sample orders and invoices, and tested failure scenarios — network outages, malformed inbound documents, concurrent processing edge cases. The system needed to handle not just the happy path but every realistic failure mode.

Results

• Key account retained — Everything Boxed met the deadline and maintained their largest customer relationship. The commercial risk was eliminated.
• EDI compliance achieved — all inbound orders and outbound invoices conform to the customer's EDI specifications. No rejections, no reconciliation failures.
• Operations team empowered — the dashboard gives non-technical staff real-time visibility into order and invoice status. They can identify and resolve exceptions without engineering support.
• Audit-ready processing — every document has a complete, timestamped processing trail. Compliance queries are answered in minutes, not days.
• Foundation for growth — the dual-path integration architecture supports onboarding new customers through EDI or API without re-engineering the core system.

Takeaway

The Everything Boxed project is a clear example of what happens when commercial risk and engineering execution intersect. The technical challenge — EDI integration, event-driven processing, operational tooling — was real but solvable. The harder problem was the context: a fixed deadline, a binary outcome, and a business relationship on the line.

Revitt executes in these situations because we do not separate planning from building. We start writing code on day one, prioritise ruthlessly, and ship systems that work under pressure. The result is not just a technical deliverable — it is a commercial outcome. Everything Boxed kept their largest customer because the system was live, compliant, and reliable before the deadline.

If your business faces a technical deadline with commercial consequences, we should talk. See how we approach these problems on our services page.