arbit/plan.md

Plan: Thrift Resale Dashboard

Build a greenfield internal dashboard for a 3-person reselling workflow, optimized for fast item intake, flexible templates, searchable inventory, and profit visibility. Recommended default stack for implementation is a Python-first web app, ideally Django + PostgreSQL + server-rendered forms with a small amount of HTMX for fast interactions. That fits the user's readability preference, keeps auth/data modeling simple, and reduces complexity for an internal tool.

Steps

1. Define the domain model and workflow boundaries first: items, templates, users, status history, sold listings, pricing estimates, and profit calculation rules. Capture the minimum viable lifecycle from acquisition to sale so implementation does not drift into marketplace-management scope.
2. Scaffold the app foundation: authentication, database, local dev setup, environment config, and a simple layout shell for the dashboard. Use built-in auth patterns where possible so user attribution is straightforward from the start.
3. Build item intake and templates: create editable item templates for common thrifting categories, allow one-click creation from templates, and make properties customizable per template so the team can adapt as buying patterns change.
4. Build inventory views and filters: implement item search across multiple fields and filters such as category, status, owner, acquisition date, price range, estimated value, and sale channel. Prioritize fast filtering and low-friction navigation over complex reporting.
5. Build pricing and profit estimation: support manual resale price suggestions at first, then integrate an external sold-comps source as a pluggable service. Cache retrieved comps, show the source and date, and always allow manual override when the estimate is wrong or unavailable.
6. Add sales tracking and profitability: track sold price, fees, shipping, net profit, time-to-sell, and item-level margin. Make it easy to mark items as sold and associate them with the person who added them.
7. Add operational quality-of-life features that fit the internal scope: photo uploads, quick notes, condition grading, bulk status updates, and a simple dashboard summary for inventory value, sales velocity, and profit by user/category.
8. Write the supporting markdown docs for future code agents and maintainers: architecture overview, data model, workflow notes, pricing integration notes, and an implementation checklist so later agents can work without re-discovering decisions.
9. Verify each slice with focused tests and a small end-to-end pass: auth, item/template CRUD, filtering, profit math, and pricing suggestion fallback behavior. Keep manual review focused on usability from intake to sale.

Relevant files

• docs/architecture.md - stack choice, system boundaries, and major components.
• docs/domain-model.md - entities, relationships, and lifecycle states.
• docs/workflows.md - intake, templating, selling, and edit flows.
• docs/pricing.md - comp sourcing, caching, overrides, and fallback rules.
• docs/agent-guide.md - conventions and instructions for future code agents.
• app/ or equivalent project root - implementation of auth, inventory, search, and reporting once the repo is scaffolded.

Verification

1. Confirm the initial schema supports the full item lifecycle without migrations that force redesign.
2. Validate that a new item can be created from a template in a small number of steps.
3. Validate multi-filter search returns expected results and stays responsive on realistic inventory sizes.
4. Validate pricing suggestions fall back cleanly when external comps are unavailable and never block item entry.
5. Validate profit calculations against known sample sales and ensure item attribution always shows the creator.

Decisions

• Scope is internal-only for a 3-person company; prioritize usability and speed of entry over permissions complexity.
• Use simple email/password auth for the first release; no role-based permission system unless a later need appears.
• Marketplace pricing should be advisory, not blocking, with manual overrides always available.
• Start with a Python/Django-style implementation unless you decide to force a different stack later.
• Keep public marketplace posting automation out of the first phase; the first version is about inventory, pricing, and profitability tracking.

Further Considerations

1. If you want the plan to assume a different stack than Django/PostgreSQL, tell me before implementation and I will revise the architecture section.
2. If you want eBay sold-comps integration to be authoritative rather than advisory, the plan should add API credential, caching, and failure-handling requirements up front.
3. If you expect to manage many item photos or barcode scans, the plan should add storage and capture workflow details now rather than later.