Air Cargo & Logistics Web Development
A system built to remove friction today and support growth tomorrow.
Norvie Air is an air cargo and freight forwarding company based in Miami, Florida, moving shipments between the United States, Jamaica, and the wider Caribbean on a core Miami to Kingston route.
Their commercial problem was not visibility. It was that every quote request arrived as an email or a phone call and had to be re-keyed by hand into the cargo system that actually issues air waybills. That re-keying is where turnaround time went, and where errors got introduced.
FIWB Solutions built the public site and, more importantly, the integration layer underneath it: a request submitted on the website arrives in Norvie's own cargo platform as a structured booking, and the customer gets a booking number back on the page before they close the tab.
Quoting and booking ran on manual coordination. A web form that only sent an email would have moved the typing rather than removed it, and an air waybill booking carries far more structure than a contact form: flight details, shipment dimensions, shipper and consignee records, handling requirements, and cost lines.
We built the website's forms to speak the cargo platform's language. The site posts to Supabase edge functions that translate a short customer-facing request into the full booking schema Norvie's API expects, submit it, and return the real booking number to the browser.
The translation layer is the product. A customer answers a handful of questions they can actually answer, and the edge function assembles the nested flight, shipment, shipper, consignee, remarks, and cost objects the booking API requires, marks the record as a quote request, and hands back the booking number the platform assigned. Nobody re-types anything.
We treated a lost lead as the failure worth engineering against. Each function calls a primary API endpoint and fails over to a secondary if the first errors or times out, so one upstream outage does not silently drop a shipment enquiry. Every call is bounded by an abort timeout so a hung vendor cannot pin the function open.
The copy was written to match what actually exists. Planned platform features are labelled as planned, and the site ships first-party commitments instead of invented customer testimonials.
The forms are not email forwarders. A quote submitted on the website becomes a structured booking record inside the cargo platform that issues air waybills, and the customer sees the booking number the platform generated. The work that used to happen after the enquiry landed now happens as it lands.
The submission path is hardened the way a public endpoint has to be: an explicit origin allowlist rather than a wildcard, per IP rate limiting, payload size caps checked before the body is parsed, field level validation and truncation on the server, and fixed error strings so a failure never reports what broke to whoever is probing. Public submissions are write only at the database level, enforced by row level security rather than by the function in front of it, so the policy holds even if someone posts directly to the API.
Quote and booking requests now arrive as structured records instead of emails to be re-keyed, and the customer gets a booking number immediately rather than waiting for someone to confirm receipt. The manual coordination step between a request and the cargo system is gone.
A form that files the booking is worth more than a form that sends an email about the booking.