DEV Community: tabban Ghani

SurplusLink AI Turning Surplus Bakery Inventory Into a B2B Side Hustle

tabban Ghani — Mon, 19 Oct 2026 02:07:42 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

What I Built

Every day, food manufacturers, bakeries and wholesalers face a familiar business challenge: having inventory they need to sell before it loses commercial value.
At the same time, small retailers are searching for affordable stock but may lack direct access to suitable wholesale suppliers.

What if AI could help these businesses discover more easily?

That question inspired SurplusLink AI, an AI-assisted B2B marketplace prototype focused on surplus packaged bakery products in Pakistan.

The idea is simple:

Wholesalers list available inventory, retailers describe what they need, and the platform connects compatible supply and demand.
Instead of becoming another generic chatbot, SurplusLink uses an open-weight language model for a specific business task: converting informal product descriptions into structured marketplace information.
The initial product scope includes sealed packaged goods such as biscuits, rusks, crackers and cookies. Real-world deployment would require appropriate product verification, expiry controls and food-safety compliance.

Who would pay for this?

The intended customers are wholesalers who want to recover value from excess inventory and retailers who want to source products at competitive prices.

The core workflow

A wholesaler lists product details, quantity, asking price, location and expiry information.
A retailer enters what they need using natural language.
AI extracts structured information:An open-weight language model identifies relevant product attributes.
The backend evaluates compatible inventory using deterministic business rules.
Buyers submit offers that sellers can accept or reject.
Accepted offers reserve inventory and generate transaction records. The prototype also explores a simulated checkout process and a transaction-based marketplace revenue model.

Demo

https://www.youtube.com/watch?v=gDrjds6meFg

Code

https://github.com/taba123-debug/SurplusLink-AI-frontend
https://github.com/taba123-debug/SurplusLink-AI-backend/

How I Built It

1.Designing the marketplace around real business entities:

I started by treating SurplusLink as a marketplace rather than an AI chat application.The backend data model covers organizations, business memberships, surplus inventory, buyer requirements, offers, deals, payments and transaction events.
PostgreSQL manages these relationships, while SQLAlchemy and Alembic provide database models and versioned migrations.

One important inventory rule is:

Available Quantity = Total Quantity - Reserved Quantity - Sold Quantity.This separation makes it possible to track stock committed to accepted deals without confusing it with inventory that has already been collected.

2.AI-assisted inventory understanding

One of the main usability problems in a marketplace is that sellers and buyers describe products differently.
For example, a retailer might write:
I need 150 biscuit packs in Lahore, under Rs. 20,000, with at least 30 days of shelf life.

The AI extraction layer is designed to information such as:

Product category: BISCUITS
Quantity: 150
Unit: PACK
Maximum budget: Rs. 20,000
City: Lahore
Minimum remaining shelf life: 30 days

The extracted values are validated using Pydantic before they can be used as structured marketplace information.Missing fields are not supposed to be guessed. Users review and confirm extracted details before saving them.I moved toward a hosted open-weight Llama model through GroqCloud to avoid downloading model weights onto my development laptop.

3.Two-way inventory matching

SurplusLink is designed to work in both directions.A buyer can discover seller listings that match a saved purchasing requirement.A seller can discover buyer requirements that are compatible with an available inventory lot.Rather than delegating every decision to an LLM, the matching engine uses explicit rules such as product category, unit, quantity, city, expiry, shelf life and price.

The AI interprets the user's language. The backend decides whether the structured records are compatible.
This separation keeps financial and inventory decisions understandable and testable.

4.Offers and inventory consistency

After finding a potential match, a buyer can submit an offer for a chosen quantity and price.The seller then decides whether to accept it.An accepted offer becomes a deal. The backend is designed to validate inventory availability at acceptance time and reserve stock transactionally, avoiding duplicate allocation of the same units.
For a marketplace, this is especially important: a product may attract multiple buyers at the same time.

5.Simulating the revenue model

SurplusLink is intended to generate revenue through transaction fees rather than monthly subscriptions.
The proposed fee model is:

