Back to Main PageA closed vehicle intelligence portal built around one input. A VIN becomes structured specifications, open recall campaigns, history and risk signals, and an operational shipping status — with per-customer usage the administrator can see and limit.
This case study focuses on the delivery constraints, product choices, and workflow decisions that shaped the build.
Closed B2B portal
One VIN
Private production system
Let a customer find serious problems with a vehicle before buying it, rather than discovering them after it has reached the warehouse — and give each customer a controlled way to do it.
Providers disagree on schema, vocabulary and coverage; a missing record is not the same as a clean record; and every report costs money, so usage control is part of the business model rather than a security afterthought.
One controlled VIN workflow. The customer sees a consistent report with uncertainty left visible; the administrator sees who is using the system and how much; issues surface earlier in the purchase process.
Vinegy began with a deceptively small question: can a customer check whether a vehicle has serious issues before buying it, instead of discovering them after it reaches the warehouse? That question exposed a larger operational problem. Useful vehicle information existed, but it was scattered between decoding services, recall data, history providers and internal judgment.
Shipkit turned that idea into a closed vehicle intelligence system built around one input — the VIN. The finished workflow combines vehicle identity, recalls, history signals, risk indicators, saved searches, account controls and an operational shipping status in one report.
The obvious solution had several problems: a premium consumer vehicle-report product was too expensive for the intended workflow, recall data lived elsewhere, deeper history required a separate provider, the business needed to control how often each customer could run reports, credentials could be shared, and raw provider output is not the same thing as an operational decision.
So the real product was never paste a VIN and show some data. It was: give each customer a controlled way to turn a VIN into a useful pre-purchase and shipping-risk decision. That reframing changed the scope significantly, and it is the part of the engagement that mattered most.
Vehicle data looks clean only after someone has normalised it. One provider describes a title event one way, another uses a different status vocabulary, and an official recall source exposes completely different identifiers and response structures.
The system therefore needed an integration layer between the external APIs and the user-facing report. Instead of letting provider-specific fields leak into the UI, we mapped responses into internal concepts — vehicle identity, recall status, accident or damage signals, salvage and total-loss signals, theft information, odometer warnings, and other available history indicators. That makes the product easier to reason about and reduces coupling to any one provider.
This is one of the most important problems in risk-oriented software. If a provider returns no record, there is a meaningful difference between checked and nothing found, this source does not cover the requested field, the provider failed, the VIN could not be resolved, and this result requires review.
A simplistic green-or-red interface turns uncertainty into false confidence. We designed the report around explicit status and readable warnings, so missing or incomplete information stays visible instead of silently becoming a pass.
Raw history is useful, but the business also needed a fast answer for the shipping workflow. That led to a higher-level status model — safe to ship, needs review, hold before shipping.
The important engineering decision was keeping the reasoning explainable. A status is tied to identifiable signals in the report rather than produced as an opaque score with no way for staff to understand why a vehicle was flagged. That is what makes the system decision support instead of a black box.
Each report can involve third-party services with their own cost, limits, latency and failure modes, so the system cannot treat every click as a free request. We designed account and usage controls into the product rather than adding them after abuse appeared.
The administrative model tracks which customer ran a search, how many VINs they checked, report history, per-customer limits, suspicious usage patterns and account activity. The client explicitly expected credentials to be shared unless the product made usage visible — which is why access control here is part of the business model, not merely a security feature.
The same VIN may be checked more than once. A production integration layer has to decide when a previous result can be reused, when information should be refreshed, and which source must be called again — balancing report freshness, provider cost, user speed and traceability.
Saved reports also preserve what the system showed at the time of a decision, rather than treating every report as an ephemeral API response.
Many SaaS products optimise for public signup. Vinegy needed the opposite: accounts are issued and controlled by the business, because access represents real API consumption and an operational relationship with the customer.
That decision simplified the customer experience while giving the administrator control over who can reach the portal, usage allowances, account suspension, search history and unusual activity. Public growth mechanics would have made the product less appropriate for the actual workflow.
A user should not need to know which provider returned which JSON field. The external services are implementation details; the product's job is to present a coherent answer while preserving enough detail for a person to understand the underlying evidence.
That is why we separated the provider layer from a normalised domain model, the report, and the operational status. It also means an individual provider can be changed or supplemented later without redesigning the customer experience.
The customer portal carries private login, VIN input and validation, vehicle decoding, the vehicle report, recall information, available history signals, risk indicators, shipping status, report history and saved reports.
The data integration layer handles multiple vehicle-data sources, provider response normalisation, an internal report schema, graceful handling of partial data, error states and provider-independent presentation. Administration covers customer management, issued accounts, search visibility, usage tracking, customer-specific limits, activity review and abuse monitoring.
Vinegy replaced a fragmented multi-source research process with one controlled VIN workflow. The customer sees a consistent report, the administrator sees who is using the system and how much, and the business can surface meaningful issues earlier in the purchase process instead of waiting until the vehicle has progressed further through operations.
Most importantly, the product does not pretend that more data automatically means better decisions. The value comes from collecting the right data, normalising it, exposing uncertainty, and presenting it in the context of the action the business is trying to take.
A private B2B web portal with customer authentication, report history and admin-provisioned accounts sits over an integration layer that validates and decodes the VIN, pulls recall and paid history data, normalises everything into one internal report schema, and handles provider errors. A decision layer turns that into risk indicators, explicit unknown and review states, shipping-status rules and human-readable reasoning, while the operations layer carries per-customer usage tracking, configurable limits, activity visibility, saved reports and abuse review.
If you are scoping a marketplace, customer portal, or workflow-heavy MVP, start with the smallest transaction that proves the business works. Then estimate the cost, compare custom code against no-code, and decide which features belong in version one.
Because the value is in the combination and the reconciliation, not the data. Individual decoding, recall and history services exist, but an operator checking dozens of vehicles needs one report with a consistent shape and a status they can act on — not four tabs and a mental merge.
That is the hardest question in risk software. Checked and nothing found, not covered by this source, provider failure, unresolvable VIN and needs review are five different outcomes, and a green-or-red interface collapses them into false confidence. The report keeps them distinct with explicit status and readable warnings.
The tool queries paid, rate-limited vehicle data on the organisation's behalf, so every report has a cost. Administrator-issued accounts with per-customer limits keep both the cost and the access under deliberate control — which is the normal shape for an internal system and the wrong shape for a consumer product.
Yes. Integration-heavy products look simple from the outside — one text field and one report page — while hiding inconsistent providers, partial coverage, paid requests, retries, entitlement, caching, auditability and risk semantics. Shipkit designs that layer before it becomes technical debt. Start with an estimate of scope.
Book a free founder call. We'll help you figure out what to build first, what it'll cost, and how fast we can launch it.
Limited availability — email alex@shipkit.us or use the contact page to start the conversation.
