FlipPrice: An Open-Source Pricing Copilot for Vintage Resellers

FlipPrice compresses vintage resale pricing into snap-a-photo listing drafts and net income using local open-source models.
FlipPrice is an MIT-licensed open-source pricing tool for vintage resellers listing 20-50 items weekly. Users submit a photo and item details to get a listing draft, fair price range, and net proceeds after fees. It uses local Gemma 3 via Ollama for descriptions, TabPFN with Ridge fallback for pricing, and avoids RandomForest due to small-sample monotonicity failures. The author argues open source is essential because closed APIs at 5-15 cents per call destroy margins, while local weights cost nearly nothing and keep data private. Only simulated self-tests exist so far, all showing positive profit, but real-reseller validation and stronger generation quality remain open questions.
The Hidden Pain Point for Resellers: Hard to Price, Heavy on Fees
For small and mid-sized sellers listing 20 to 50 vintage items per week, the most time-consuming step is often not photographing or writing descriptions — it's pricing. Price too high and inventory sits; price too low and you're working for nothing. On top of that, you have to calculate platform commissions, shipping, and actual take-home pay. FlipPrice tries to compress this entire workflow into one motion: "snap a photo, fill in a few fields, get a listing draft and net income."
This is an open-source project (MIT license), positioned as a "side-hustle pricing copilot," with code hosted on GitHub: https://github.com/firfircelik/flipprice

