# Marevia > Provider-led, multi-tenant freight software designed and built in full by Adam Amr. Marevia combines provider-customer account management, a private marketplace for freight requests and quotes, shared shipment workspaces, and AI that works across the product. - [Visual case study](https://adamamr.me/projects/marevia/) - [Live product](https://marevia.ai/) - Built by Adam Amr ## What Marevia is Marevia is software for logistics providers and the customers they already serve. A provider can bring its customers into one portal, manage each relationship, publish the services and rates it is prepared to offer, respond to freight requests, and run awarded shipments. A customer can work with several connected providers, send one structured request to any combination of them, compare their offers, choose one, and continue the work with the winning provider. This creates a private marketplace inside an operational customer platform. A customer can request competing offers from any combination of its connected providers while every company keeps its own account and data boundaries. The product replaces a familiar split across email threads, spreadsheets, attachments, tracking sites, and separate customer portals. The request, every quote, the commercial decision, the shipment, its messages and documents, and its tracking history remain connected. ## Adam's work Adam built the whole product. He defined what Marevia is, designed its interfaces, and built the systems behind them. His work spans: - the product model and provider-led private network; - the complete RFQ, matching, quote, award, shipment, tracking, document, and customer-account flows; - customer and provider onboarding, company verification, teams, roles, and relationship lifecycles; - the visual direction, custom assets and landing pages, product language, interaction and motion, typography, hierarchy, spacing, and the hell of making a data-dense interface look and feel coherent; - the web interface, responsive and bidirectional layouts, native mobile companion, and separate light and dark design systems; - the backend, realtime data, permissions, files, carrier tracking, billing, email, authentication, and other integrations; - the matching engine that compares each RFQ with provider services and rates without excluding providers that need to quote manually; - the AI infrastructure: a provider-agnostic model layer, product tools, relationship-aware context, streamed conversations, custom charts and shipment views, navigation, and approval-gated actions; - the product specifications and tests needed to keep those systems consistent. The difficult part was making all of those domains agree while keeping the product delightful to use. A relationship changes what the matching engine can use, which changes who receives an RFQ, which changes what the AI can see, which changes what both companies can do once a quote becomes a shipment. Adam designed those connections as well as the individual features, then worked through the language, states, movement, density, and edge cases until the whole product felt coherent. ## Provider-customer network Marevia uses a many-to-many organization network. A provider can manage many customers, and a customer can connect to many providers. The companies remain independent tenants; accepting a provider invitation does not make the customer a member of the provider's organization. An active relationship makes a provider eligible to receive new work and lets a customer see an approved, customer-safe view of that provider's services. It does not grant broad access to either company's data. Providers get a focused account view for each customer: invitations, current relationships, shared RFQs, quotes, active shipments, and work that needs attention. It serves the operational purpose of a CRM without introducing sales stages, pipeline fields, or generic account theatre. Either company can end a relationship. That prevents new requests and current service browsing, but it does not erase or disable work already shared. Existing RFQs can still be answered, accepted quotes remain valid, and shipments continue with their history intact. ## From request to shipment The RFQ builder collects the route, freight mode, equipment, cargo, handling requirements, dates, service scope, and additional services in a structured form. The request stays reviewable while it is being prepared. The AI can collect the same details in conversation and produce an editable draft. The customer then chooses one, several, or all connected providers. Every selected provider receives the RFQ, even when Marevia finds no matching service or rate. Matching can return an instant catalogue price or identify a service that needs the provider's response. It automates commercial work; it never acts as a gatekeeper. A provider without a match can always quote manually. Offers return to the RFQ with price, transit time, validity, inclusions, and provider details together. Accepting one creates a shipment workspace shared by the customer and the provider that won the work. That workspace preserves the accepted terms and carries the work forward through messages, documents, events, and tracking. Carrier data appears beside manual milestones and schedule changes. Tracking history is append-only, so a correction becomes a new event rather than silently rewriting what was previously known. Dashboards on both sides summarize open requests, quotes awaiting a decision, active shipments, deadlines, schedule drift, and exceptions. Items that need action link back to the underlying record. ## Matching engine Providers describe the work they can handle through services and rates: lanes, freight modes, equipment, cargo types, handling requirements, timing, and pricing. Marevia compares an RFQ with that catalogue and explains the result in the commercial flow. A strong match can produce an instant price. Another match can identify the relevant service but still ask the provider to respond. No match does not remove the provider. If the customer selected that company, it receives the request and can quote manually. Adam designed and built the matching engine around that rule: automate useful work without letting incomplete catalogue data decide who gets an opportunity. ## Privacy and shared work Marevia keeps each company independent even when two companies share work. The interface does not merely hide private records; access is checked on the server whenever data is read or changed. A relationship lets a customer send new work to a provider, but it does not expose the customer's whole account. Marevia keeps a record of exactly which provider received each RFQ and which two companies share each shipment. A provider cannot see a customer's other providers, competing offers, unrelated RFQs or shipments, team, or private settings. A customer cannot see a provider's internal costs, margins, drafts, paused services, other customers, or internal notes. The same rules hold through invitations, recipient selection, quotes, award, files, tracking, AI, and relationship changes. Existing work remains usable when a relationship ends; new work is blocked without rewriting history. ## AI throughout the product The AI assistant is part of Marevia's operating model rather than a chat box added beside it. It works over live product data and stays inside the same organization, relationship, and record boundaries as the person asking the question. It can search customers and providers, understand which relationship a person means, inspect RFQs and quotes, review shipments and tracking, read documents, summarize provider capabilities, compare commercial terms, build charts from operational data, generate shipment visuals, and open the record behind an answer. A question about one customer or provider stays inside that relationship instead of blending it with the wider account. For shipment documents, Adam built an asynchronous retrieval pipeline that turns uploaded files into searchable content isolated to each shipment. The assistant pulls only the relevant sections for a question, respects the same access controls as the rest of Marevia, and says when some files could not be searched. Adam built the AI infrastructure as well as its visible features. The model layer is provider-agnostic, so different models can be routed through the same product contracts. The assistant has purpose-built tools instead of one large data dump, persistent streamed conversations, and custom renderers for charts, routes, shipment views, and documents. It can move from an answer into the actual workspace that supports it. The assistant can also produce a document the user keeps. It writes a structured briefing over live operational data and renders it as a PDF in the browser, charts and tables included, so the report is built where the person asked for it instead of being sent to a rendering service. Reports are laid out for print in light or dark paper, carry Latin and Arabic text, and are bounded by size and time limits so a long briefing cannot hang the page. The assistant reads what the user is allowed to read. Changes to real work are prepared for approval. It can turn a plain-language shipment description into a complete RFQ draft, but the user reviews and approves it before anything is created. It cannot quietly send an RFQ, accept a quote, change a shipment, invite a company, or end a relationship. The same threads, tools, and shipment visuals are available in a native mobile companion. The mobile app uses the same AI infrastructure and product permissions rather than becoming a separate, reduced assistant. ## Onboarding and verification Customer and provider organizations follow different verification paths because they carry different risks. Customers creating a new workspace submit a country, tax registration number, and tax document during onboarding. Marevia checks that the company is not already registered, compares the document with the number provided, and either verifies the evidence or sends it for human review. Ambiguous or unreadable evidence goes to a person rather than being silently approved or permanently rejected. Provider verification remains a human approval process before the provider can invite customers and operate in the network. Applications can be saved, reviewed, rejected with a specific reason, corrected, and resubmitted. Both flows account for duplicate companies, mismatched numbers, unreadable files, unavailable checks, pending review, rejection, and recovery. A failed check explains what happened and what the person can do next. ## Interface and design systems Marevia's light and dark modes are purpose-designed systems. Dark mode is not an inverted copy of the light interface. It has its own surface tokens, component states, chart treatment, status colors, selection, focus, depth, edges, and shadows. Its operational material uses charcoal with burnished gold, marine blue, emerald, and garnet where the data calls for them. The interface handles dense freight data without turning every page into a table. RFQs retain a persistent review summary, quote comparison keeps commercial terms aligned, shipment pages preserve a long operational history, and dashboards distinguish routine movement from work that needs attention. That care extends beyond the large screens and workflows. Adam worked at the level of typography, spacing, product language, focus, motion, loading, empty states, errors, and small transitions. Those details keep the interface calm and coherent even when the operation behind it is complicated. Custom freight assets give routes, service scopes, tracking events, and AI-generated shipment views a visual language of their own. Responsive and mobile layouts are designed for real operational use rather than scaled-down desktop screenshots. The web product supports both left-to-right and right-to-left layouts, and live updates allow new quotes, messages, tracking events, and approvals to appear without manual refresh. ## A note on the work Marevia has probably asked more of me than anything else I have built, at least up to this point. I have worked on it across product design, logistics, backend architecture, authorization, data modeling, AI, tracking, performance, mobile, motion, branding, and all the strange details that appear somewhere between those things. A lot of that work disappears when it is done properly. A conversation simply scrolls smoothly. A shipment route just looks correct. A company gets verified without feeling like it went through a janky compliance system. A page opens with its data already there. An illustration makes a complicated choice easier to understand. I spent an unreasonable amount of time on things most people will never know were difficult. I rebuilt major parts of the underlying system, including the data model and architecture seven times if not more, as my understanding of the product, domain, and its needs became sharper. That also meant being willing to change the product itself, including rebuilding it from a marketplace-first idea into the private provider-customer network it is now. I obsessed over things as broad as authorization and shipment-tracking semantics and as specific as thread ergonomics, streaming behavior, scroll anchoring, material lighting, motion timing, and the exact way information enters the screen. A lot of the work was difficult, some of it was thrown away, and plenty of it will probably change again. But I tried very hard not to leave something at "it works" when I knew it could be clearer, stronger, faster, or simply feel better. I care a lot about what I made here. I tried to bring the same level of attention and care to the systems nobody sees and the pixels everyone does.