How a Scrap Metal Trading Business Replaced Manual Selling With a Digital Bidding Platform

The client buys and sells ferrous scrap, non-ferrous scrap, and ferroalloys, sourcing material from suppliers and distributing it to the customers who need it. Every sale used to run through phone calls, manual customer approvals, and paper-based verification. When the client decided to go digital and automate the selling process, they brought the project to Solvios.

How a Scrap Metal Trading Business Replaced Manual Selling With a Digital Bidding Platform
Client

A scrap metal trading company operating in the ferrous, non-ferrous, and ferroalloy scrap segments

Duration

3 months

Industry

Metal Scrap Trading

Country

Not confirmed in available source material flagged for review

The Challenge They Brought to the Table

The client is a business-to-business scrap metal trader buying and selling ferrous scrap, non-ferrous scrap, and ferroalloys. Their entire sales process ran manually, with owners approving customers over the phone and tracking offers on paper. Solvios built a web application for the owners and a hybrid mobile app for customers, connecting product listings, customer verification, and bidding in one system. The result was a digital selling process that replaced manual coordination with a structured, trackable workflow.

No digital way for the client to list scrap products or offers

Customer approvals handled manually, with no verification trail

No structured bidding process for offers on scrap lots

No visibility into which customers were active or eligible to bid

No reporting on offers made, bids received, or deal status

Growing transaction volume made phone-based coordination harder to sustain

The Approach We Recommended

When Solvios started the engagement, the client's selling process lived almost entirely outside any software system. Offers were negotiated over calls and in-person meetings, and there was no central record of who had bid on what or where any deal actually stood.

No web platform for owners to publish products or offers

No mobile app for customers to browse, register, or bid

No document verification step before granting bidding access

No dashboard to track pending approvals or top bidders

No workflow for tracking the status of individual bids

No reporting layer to review offer and bid activity over time

key challenges background

The Problem That Needed More Than a Quick Fix

A basic listing page wouldn't have solved this. The client needed a system that handled two different user groups, owners managing offers and customers bidding on them, plus a verification layer that kept unqualified buyers out of the bidding pool.

Two-Sided Platform, One System

Owners needed to create and manage offers from one interface, while customers needed a separate mobile experience to browse and bid. Building these as disconnected systems would have created data mismatches and support headaches later.

Verifying Customers Before They Could Bid

Not every customer who signed up should have been allowed to bid. The client needed a way to confirm business licenses and financial documents before granting bidding access, without turning onboarding into a multi-week process.

Tracking Bid Status Without a Paper Trail

Offers moved through several stages before a deal closed, and the client had no way to see where any individual bid stood. Whatever we built had to make bid status visible without owners having to chase updates manually.

Reporting That Owners Could Actually Use

The client wanted to review offers and bids by date and time, not dig through a spreadsheet someone updated inconsistently. The reporting layer needed to be simple enough for non-technical owners to use on a daily basis

How We Approached It?

We started by splitting the platform into two clearly scoped applications: a web application for the client's owners and a hybrid mobile app for customers. Keeping the interfaces separate, while sharing the same backend and data model, kept both experiences focused on what each user group actually needed to do.

Scoping Two Interfaces Around Two User Groups

Before writing any code, we mapped what owners needed versus what customers needed. Owners needed to create products, review offers, and approve customers. Customers needed to register, upload documents, browse offers, and place bids. That split shaped the entire architecture.

Building the Document Verification Flow First

Since bidding access depended on verified documents, we built the upload and review flow early. Customers submit business licenses and financial documents through the mobile app, and owners review and approve them from the web dashboard before bidding access unlocks.

Designing the Bid Workflow Around Real Statuses

We mapped out the actual stages a bid moves through, from submission to owner review to acceptance or rejection, and built a workflow that reflects those statuses in real time on both the owner and customer sides.

Building a Hybrid Mobile App for Cross-Platform Reach

Rather than building and maintaining separate native apps, we built a hybrid mobile application so customers on either platform get the same bidding experience without doubling the development and maintenance effort.

Layering in Reporting Without Overcomplicating It

The reporting requirement was straightforward on paper but easy to overbuild. We kept it to what owners actually asked for: date and time filters on offers and bids, so they can see activity at a glance instead of running manual counts.

filter list background

What We Built & Delivered

The final platform pairs a web application for the client's team with a hybrid mobile app for customers. Together, they cover product listing, customer verification, bidding, and reporting in one connected system.

Admin Dashboard

Admin Dashboard

An intuitive dashboard where owners check ongoing offers, review pending customer approvals, and see top bidders at a glance, without switching between separate tools.

Document Verification

Document Verification

Customers upload business licenses and financial documents directly from the mobile app. Owners review and approve them before bidding access is granted, keeping unverified buyers out of the process.

Bid Workflow Management

Bid Workflow Management

A structured workflow tracks every offer and bid status, so both owners and customers always know where a given bid stands without needing to ask.

Custom Reporting

Custom Reporting

A reporting module with date and time filters gives owners a clear view of offer activity and bid volume, replacing manual tracking with a report they can pull on demand.

Customer Registration & Profile Management

Customer Registration & Profile Management

Customers register through the mobile app, manage their profile, and track their own offer and bid history in one place.

Cross-Platform Bidding Access

Cross-Platform Bidding Access

