FlipPrice

Can Open Models Price Second-Hand Goods Well Enough for Resellers?

Week 2 · Side Hustle Project Report

Repository: https://github.com/firfircelik/flipprice

Can an open-model stack turn a second-hand item into a usable listing, a price estimate, and estimated net proceeds — without relying on paid, per-request AI APIs?

That is the question behind FlipPrice, a lightweight pricing and listing assistant for vintage resellers and second-hand sellers.

The idea is simple: researching comparable sold items takes time, while per-listing AI fees accumulate. FlipPrice explores a local-first alternative that separates listing generation from price estimation.

1. The Problem

Resellers listing 20–50 items a week face two recurring challenges:

• Pricing uncertainty: researching comparable sold items takes time, and asking prices do not necessarily reflect realised sale prices.
• Accumulating AI costs: at an illustrative $0.05–$0.15 per listing, API costs can add up before a product sells.

Estimates use 52 weeks divided by 12 months. Actual costs depend on provider pricing and token usage.

The goal: generate a listing draft, estimate a selling price, and calculate expected net proceeds at near-zero marginal model-inference cost.

2. Architecture

FlipPrice uses a lightweight FastAPI service and separates language generation from numerical price estimation.

Listing generation: Gemma 3 + Ollama

Gemma 3 runs locally through Ollama and generates listing copy from a constrained prompt. Output stripping and a brand-first title rule help reduce unwanted preambles and improve consistency.

Pricing: Ridge with an optional TabPFN path

• Ridge regression: the implemented fallback pricing path, using target-encoded features.
• TabPFN: an optional tabular-model path. The code is implemented, but live verification is pending because the required license token is unavailable.
• Training data: a 20-row seed dataset, currently suitable for early development rather than proving market-wide pricing accuracy.

The separation is intentional: a language model can write convincing copy without knowing the correct market price.

API, storage, and validation

• FastAPI for the application layer.
• Local JSON storage, with MongoDB Atlas as a possible upgrade.
• Condition validation through an enum.
• Non-negative cost validation.
• Photo uploads capped at 2 MB.

These are baseline application safeguards, not a complete production security assessment.

3. Initial Results

Three example items were processed through the prototype using live Gemma 3 on an Apple M2 machine.

These are recorded prototype outputs, not independently verified market values or guaranteed resale outcomes.

The experiment shows that the workflow can produce item-specific estimates. It does not yet demonstrate pricing accuracy. That requires independent sold-price data, a held-out test set, and explicit error metrics.

4. Latency

These are initial development-environment measurements. The number of repetitions, percentile distribution, and complete test procedure still need to be standardised.

The main observation is the difference between cold and warm pricing. Reusing loaded components and avoiding unnecessary initialisation appear to be important optimisation opportunities.

5. Debugging Notes

Random Forest inverted the expected condition relationship

With only 20 training rows, Random Forest returned:

• like_new: 97.51
• fair: 103.36

The model assigned a higher estimate to the fair-condition example. This exposed a weakness in the current model and dataset, not proof that Random Forest is inherently unsuitable for resale pricing.

Change: Ridge regression replaced the fallback model, producing a cleaner gradient in the tested examples. A regression test now guards against this specific failure.

TabPFN cold-start overhead

The TabPFN import path added approximately 15 seconds of cold-start overhead without a license token.

Change: The path was gated on token availability, reducing the observed cold-path time from approximately 17 seconds to 5 seconds in the measured setup. Live TabPFN pricing remains unverified.

Unwanted title preambles

Small models sometimes added introductory text to generated titles.

Change: Output stripping and a brand-first title rule improved consistency.

Tests

The automated suite reports 8/8 passing tests. This supports basic functional correctness but does not establish pricing accuracy or production readiness.

6. Unit Economics

Local inference removes the separate hosted-model inference fee for each listing, but it does not make the system completely free to operate.

Costs still include hardware, electricity, maintenance, storage, development, and any external services.

The business case therefore depends on two questions:

1. Can local inference reduce the marginal cost of preparing listings?
2. Can the price estimates improve reseller decisions enough to justify adoption?

The architecture supports the first hypothesis. The second remains unvalidated.

7. Limitations

• Small dataset: 20 rows cannot adequately represent the diversity of second-hand markets.
• No independent accuracy benchmark: MAE, median absolute error, category-level errors, and interval coverage have not yet been reported.
• TabPFN is not live-verified: its code path exists, but the required license token is unavailable.
• No external users: results are agent-run dogfooding simulations documented in FIRST_USER_TEST.md.
• Offline operation needs broader verification: the complete workflow must be tested with network access disabled.
• Commercial value is unproven: time saved, realised sale prices, and willingness to pay have not been measured.

8. What Comes Next?

1. Benchmark pricing accuracy

Build a representative dataset of completed sales and evaluate against a held-out test set. Report MAE, median absolute error, suitable percentage-error metrics, and performance by category and condition. Compare against simple baselines such as category medians.

Prevent duplicate and near-duplicate listings from leaking across training and evaluation.

2. Run a real reseller pilot

Recruit a small group of second-hand sellers and measure listing preparation time, draft acceptance, agreement with suggested prices, eventual sale prices, and willingness to pay.

3. Standardise performance tests

Document hardware, model configuration, repetition counts, and latency percentiles. Test offline operation with external network access disabled.

4. Validate TabPFN

If access becomes available, compare TabPFN, Ridge, and simple baselines on the same held-out dataset. Keep the fallback until the alternative is verified.

5. Test willingness to pay

Once pricing quality and time savings are demonstrated, test a simple commercial offer. The important question is whether the value delivered exceeds the cost and uncertainty of the seller's existing process.

9. Conclusion

FlipPrice demonstrates a local-first prototype that combines open-model listing generation with a separate tabular pricing layer.

The initial run produced listing drafts and item-specific price and net-proceeds estimates. Warm pricing latency reached 9 ms in the measured setup, and all eight automated tests passed.

These results support the feasibility of the implementation. They do not yet prove reliable market-price prediction or commercial demand.

The next milestone is evidence: validate estimates against real completed sales and test the workflow with actual resellers.

If FlipPrice can consistently save time and produce estimates sellers trust, its local-first architecture could provide a meaningful cost advantage. If it cannot, low inference cost alone will not make it a viable product.

That is what the next iteration needs to answer.

---

Project: FlipPrice on GitHub · License: MIT

FlipPrice is an experimental project. Estimates are informational and are not guaranteed resale values.