From One Photo to a Listing Draft
FlipPrice's input is straightforward: take a photo of the item, then fill in the name, brand, category, condition, era, and purchase cost. If the seller is willing to upload their own sold-history CSV, the system can also fine-tune estimates for specific categories.
The output comes in three parts:
- Listing draft: generated by a local open-weights model, with the title starting with the brand
- Fair price range: inferred from sold comparable data
- Net take-home amount: actual income after platform fees are deducted
There's also a profit dashboard for an overview. The target users are resellers listing 20 to 50 items per week who want to save 10 minutes per item.
What is TabPFN: TabPFN (Tabular Prior-data Fitted Network) is a Transformer model designed specifically for small-scale tabular data. It was originally proposed by researchers to perform classification and regression directly on datasets of a few hundred rows or fewer, without traditional training iterations. By pretraining on a large number of synthetic tabular tasks, it bakes the ability to "infer functional relationships from a few samples" into its weights; at inference time, the training set is fed in as context in a single pass to produce predictions. For resale pricing — a classic small-sample, multi-field scenario (condition, era, brand, purchase cost) — TabPFN is often more stable than random forests or gradient boosting, because it won't overfit to a curve that defies common sense on very few samples. The trade-off is that it requires a one-time license and token, making it a type of "model weights are available but not entirely unconditionally free."
Tech Stack: Local Inference + Dual-Engine Pricing
Verified on Apple M2 with Python 3.14. The installation process is: clone the repo, create a venv, pip install, ollama pull gemma3:1b, and start uvicorn. The README also provides a one-click Render deploy button.
Description generation uses Gemma 3 (via Ollama), with constrained prompts and titles that prioritize the brand. There's also a local fallback chain, so it can run offline too.
Pricing uses TabPFN first, with Ridge as a fallback. Interestingly, the author tried RandomForest but abandoned it because it failed monotonicity on a small 20-row CSV. Sellers can upload their own CSV, and the system will validate it. Note that TabPFN 9 requires a one-time license plus token; after that, the same codebase can switch engines.
The repo has 7 tests, all passing, organized by user journey: marketplace flow, offline mode, malicious input, photo attachment, and live model testing.
Why RandomForest fails monotonicity on small samples: Monotonicity refers to directional constraints like "better condition and stronger brand should not lead to a lower estimate." A random forest votes or averages across many decision trees. When there are only about twenty training rows, each tree's split points can easily be dominated by individual noisy samples, creating anomalous step patterns in some regions of feature space — for example, "moving condition from 9/10 to like-new actually lowers the predicted price." Such models have no built-in monotonic constraint, and the problem gets worse with fewer samples. Ridge regression is a linear model and is naturally monotonic in its features (when coefficients are positive), making it more predictable as a fallback; TabPFN, meanwhile, gets closer to a smooth functional shape on small samples through its pretrained prior, so it can still maintain reasonable directionality with limited data.
Why "Open Source" Is the Economic Prerequisite for This Approach
The author lays out the core reason clearly: closed-source APIs charge 5 to 15 cents per call. At 50 calls per week, profits get eaten directly. Local open weights cost close to nothing, work offline, and keep data on the device.
TabPFN can also learn from the seller's own history. For a vintage resale business that already runs on thin margins and low unit prices, this difference in unit economics is decisive.
What unit economics means in a side-hustle context: Unit economics refers to the ratio of revenue to marginal cost for each completed transaction. For vintage sellers listing 20 to 50 items per week, per-item gross margin is already low. Assuming each listing requires three to five closed-source API calls to generate the title, description, and estimate, at 5 to 15 cents each, weekly AI costs could reach several dollars — hundreds of dollars a year, equivalent to eating the profit on several items. Local open weights push this marginal cost down to nearly zero (only electricity and device depreciation), and it doesn't scale linearly with listing volume. More importantly, the data stays on the local machine, so the seller's sold history and cost structure don't leak out — a competitive asset for small sellers who rely on sourcing differentiation.
Test Samples and What Still Needs Validation
The author candidly admits that there are no external real users yet, so self-testing was done under a "simulated seller" identity, with three representative findings all estimated live using Gemma 3:
- Canon AE-1 film camera, bought for 60, p50 estimate 286.34, net 189.12
- Levis 501 like-new, bought for 15, p50 108.85, net 79.70
- Sony WH-1000XM3, bought for 40, p50 116.82, net 61.63
Every listing title provided starts with the brand, and every profit margin is positive. The full log is in the repo's FIRST_USER_TEST.md.
The author explicitly says the next step is to find real resellers to test with. This is worth noting — self-testing can prove the pipeline runs, but it cannot prove whether the pricing is accurate in a real market.
The gap between self-testing and real-market validation: Self-testing under a "simulated seller" identity essentially verifies whether the system pipeline works end to end — whether photos can be parsed, fields can enter the model, fees can be deducted correctly, and the output format is consistent. What it cannot verify is price accuracy, because actual transaction prices are affected by external factors such as seasonality, platform traffic, buyer negotiation, image quality, and shipping speed. The p50 estimates for the three items in the article only show that the model's numbers fall within a reasonable range and that profit is positive; they do not mean the item could actually sell at that price on eBay or Depop. To judge whether the estimates are usable, you'd need to backtest against real sellers' historical transaction data, or have real users list items and compare expected prices against actual sale prices.
Is This Kind of Tool Worth Watching?
For vintage resellers, FlipPrice's value isn't that "AI writes your copy" — it's that it connects pricing, fees, and net income into one chain, and because it's open source with local inference, the marginal cost is nearly zero.
It also has clear limitations: the default Gemma 3 is a 1B small model, so generation quality is limited; TabPFN's paid threshold is a breaking point for purely free users; and without real user data, estimation accuracy remains a question mark.
But as a Hacktoberfest side-project challenge submission, it frames the question clearly enough: can open source make resale pricing tools economically viable on unit economics?
One-line Summary
FlipPrice uses local open-source models to compress vintage resale pricing into a snap-a-photo flow that produces a listing draft and net income.
Paragraph Summary
FlipPrice is an MIT-licensed open-source side-hustle pricing tool aimed at small and mid-sized vintage sellers listing 20 to 50 items per week. Users take a product photo and enter the name, brand, category, condition, era, and purchase cost, and the system outputs a listing draft, a fair price range, and the net take-home amount after platform fees. Technically, description generation uses Gemma 3 running locally via Ollama, pricing is primarily TabPFN with Ridge as a fallback, and RandomForest was abandoned due to monotonicity failures on small samples. The author emphasizes that the core reason for open source is unit economics: closed-source APIs cost 5 to 15 cents each, while local weights cost nearly nothing and keep data from leaking. Currently there are only three self-tested samples from a simulated seller, all showing positive profit, but no real reseller has validated pricing accuracy, and the default 1B small model also limits generation quality.
Related articles

ChatGPT Space Launches: Team Collaboration and New Pages Features Explained
ChatGPT Space is OpenAI's new team collaboration feature with Pages, real-time collaboration, and Slack/Google Drive sync. We break down its privacy design, multi-platform integration, and the full workflow from conversation to document.

Migrating Apache Spark UDFs to GPU Acceleration with AI Agents
NVIDIA developer blog explains how AI Agents rewrite Apache Spark UDFs for GPU acceleration, covering migration criteria, agent rewriting and verification workflows, plus pitfalls like result consistency and CPU-GPU transfer overhead.

Zed Editor v0.40.4-rc2 Released: Usage Credits Now Available Without Upgrading
Zed editor releases v0.40.4-rc2, allowing users to use usage credits for AI features without upgrading to a paid plan, lowering the trial barrier.