2% buyer service fee
2% seller commission For example, consider a wholesale deal for 150 biscuit packs at Rs. 120 each.
Financial breakdown
Amount
Transaction subtotal
Rs. 18,000
Buyer fee (2%)
Rs. 360
Buyer pays
Rs. 18,360
Seller fee (2%
Rs. 360
Seller receives
Rs. 17,640
Platform gross fees
Rs. 720

This is an illustrative business scenario. It is not real income, and the prototype does not process real financial transactions.

Why Does Open Innovation Matter?

Open-weight AI made this project practical to explore without training an entire language model from scratch.
For a small marketplace product, the valuable part is not necessarily building the largest model. It is applying an existing model to a specific problem and combining its output with reliable software engineering.

The benefits of this approach include:

Model flexibility:

The AI integration can be isolated behind a provider interface, making it easier to experiment with alternative compatible models.

Lower infrastructure requirements:

Hosted inference allows development without maintaining a dedicated local GPU or running large model weights.

More control over business logic:

AI assists with interpretation, while validated schemas, SQL queries and transaction rules determine what the system actually does.

A path toward specialization:

In the future, a model could be evaluated or fine-tuned for local wholesale inventory descriptions, including Urdu-English terminology and product abbreviations.
Using an open-weight model does not automatically make an application private, offline or free to operate. Hosted inference still has provider costs and data-handling considerations, which would need to be evaluated before onboarding real businesses.

My Agent Session

During the development of SurplusLink AI, I used OpenAI Codex as an AI-assisted development tool.
Codex helped accelerate the implementation of FastAPI endpoints, PostgreSQL database models, Alembic migrations, AI inference integration, and frontend connectivity.
My approach was to define the marketplace architecture, business workflows, and technical requirements first, then use Codex to implement and refine individual components.
This allowed me to focus on understanding backend architecture, inventory management, transaction handling, and the integration of open-weight AI into a practical business application.

Closing Thoughts

SurplusLink AI explores a straightforward idea:
Excess inventory for one business could become a useful purchasing opportunity for another.
By combining open-weight AI for natural-language understanding with conventional marketplace architecture, I wanted to build something that has a plausible path from hackathon prototype to a practical side hustle.
Thanks to the Hacktoberfest and DEV Community organizers for creating this opportunity to experiment with open-source AI.
I'd love feedback on the idea, especially from developers building B2B marketplaces or AI-powered tools for small businesses.

How is R2 used for object storage?

tabban Ghani — Wed, 30 Sep 2026 07:48:55 +0000

Modern applications often need to store profile pictures, PDFs, documents, videos, and other media. Instead of storing these files directly in a database, we can use object storage.

Let's understand the complete flow with a simple example: uploading a profile picture.

R2 and the Database

Suppose a user wants to upload:

profile-image.png

We separate the actual file from its application metadata:

DATABASE                         CLOUDFLARE R2
────────                         ─────────────
userId                           Actual image
fileKey  ──────────────────────> users/123/profile/abc.png
fileName
mimeType
fileSize

The actual image is stored in R2, while our database stores information needed to reference and manage it.

How Does the Upload Work?

The basic architecture is:

Frontend
   │
   │ 1. Request upload
   ▼
Backend
   │
   │ 2. Validate file information
   │ 3. Generate unique fileKey
   │ 4. Generate Presigned PUT URL
   ▼
Frontend
   │
   │ 5. PUT actual file
   ▼
Cloudflare R2
   │
   ▼
Object Stored

1. Frontend requests an upload

The frontend first sends information about the selected file:

POST /media/upload-url

{
  "fileName": "profile-image.png",
  "mimeType": "image/png",
  "fileSize": 245760
}

At this point, the actual image has not been uploaded.

2. Backend validates and generates a file key

The backend validates information such as the allowed file type and size.

It then generates a unique object key:

users/123/profile/550e8400.png

This fileKey identifies where the object will be stored inside the R2 bucket.

3. Backend generates a Presigned PUT URL

Using server-side R2 credentials, the backend generates a temporary presigned PUT URL for that specific object key.

For example:

{
  "fileKey": "users/123/profile/550e8400.png",
  "uploadUrl": "<presigned-url>",
  "expiresIn": 600
}

Conceptually, the URL provides temporary permission for:

Operation → PUT
Object    → users/123/profile/550e8400.png
Expiry    → 10 minutes

The R2 credentials remain securely on the backend.

4. Frontend uploads directly to R2

The frontend now sends the actual image using the presigned URL:

PUT <presigned-url>
Content-Type: image/png

<actual image bytes>

The important architecture is:

Frontend ───── actual file ─────> R2

The large file doesn't need to travel through the application backend in this direct-upload design.

R2 validates the signed request and stores the object under the key used to create the URL.

5. Store the reference

After a successful upload, the application can save or finalize the metadata:

userId:    123
fileKey:   users/123/profile/550e8400.png
fileName:  profile-image.png
mimeType:  image/png
fileSize:  245760

A more robust application can also call something like:

POST /media/complete

after the R2 upload succeeds, allowing the backend to verify/finalize the uploaded media.

What Happens When the Presigned URL Expires?

Suppose the URL is valid for 10 minutes.

After 10 minutes:

Presigned URL       ❌ Expired
Uploaded R2 object  ✅ Still exists

The permission is temporary, not the stored object.

Final Flow

The entire upload process can be remembered as:

Select File
    ↓
POST metadata → Backend
    ↓
Validate
    ↓
Generate File Key
    ↓
Generate Presigned PUT URL
    ↓
Return URL + File Key
    ↓
Frontend PUT → R2
    ↓
Actual File Stored
    ↓
Store / Finalize Metadata

The core idea is simple:

The backend controls the upload, the presigned URL provides temporary permission, the frontend uploads directly to R2, R2 stores the actual file, and the database stores its reference.