Start a project
Menu
Start a project
CASE STUDY

Rethinking online purchasing.

How the website, purchase calculator, mail-in purchase and auctions are becoming one focused white-label platform for pawnshops and gold buyers.

Field
Pawnshops & gold buying
Status
In development
Focus
White-label, transaction workflows, system boundaries
View VitrinoOSDiscuss a project
CONTEXT

Customer acquisition does not end at the contact form.

For pawnshops and gold buyers, a digital touchpoint can connect the public website, purchase calculator, mail-in purchase, status communication, documents, auctions and operator-specific branding.

The real product problem is the end-to-end digital transaction path.
01Public website
02Purchase calculator
03Mail-in purchase
04Status communication
05Documents
06Auctions
07Operator branding
CORE PROBLEM

Too many separate systems for one connected process.

Depending on the operator, the CMS, calculator, email communication, shipping, auctions and configuration may run separately. This creates broken handoffs, duplicated content and inconsistent status or brand logic.

01Website CMS
02Separate calculator
03Manual email
04Shipping steps
05Auction management
06Status enquiries
07Duplicated configuration
08Inconsistent branding
CRITICAL PRODUCT DECISION

Not another ERP.

VitrinoOS deliberately owns the digital customer and transaction layer. Existing domain core systems retain their responsibility and can connect through clear handoffs.

Owned by VitrinoOS

  • Website
  • Customer acquisition
  • Purchase valuation
  • Mail-in purchase
  • Auctions
  • Digital transaction flow

Remains external

  • Accounting
  • Pawn register
  • Internal AML systems
  • Existing ERP & back office
Clear system boundaries were a product decision, not a limitation.
WHITE-LABEL ARCHITECTURE

One core. Different operators.

One codebase supports operator-level configuration for company data, logo, theme, modules, legal texts and domain within clearly defined product boundaries.

01

Operator A

Its own brand, domain and module selection.

02

Operator B

Its own content, legal texts and visual configuration.

03

Operator C

Its own operator configuration on the same product foundation.

MAIL-IN PURCHASE FLOW

Mail-in purchase as one connected process.

The workflow connects structured data capture, shipping, review, offer, decision, documents and status communication. Encrypted sensitive data, a token-based customer portal, DHL integration and PDF documents support the relevant steps.

  1. 01Enquiry
  2. 02Data capture
  3. 03Shipping
  4. 04Arrival
  5. 05Review
  6. 06Offer
  7. 07Decision
  8. 08Documents & status

Clear states

Customer and operator views follow the same process.

Defined handoffs

Shipping, review and communication remain connected.

AUCTIONS

Auctions as their own digital process.

Auction management, catalogue, pre-bids, mobile auction-floor entry and reporting or CSV export form a distinct workflow within the platform.

  1. 01Auction
  2. 02Catalogue
  3. 03Pre-bid
  4. 04Auction-floor entry
  5. 05Reporting

Preparation

Structure lots and catalogue for publication.

Delivery

Keep pre-bids and mobile capture in one workflow.

Reporting

Prepare results for reports and export.

LEGAL & REGULATORY CONTEXT

Product decisions in a real regulatory environment.

Relevant requirements from the PfandlV and AML context, GDPR and privacy, distance selling and online transactions inform process and product decisions.

  1. 01Requirement
  2. 02Process decision
  3. 03Product boundary
  4. 04Operator review

PfandlV context

AML context

GDPR & privacy

Distance selling & online transactions

Specific legal assessment remains with responsible operators and their advisers; the platform makes no certification or completeness claim.
TECHNICAL IMPLEMENTATION

Pragmatic technology for a clear product focus.

The server-rendered application uses PHP 8.1+, MySQL or MariaDB, HTML, CSS, JavaScript and focused JSON endpoints. DHL and Microsoft 365 SMTP OAuth2 connect where the process requires them.

Role-based permissions, optional TOTP 2FA, CSRF protection, audit trails, AES-256-GCM, Ed25519-signed licences and integrity checks support clear technical boundaries.
01Server-rendered application
02PHP 8.1+
03MySQL / MariaDB
04HTML / CSS / JavaScript
05JSON endpoints
06DHL integration
07Microsoft 365 SMTP OAuth2
ARCHITECTURE EFFECT

What the product architecture already achieves.

Because VitrinoOS is still in development, this section describes architecture and product effects rather than claimed production outcomes.

01

Clearer process ownership

02

One coherent digital layer

03

Reusable white-label foundation

04

Deliberate back-office boundaries

05

Fewer duplicated product concepts

06

Consistent operator configuration

LESSONS

What this product demonstrates.

  1. 01

    Focus is often more valuable than feature breadth.

  2. 02

    Not every core system needs replacing.

  3. 03

    White-label needs clear configuration boundaries.

  4. 04

    Regulatory context is part of product design.

  5. 05

    System boundaries are a feature.

START A PROJECT

Which digital process should become clearer?

When several systems represent one connected customer process, it is worth examining product boundaries, handoffs and shared data.

Discuss a projectView VitrinoOS