Built as a hybrid mobile app, customers can browse offers, view statuses, and place bids from either iOS or Android without the client maintaining two separate codebases.

What Changed After We Shipped

The client went from a fully manual, phone-driven sales process to a digital platform that owners and customers both use directly. The changes weren't about a single metric spiking, they were about removing the friction that manual coordination created.

Faster - Customer Onboarding

Faster - Customer Onboarding

Document verification through the app replaced back-and-forth phone calls and in-person paperwork, shortening the time between signup and bidding eligibility.

Clearer - Bid Visibility

Clearer - Bid Visibility

Owners and customers can both see where a bid stands at any point, cutting down on the status-check calls that used to interrupt the day.

Simpler - Offer Reporting

Simpler - Offer Reporting

Owners pull date-filtered reports directly from the dashboard instead of reconstructing offer history from notes and memory.

Reduced - Manual Coordination

Reduced - Manual Coordination

Moving offer creation and bid tracking into one system took the daily back-and-forth of manual approvals off the owners' plate.

Scalable - Customer Base

Scalable - Customer Base

A self-service registration and bidding flow means the client can bring on more customers without proportionally increasing the manual workload. None of these changes required the client to hire more staff or change how they source scrap. The platform simply gave their existing process a system to run on.

Solvios Technology not only created a new website, but a logo and its marketing campaigns, as well. They had well-established management that understood all of the client's needs, big or small. The team also commendably understood the client's industry.

Mayank, Founder, Scrap Metal Trading Company

Ready to Digitize Your Own Buying and Selling Process?

If manual approvals, phone-based coordination, or disconnected spreadsheets are slowing down how you sell, a structured web and mobile platform can take that friction off your plate the way it did here.

Response within 24 hours. No commitment required.

Talk to Our Team
Ready to Digitize Your Own Buying and Selling Process?

How the Engagement Ran

The engagement ran for three months with a five-person team: a project manager, a UI/UX designer, a backend developer, and two mobile app developers. We structured the work in five phases to get the verification and bidding core built first.

Discovery & Requirement Mapping
01

Discovery & Requirement Mapping

We mapped the owner and customer workflows separately, defined the document verification requirements, and scoped what a hybrid mobile app needed to cover on both platforms.

UI/UX Design
02

UI/UX Design

Our designer built out the owner dashboard and the customer-facing mobile flows, keeping registration, document upload, and bidding as simple as the process allowed.

Web Application Development
03

Web Application Development

The backend developer built the web application owners use to create products, manage offers, and review customer approvals, along with the shared data layer both apps run on.

Mobile App Development
04

Mobile App Development

The two mobile developers built the hybrid customer app covering registration, document upload, offer browsing, and bidding, wired into the same backend as the web application.

QA, Reporting & Launch
05

QA, Reporting & Launch

We tested the bid workflow end-to-end across both apps, built out the reporting module, and moved the platform into production through a phased rollout.

Mayank, Founder, Scrap Metal Trading Company

filter list background

Frequently Asked Questions

For a scoped engagement like this, three months is realistic when the team includes a project manager, a UI/UX designer, a backend developer, and dedicated mobile developers. That timeline covers discovery, design, parallel web and mobile development, and testing. It assumes the core scope, product listings, customer verification, and a bidding workflow, stays fixed once development starts. Adding features like payment processing, advanced analytics, or multi-language support would extend the timeline. The fastest path to an accurate estimate is a discovery call where we map your specific offer and bidding requirements before committing to a number.

A hybrid app lets customers on either platform use the same bidding experience from a single codebase, which cuts development time and ongoing maintenance compared to building and updating two native apps in parallel. For a customer-facing bidding flow that isn't pushing the limits of platform-specific hardware, the performance trade-off is minor. Native development makes more sense when an app needs deep platform integration or heavy device-level performance. For registration, document upload, and bidding, a hybrid approach gets you to market faster without giving up meaningful functionality.

Customers upload business licenses and financial documents directly through the mobile app during registration. Those documents route to the owner's dashboard on the web application, where they're reviewed and either approved or rejected before bidding access unlocks. This keeps the verification decision in the client's hands rather than automating an approval that carries financial risk. The workflow keeps the review queue visible, so owners can see pending approvals alongside active offers instead of tracking verification requests separately from the rest of their sales activity.

Yes. The architecture separates the customer-facing mobile app from the owner-facing web application, both running against a shared backend, so growth in customer registrations or offer volume doesn't require rebuilding either interface. The reporting and bid workflow modules are built to handle increasing data volume without a redesign. What typically needs revisiting at scale is infrastructure sizing and, potentially, database optimization if offer and bid volume grows significantly. Those are operational adjustments, not architectural rebuilds, which is why we design the data model with growth in mind from the start.

The platform runs on React JS for the front-end and MySQL for the underlying database, chosen for a straightforward reason: they matched the client's team's ability to maintain the system after launch, and they're proven for the kind of structured, relational data that offers, bids, and customer records represent. We don't default to a single stack across every project. The right choice depends on the client's in-house technical capacity, the data structure the application needs, and how the client plans to scale after the initial build.

Didn't Find What You Were Looking For?

Get In Touch With Our Experts

Need Project Consultation? Let’s Talk

We'd love to understand what you want to build. The more context you share, the faster we can give you a useful response not a sales pitch, but a genuine assessment of how we can help and what working together would look like.