makiolaj/GearBox
1
0
Fork 0
Code Issues 8 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

docs: complete project research

Browse Source
This commit is contained in:
Jean-Luc Makiola
2026-03-16 11:39:16 +01:00
parent 1324018989
commit 79457053b3
5 changed files with 1273 additions and 889 deletions
Download Patch File Download Diff File Expand all files Collapse all files

381
.planning/research/FEATURES.md
View File

@@ -1,201 +1,244 @@
# Feature Research
# Feature Research: v1.2 Collection Power-Ups
**Domain:** Gear management and purchase planning (personal inventory + research workflow)
**Researched:** 2026-03-14
**Domain:** Gear management -- search/filter, weight classification, weight visualization, candidate status tracking, weight unit selection
**Researched:** 2026-03-16
**Confidence:** HIGH
**Scope:** New features only. v1.0/v1.1 features (item CRUD, categories, threads, setups, dashboard, onboarding, images, icons) are already shipped.
## Feature Landscape
## Table Stakes
### Table Stakes (Users Expect These)
Features that gear management users expect. Missing these makes the app feel incomplete for collections beyond ~20 items.
Features users assume exist. Missing these = product feels incomplete.
| Feature | Why Expected | Complexity | Dependencies on Existing |
|---------|--------------|------------|--------------------------|
| Search items by name | Every competitor with an inventory concept has search. Hikt highlights "searchable digital closet." PackLight Supporter Edition has inventory search. Once a collection exceeds 30 items, scrolling to find something is painful. LighterPack notably lacks this and users complain. | LOW | Items query (`useItems`), collection view. Client-side only -- no API changes needed for <500 items. |
| Filter items by category | Already partially exists in Planning view (category dropdown for threads). Collection view groups by category visually but has no filter. Users need to quickly narrow to "show me just my shelter items." | LOW | Categories query (`useCategories`), collection view. Client-side filtering of already-fetched items. |
| Weight unit selection (g, oz, lb, kg) | Universal across all competitors. LighterPack supports toggling between g/oz/lb/kg. Packrat offers per-item input in any unit with display conversion. Backpacking Light forum users specifically praise apps that let you "enter item weights in grams and switch the entire display to lbs & oz." Gear specs come in mixed units -- a sleeping bag in lbs/oz, a fuel canister in grams. | LOW | `formatWeight()` in `lib/formatters.ts`, `settings` table (already exists with key/value store), TotalsBar, ItemCard, CandidateCard, SetupCard -- every weight display. |
| Weight classification (base/worn/consumable) | LighterPack pioneered this three-way split and it is now universal. Hikt, PackLight, Packstack, HikeLite, 99Boulders spreadsheet -- all support it. "Base weight" is the core metric of the ultralight community. Without classification, weight totals are a single number with no actionable insight. | MEDIUM | `setup_items` join table (needs new column), setup detail view, setup service, totals computation. Schema migration required. |
| Feature | Why Expected | Complexity | Notes |
|---------|--------------|------------|-------|
| Item CRUD with core fields (name, weight, price, category) | Every gear app and spreadsheet has this. It is the minimum unit of value. | LOW | Weight and price are the two fields users care about most. Category groups items visually. |
| Weight unit support (g, oz, lb, kg) | Gear communities are split between metric and imperial. LighterPack, GearGrams, Hikt all support multi-unit. | LOW | Store in grams internally, display in user-preferred unit. Conversion is trivial. |
| Automatic weight/cost totals | Spreadsheets do this. Every competitor does this. Manual math = why bother with an app. | LOW | Sum by category, by setup, by collection. Real-time recalculation on any change. |
| Categories/grouping | LighterPack, GearGrams, Packstack all organize by category (shelter, sleep, cook, clothing, etc.). Without grouping, lists become unreadable past 20 items. | LOW | User-defined categories. Suggest defaults but allow custom. |
| Named setups / packing lists | LighterPack has lists, GearGrams has lists, Packstack has trips, Hikt has packing lists. Composing subsets of your gear into purpose-specific loadouts is universal. | MEDIUM | Items belong to collection; setups reference items from collection. Many-to-many relationship. |
| Setup weight/cost breakdown | Every competitor shows base weight, worn weight, consumable weight as separate totals. Pie charts or percentage breakdowns by category are standard (LighterPack pioneered this). | MEDIUM | Weight classification (base/worn/consumable) per item per setup. Visual breakdown is expected. |
| Notes/description per item | Spreadsheet users write notes. Every competitor supports free text on items. Useful for fit notes, durability observations, model year specifics. | LOW | Plain text field. No rich text needed for v1. |
| Product links / URLs | Users track where they found or bought items. Spreadsheets always have a "link" column. | LOW | Single URL field per item. |
| Photos per item | Hikt, GearCloset, and Packrat all support item photos. Visual identification matters -- many gear items look similar in text. | MEDIUM | Image upload and storage. Start with one photo per item; multi-photo is a differentiator. |
| Search and filter | Once a collection exceeds 30-40 items, finding things without search is painful. Hikt highlights "searchable digital closet." | LOW | Filter by category, search by name. Basic but essential. |
| Import from CSV | GearGrams, HikeLite, HikerHerd, Packrat all support CSV import. Users migrating from spreadsheets (GearBox's primary audience) need this. | MEDIUM | Define a simple CSV schema. Map columns to fields. Handle unit conversion on import. |
| Export to CSV | Companion to import. Users want data portability and backup ability. | LOW | Straightforward serialization of collection data. |
## Differentiators
### Differentiators (Competitive Advantage)
Features that set GearBox apart or add meaningful value beyond what competitors offer.
Features that set the product apart. Not required, but valuable.
| Feature | Value Proposition | Complexity | Dependencies on Existing |
|---------|-------------------|------------|--------------------------|
| Weight distribution visualization (donut/pie chart) | LighterPack's pie chart is iconic and widely cited as its best feature. "The pie chart at the top is a great way to visualize how your pack weight breaks down by category." PackLight uses bar graphs. GearBox can do this per-setup with a modern donut chart that also shows base/worn/consumable breakdown -- a combination no competitor offers cleanly. | MEDIUM | Totals data (already computed server-side per category), weight classification (new), a chart library (react-minimal-pie-chart at 2kB or Recharts). |
| Candidate status tracking (researching/ordered/arrived) | No competitor has this. Research confirmed: the specific workflow of tracking purchase status through stages does not exist in any gear management app. This is unique to GearBox's planning thread concept. It makes threads a living document of the purchase lifecycle, not just a comparison tool. | LOW | `thread_candidates` table (needs new `status` column), CandidateCard, CandidateForm. Simple text field migration. |
| Planning category filter with icon-aware dropdown | Already partially built as a plain `<select>` in PlanningView. Upgrading to show Lucide icons alongside category names makes filtering feel polished and consistent with the icon picker UX. | LOW | Existing CategoryPicker component pattern, existing category filter state in PlanningView. |
| Weight classification shown per-setup (not global) | In LighterPack, worn/consumable flags are per-item within a list. In GearBox, items exist in a global collection and appear in multiple setups. The same jacket might be "worn" in a summer bikepacking setup but "base weight" (packed in panniers) in a winter setup. Classification belongs on the setup_items join, not on the item itself. This is architecturally superior to competitors. | MEDIUM | `setup_items` table schema, setup sync endpoint, setup detail UI. |
| Feature | Value Proposition | Complexity | Notes |
|---------|-------------------|------------|-------|
| Purchase planning threads | No competitor has this. LighterPack, GearGrams, Packstack, Hikt are all post-purchase tools. GearBox's core value is the pre-purchase research workflow: create a thread, add candidates, compare, decide, then move the winner to your collection. This is the single biggest differentiator. | HIGH | Thread model with candidate items, status tracking, resolution workflow. This is the app's reason to exist. |
| Impact preview ("how does this affect my setup?") | No competitor shows how a potential purchase changes your overall setup weight/cost. Users currently do this math manually in spreadsheets. Seeing "+120g to base weight, +$85 to total cost" before buying is uniquely valuable. | MEDIUM | Requires linking threads to setups. Calculate delta between current item (if replacing) and candidate. |
| Thread resolution workflow | The lifecycle of "researching -> ordered -> arrived -> in collection" does not exist in any competitor. Closing a thread and promoting the winner to your collection is a novel workflow that mirrors how people actually buy gear. | MEDIUM | Status state machine on thread items. Resolution action that creates/updates collection item. |
| Side-by-side candidate comparison | Wishlist apps let you save items. GearBox lets you compare candidates within a thread on the dimensions that matter (weight, price, notes). Similar to product comparison on retail sites, but for your specific context. | MEDIUM | Comparison view pulling from thread candidates. Highlight differences in weight/price. |
| Priority/ranking within threads | Mark favorites among candidates. Simple but no gear app does this because no gear app has a research/planning concept. | LOW | Numeric rank or star/favorite flag per candidate in a thread. |
| Multi-photo per item | Most competitors support zero or one photo. Multiple photos (product shots, detail shots, in-use shots) add real value for gear tracking. | MEDIUM | Gallery per item. Storage considerations. Defer to v1.x. |
| Weight distribution visualization | LighterPack's pie chart is iconic. A clean, modern version with interactive breakdowns by category adds polish. | MEDIUM | Chart component showing percentage of total weight by category. |
| Hobby-agnostic data model | Competitors are hiking/backpacking-specific. GearBox works for bikepacking, sim racing, photography, cycling, or any collection hobby. The data model uses generic "categories" rather than hardcoded "shelter/sleep/cook." | LOW | Architecture decision more than feature. No hiking-specific terminology baked into the model. |
## Anti-Features
### Anti-Features (Commonly Requested, Often Problematic)
Features to explicitly NOT build in this milestone.
Features that seem good but create problems.
| Anti-Feature | Why Avoid | What to Do Instead |
|--------------|-----------|-------------------|
| Per-item weight input in multiple units | Packrat lets you enter "2 lb 3 oz" per item. This adds parsing complexity, ambiguous storage, and conversion bugs. | Store grams internally (already done). Convert for display only. Users enter grams; if they want oz input, they convert mentally or we add a unit toggle on the input field later. |
| Interactive chart drill-down (click to zoom) | LighterPack lets you click pie slices to zoom into category breakdowns. Adds significant interaction complexity. | Static donut chart with hover tooltips. Drill-down is a future enhancement. |
| Weight goals / targets ("your target base weight is X") | Some apps show ultralight thresholds. Adds opinionated norms that conflict with hobby-agnostic design. | Show the numbers. Let users interpret them. |
| Custom weight classification labels | Beyond base/worn/consumable. Some users want "luxury" or "shared" categories. | Three classifications cover 95% of use cases. The notes field handles edge cases. |
| Server-side search / full-text search | SQLite FTS5 or similar. Premature for a single-user app with <1000 items. | Client-side filtering of the already-fetched items array. Simpler, faster for the expected data scale. |
| Worn/consumable at the global item level | Tempting to add a classification column to the `items` table. | Classification varies by setup context. A rain shell is "worn" on a day hike but "base weight" (packed) on a bike tour. The join table `setup_items` is the correct location. |
| Feature | Why Requested | Why Problematic | Alternative |
|---------|---------------|-----------------|-------------|
| Multi-user / social sharing | "Share my setup with friends," "collaborate on packing lists." Hikt Premium has real-time collaboration. | Adds auth, permissions, data isolation, and massive complexity to a single-user app. The PROJECT.md explicitly scopes this out. Premature for v1. | Export/share as read-only link or image in a future version. No auth needed. |
| Price tracking / deal alerts | Wishlist apps (Sortd, WishUpon) track price drops. Seems useful for purchase planning. | Requires scraping or API integrations with retailers. Fragile, maintenance-heavy, legally gray. Completely different product category. | Store the price you found manually. Link to the product page. Users can check prices themselves. |
| Barcode/product database scanning | Hikt has barcode scanning and product database lookup. Seems like it saves time. | Requires maintaining or licensing a product database. Outdoor gear barcodes are inconsistent. Mobile-first feature that does not fit a web-first app. | Manual entry is fine for a collection that grows by 1-5 items per month. Not a data-entry-heavy workflow. |
| Custom comparison parameters | "Let me define which fields to compare (warmth rating, denier, waterproof rating)." | Turns a simple app into a configurable schema builder. Massive complexity for marginal value. PROJECT.md lists this as out of scope for v1. | Use the notes field for specs. Fixed comparison on weight/price covers 80% of use cases. |
| Community gear database / shared catalog | "Browse what other people use," "copy someone's gear list." Hikt has community packing lists. | Requires moderation, data quality controls, user accounts, and content management. Completely different product. | Stay focused on personal inventory. Community features are a different app. |
| Mobile native app | PackLight and Hikt have iOS/Android apps. | Doubles or triples development effort. Web-first serves the use case (gear management is a desk activity, not a trailside activity). PROJECT.md scopes this out. | Responsive web design. Works on mobile browsers for quick lookups. |
| Real-time weather integration | Packstack integrates weather for trip planning. | Requires external API, ongoing costs, and is only relevant to outdoor-specific use cases. GearBox is hobby-agnostic. | Out of scope. Users check weather separately. |
| Automated "what to bring" recommendations | AI/rule-based suggestions based on trip conditions. | Requires domain knowledge per hobby, weather data, user preference modeling. Over-engineered for a personal tool. | Users build their own setups. They know their gear. |
## Feature Details
### 1. Search and Filter
**What users expect:** A text input that filters visible items by name as you type. A category dropdown or pill selector to filter by category. Both should work together (search within a category).
**Domain patterns observed:**
- Hikt: Searchable gear closet with category and specification filters
- PackLight: Inventory search (premium feature) with category organization
- Backpacking Light Calculator: Search filter in gear locker and within packs
- LighterPack: No text search -- widely considered a gap
**Recommended implementation:**
- Sticky search bar above the collection grid with a text input and category filter dropdown
- Client-side filtering using `Array.filter()` on the items array from `useItems()`
- Case-insensitive substring match on item name
- Category filter as pills or dropdown (reuse the pattern from PlanningView)
- URL search params for filter state (shareable filtered views, consistent with existing `?tab=` pattern)
- Clear filters button when any filter is active
- Result count displayed ("showing 12 of 47 items")
**Complexity:** LOW. Pure client-side. No API changes. ~100 lines of new component code plus minor state management.
### 2. Weight Classification (Base/Worn/Consumable)
**What users expect:** Every item in a setup can be marked as one of three types:
- **Base weight**: Items carried in the pack. The fixed weight of your loadout. This is the primary metric ultralight hikers optimize.
- **Worn weight**: Items on your body while hiking (shoes, primary clothing, watch, sunglasses). Not counted toward pack weight but tracked as part of "skin-out" weight.
- **Consumable weight**: Items that deplete during a trip (food, water, fuel, sunscreen). Variable weight not counted toward base weight.
**Domain patterns observed:**
- LighterPack: Per-item icons (shirt icon = worn, flame icon = consumable). Default = base weight. Totals show base/worn/consumable/total separately.
- Packstack: "Separates base weight, worn weight, and consumables so you always know exactly what your pack weighs."
- HikeLite: "Mark heavy clothing as worn to see your true base weight."
- 99Boulders spreadsheet: Column with dropdown: WORN / CONSUMABLE / - (dash = base).
**Critical design decision -- classification scope:**
In LighterPack, items only exist within lists, so the flag is per-item-per-list inherently. In GearBox, items live in a global collection and are referenced by setups. The classification MUST live on the `setup_items` join table, not on the `items` table. Reason: the same item can have different classifications in different setups (a puffy jacket is "worn" on a cold-weather hike but "base weight" in a three-season setup where it stays packed).
**Recommended implementation:**
- Add `classification TEXT NOT NULL DEFAULT 'base'` column to `setup_items` table
- Valid values: `"base"`, `"worn"`, `"consumable"`
- Default to `"base"` (most items are base weight; this matches user expectation)
- UI: Small segmented control or icon toggle on each item within the setup detail view
- LighterPack-style icons: backpack icon (base), shirt icon (worn), flame/droplet icon (consumable)
- Setup totals recalculated: show base weight, worn weight, consumable weight, and total (skin-out) as four separate numbers
- SQL aggregation update: `SUM(CASE WHEN classification = 'base' THEN weight_grams ELSE 0 END)` etc.
**Complexity:** MEDIUM. Requires schema migration, API changes (sync endpoint must accept classification), service layer updates, and UI for per-item classification within setup views.
### 3. Weight Distribution Visualization
**What users expect:** A chart showing where the weight is. By category is standard. By classification (base/worn/consumable) is a bonus.
**Domain patterns observed:**
- LighterPack: Color-coded pie chart by category, click to drill down. "As you enter each piece of equipment, a pie chart immediately displays a breakdown of where your weight is appropriated." Colors are customizable per category.
- PackLight: Bar graph comparing category weights
- OutPack: Category breakdown graph
**Two chart contexts:**
1. **Collection-level**: Weight by category across the whole collection. Uses existing `useTotals()` data.
2. **Setup-level**: Weight by category AND by classification within a specific setup. More useful because setups represent actual loadouts.
**Recommended implementation:**
- Donut chart (modern feel, consistent with GearBox's minimalist aesthetic)
- Library: `react-minimal-pie-chart` (2kB gzipped, zero dependencies, SVG-based) over Recharts (40kB+). GearBox only needs pie/donut -- no line charts, bar charts, etc.
- Setup detail view: Donut chart showing weight by category, with center text showing total base weight
- Optional toggle: switch between "by category" and "by classification" views
- Color assignment: Derive from category or classification type (base = neutral gray, worn = blue, consumable = amber)
- Hover tooltips showing category name, weight, and percentage
- Responsive: Chart should work on mobile viewports
**Complexity:** MEDIUM. New dependency, new component, integration with totals data. The chart itself is straightforward; the data aggregation for per-setup-per-category-per-classification is the main work.
### 4. Candidate Status Tracking
**What users expect:** This is novel -- no competitor has it. The workflow mirrors real purchase behavior:
1. **Researching** (default): You found this product, added it to a thread, and are evaluating it
2. **Ordered**: You decided to buy it and placed an order
3. **Arrived**: The product has been delivered. Ready for thread resolution.
**Why this matters:** Without status tracking, threads are a flat list of candidates. With it, threads become a living purchase tracker. A user can see at a glance "I ordered the Nemo Tensor, still researching two other pads."
**Recommended implementation:**
- Add `status TEXT NOT NULL DEFAULT 'researching'` column to `thread_candidates` table
- Valid values: `"researching"`, `"ordered"`, `"arrived"`
- UI: Status badge on CandidateCard (small colored pill, similar to existing weight/price badges)
- Color scheme: researching = gray/neutral, ordered = amber/yellow, arrived = green
- Status change: Dropdown or simple click-to-cycle on the candidate card
- Thread-level summary: Show count by status ("2 researching, 1 ordered")
- When resolving a thread, only candidates with status "arrived" should be selectable as winners (soft constraint -- show a warning, not a hard block, since users may resolve with a "researching" candidate they just bought in-store)
**Complexity:** LOW. Simple column addition, enum-like text field, badge rendering, optional status transition UI.
### 5. Weight Unit Selection
**What users expect:** Choose a preferred unit (grams, ounces, pounds, kilograms) and have ALL weight displays in the app use that unit. LighterPack toggles between g/oz/lb/kg at the top level. The BPL Calculator app lets you "enter item weights in grams and switch the entire display to lbs & oz."
**Domain patterns observed:**
- LighterPack: Toggle at list level between lb/oz/g/kg. Only changes summary display, not per-item display.
- Packrat: "Input items in different units, choose how they're displayed, and freely convert between them."
- BPL Calculator: Global settings change, applied to all displays
- WeighMyGear: Input locked to grams, less intuitive
**Recommended implementation:**
- Store preference in existing `settings` table as `{ key: "weightUnit", value: "g" }` (default: grams)
- Supported units: `g` (grams), `oz` (ounces), `lb` (pounds + ounces), `kg` (kilograms)
- Conversion constants: 1 oz = 28.3495g, 1 lb = 453.592g, 1 kg = 1000g
- Display format per unit:
- `g`: "450g" (round to integer)
- `oz`: "15.9 oz" (one decimal)
- `lb`: "2 lb 3 oz" (pounds + remainder ounces, traditional format)
- `kg`: "1.45 kg" (two decimals)
- Update `formatWeight()` to accept unit parameter or read from a React context/hook
- Settings UI: Simple dropdown or segmented control, accessible from a settings page or inline in the TotalsBar
- Internal storage stays as grams (already the case with `weight_grams` column)
- Affects: TotalsBar, ItemCard, CandidateCard, SetupCard, CategoryHeader, setup detail view, chart tooltips
**Complexity:** LOW. No schema changes. Update the `formatWeight()` function, add a settings hook, propagate the unit to all display points. The main effort is touching every component that displays weight (there are ~6-8 call sites).
### 6. Planning Category Filter with Icon-Aware Dropdown
**What users expect:** The existing category filter in PlanningView is a plain `<select>` without icons. Since categories now have Lucide icons (v1.1), the filter should show them.
**Recommended implementation:**
- Replace the native `<select>` with a custom dropdown component that renders `<LucideIcon>` alongside category names
- Match the visual style of the CategoryPicker used in thread creation
- Same functionality, better visual consistency
**Complexity:** LOW. UI-only change. Replace ~20 lines of `<select>` with a custom dropdown component.
## Feature Dependencies
```
[Item CRUD + Core Fields]
[Weight Unit Selection] --independent-- (affects all displays, no schema changes)
|
+--requires--> [Categories]
+-- should ship first (all other features benefit from correct unit display)
[Search & Filter] --independent-- (pure client-side, no schema changes)
|
+--enables---> [Named Setups / Packing Lists]
| |
| +--enables---> [Setup Weight/Cost Breakdown]
| |
| +--enables---> [Impact Preview] (also requires Planning Threads)
+-- no dependencies on other v1.2 features
[Candidate Status Tracking] --independent-- (schema change on thread_candidates only)
|
+--enables---> [Planning Threads]
|
+--enables---> [Candidate Comparison]
|
+--enables---> [Thread Resolution Workflow]
| |
| +--creates---> items in [Collection]
|
+--enables---> [Priority/Ranking]
|
+--enables---> [Status Tracking] (researching -> ordered -> arrived)
+-- no dependencies on other v1.2 features
[Search & Filter] --enhances--> [Item CRUD] (becomes essential at ~30+ items)
[Weight Classification] --depends-on--> [existing setup_items table]
|
+-- schema migration on setup_items
+-- enables [Weight Distribution Visualization]
[Import CSV] --populates--> [Item CRUD] (bootstrap for spreadsheet migrants)
[Weight Distribution Visualization] --depends-on--> [Weight Classification]
|
+-- needs classification data to show base/worn/consumable breakdown
+-- can show by-category chart without classification (partial value)
+-- new dependency: react-minimal-pie-chart
[Photos] --enhances--> [Item CRUD] (independent, can add anytime)
[Weight Unit Support] --enhances--> [All weight displays] (must be in from day one)
[Planning Category Filter Icons] --depends-on--> [existing CategoryPicker pattern]
|
+-- pure UI enhancement
```
### Dependency Notes
### Implementation Order Rationale
- **Named Setups require Item CRUD:** Setups are compositions of existing collection items. The collection must exist first.
- **Planning Threads require Item CRUD:** Thread candidates have the same data shape as collection items (weight, price, etc.). Reuse the item model.
- **Impact Preview requires both Setups and Threads:** You need a setup to compare against and a thread candidate to evaluate. This is a later-phase feature.
- **Thread Resolution creates Collection Items:** The resolution workflow bridges threads and collection. Both must be stable before resolution logic is built.
- **Import CSV populates Collection:** Import is a bootstrap feature for users migrating from spreadsheets. Should be available early but after the core item model is solid.
1. **Weight Unit Selection** first -- touches formatting everywhere, foundational for all subsequent weight displays
2. **Search & Filter** second -- standalone, immediately useful, low risk
3. **Candidate Status Tracking** third -- standalone schema change, simple
4. **Planning Category Filter** fourth -- quick UI polish
5. **Weight Classification** fifth -- most complex schema change, affects setup data model
6. **Weight Distribution Visualization** last -- depends on classification, needs chart library, highest UI complexity
## MVP Definition
## Complexity Summary
### Launch With (v1)
Minimum viable product -- what is needed to validate the concept and replace a spreadsheet.
- [ ] Item CRUD with weight, price, category, notes, product link -- the core inventory
- [ ] User-defined categories -- organize items meaningfully
- [ ] Weight unit support (g, oz, lb, kg) -- non-negotiable for gear community
- [ ] Automatic weight/cost totals by category and overall -- the reason to use an app over a text file
- [ ] Named setups with item selection and totals -- compose loadouts from your collection
- [ ] Planning threads with candidate items -- the core differentiator, add candidates you are researching
- [ ] Side-by-side candidate comparison on weight/price -- the payoff of the thread concept
- [ ] Thread resolution (pick a winner, move to collection) -- close the loop
- [ ] Dashboard home page -- clean entry point per PROJECT.md constraints
- [ ] Search and filter on collection -- usability at scale
### Add After Validation (v1.x)
Features to add once core is working and the planning thread workflow is proven.
- [ ] Impact preview ("this candidate adds +120g to your Summer Bikepacking setup") -- requires setups + threads to be stable
- [ ] Status tracking on thread items (researching / ordered / arrived) -- lifecycle tracking
- [ ] Priority/ranking within threads -- mark favorites among candidates
- [ ] Photos per item -- visual identification, one photo per item initially
- [ ] CSV import/export -- migration path from spreadsheets, data portability
- [ ] Weight distribution visualization (pie/bar chart by category) -- polish feature
### Future Consideration (v2+)
Features to defer until product-market fit is established.
- [ ] Multi-photo gallery per item -- storage and UI complexity
- [ ] Shareable read-only links for setups -- lightweight sharing without auth
- [ ] Drag-and-drop reordering in lists and setups -- UX refinement
- [ ] Bulk operations (multi-select, bulk categorize, bulk delete) -- power user feature
- [ ] Dark mode -- common request, low priority for initial launch
- [ ] Item history / changelog (track weight after modifications, price changes) -- advanced tracking
## Feature Prioritization Matrix
| Feature | User Value | Implementation Cost | Priority |
|---------|------------|---------------------|----------|
| Item CRUD with core fields | HIGH | LOW | P1 |
| Categories | HIGH | LOW | P1 |
| Weight unit support | HIGH | LOW | P1 |
| Auto weight/cost totals | HIGH | LOW | P1 |
| Named setups | HIGH | MEDIUM | P1 |
| Planning threads | HIGH | HIGH | P1 |
| Candidate comparison | HIGH | MEDIUM | P1 |
| Thread resolution | HIGH | MEDIUM | P1 |
| Dashboard home | MEDIUM | LOW | P1 |
| Search and filter | MEDIUM | LOW | P1 |
| Impact preview | HIGH | MEDIUM | P2 |
| Status tracking (threads) | MEDIUM | LOW | P2 |
| Priority/ranking (threads) | MEDIUM | LOW | P2 |
| Photos per item | MEDIUM | MEDIUM | P2 |
| CSV import/export | MEDIUM | MEDIUM | P2 |
| Weight visualization charts | MEDIUM | MEDIUM | P2 |
| Multi-photo gallery | LOW | MEDIUM | P3 |
| Shareable links | LOW | MEDIUM | P3 |
| Drag-and-drop reordering | LOW | MEDIUM | P3 |
| Bulk operations | LOW | MEDIUM | P3 |
**Priority key:**
- P1: Must have for launch
- P2: Should have, add when possible
- P3: Nice to have, future consideration
## Competitor Feature Analysis
| Feature | LighterPack | GearGrams | Packstack | Hikt | GearBox (Our Approach) |
|---------|-------------|-----------|-----------|------|------------------------|
| Gear inventory | Per-list only (no central closet) | Central library + lists | Full gear library | Full closet with search | Full collection as central source of truth |
| Weight tracking | Excellent -- base/worn/consumable splits, pie charts | Good -- multi-unit, category totals | Good -- base/worn/consumable | Excellent -- smart insights | Base/worn/consumable with unit flexibility |
| Packing lists / setups | Unlimited lists (web) | Multiple lists via drag-drop | Trip-based (2 free) | 3 free lists, more with premium | Named setups composed from collection |
| Purchase planning | None | None | None | None | Planning threads with candidates, comparison, resolution -- unique |
| Impact analysis | None | None | None | None | Show how a candidate changes setup weight/cost -- unique |
| Photos | None | None | None | Yes | Yes (v1.x) |
| Import/export | None (copy-linked lists only) | CSV import | None mentioned | LighterPack import, CSV | CSV import/export (v1.x) |
| Mobile | No native app (web only, poor mobile UX) | Web only | iOS only | iOS + Android + web | Web-first, responsive design |
| Sharing | Shareable links | None mentioned | Shareable trip links | Community lists, collaboration | Deferred (v2+, read-only links) |
| Hobby scope | Hiking/backpacking only | Hiking/backpacking only | Hiking/backpacking only | Hiking/backpacking only | Any hobby (bikepacking, sim racing, photography, etc.) |
| Pricing | Free | Free | Freemium (2 lists free) | Freemium (3 lists free) | Single-user, no tiers |
| Status | Open source, aging, no mobile | Maintained but dated | Active development | Actively developed, modern | New entrant with unique purchase planning angle |
| Feature | Schema Change | API Change | New Dependency | UI Scope | Overall |
|---------|---------------|------------|----------------|----------|---------|
| Search & Filter | None | None | None | Collection view only | LOW |
| Weight Unit Selection | None (uses settings) | None (settings API exists) | None | All weight displays (~8 components) | LOW |
| Candidate Status Tracking | `thread_candidates.status` column | Update candidate CRUD | None | CandidateCard, CandidateForm | LOW |
| Planning Category Filter | None | None | None | PlanningView dropdown | LOW |
| Weight Classification | `setup_items.classification` column | Update setup sync + detail endpoints | None | Setup detail view | MEDIUM |
| Weight Distribution Chart | None | Possibly new totals endpoint | react-minimal-pie-chart (~2kB) | New chart component | MEDIUM |
## Sources
- [LighterPack](https://lighterpack.com/) -- free web-based gear list tool, community standard
- [GearGrams](https://www.geargrams.com/) -- drag-and-drop gear library with multi-unit support
- [Packstack](https://www.packstack.io/) -- trip-centric gear management with weather integration
- [Hikt](https://hikt.app/) -- modern gear manager with mobile apps and community features
- [Hikt Blog: Best Backpacking Gear Apps 2026](https://hikt.app/blog/best-backpacking-gear-apps-2026/) -- competitive comparison
- [HikeLite](https://hikeliteapp.com/) -- ultralight gear management with CSV support
- [Packrat](https://www.packrat.app/) -- iOS/Android gear inventory with CSV/JSON import
- [LighterPack GitHub Issues](https://github.com/galenmaly/lighterpack/issues) -- user feature requests and limitations
- [Palespruce Bikepacking Gear Spreadsheet](http://www.palespruce.com/bikepacking-gear-spreadsheet/) -- spreadsheet workflow GearBox replaces
- [99Boulders Backpacking Gear List Spreadsheet](https://www.99boulders.com/backpacking-gear-list-spreadsheet) -- spreadsheet workflow patterns
- [LighterPack](https://lighterpack.com/) -- weight classification and pie chart visualization patterns
- [LighterPack Tutorial (99Boulders)](https://www.99boulders.com/lighterpack-tutorial) -- detailed feature walkthrough
- [LighterPack Tutorial (Backpackers.com)](https://backpackers.com/blog/how-to-calculate-backpack-weight-with-lighterpack/) -- base/worn/consumable definitions
- [Hikt](https://hikt.app/) -- searchable gear closet, base vs worn weight display
- [PackLight (iOS)](https://apps.apple.com/us/app/packlight-for-backpacking/id1054845207) -- search, custom categories, bar graph visualization
- [Packstack](https://www.packstack.io/) -- base/worn/consumable weight separation
- [HikeLite](https://hikeliteapp.com/) -- worn weight marking, CSV import format
- [Packrat](https://www.packrat.app/) -- flexible weight unit input and display conversion
- [BPL Calculator Forum Discussion](https://backpackinglight.com/forums/topic/new-backpacking-hiking-weight-calculator-app/) -- unit conversion UX, search filter patterns
- [react-minimal-pie-chart (GitHub)](https://github.com/toomuchdesign/react-minimal-pie-chart) -- 2kB lightweight chart library
- [Best React Chart Libraries 2025 (LogRocket)](https://blog.logrocket.com/best-react-chart-libraries-2025/) -- chart library comparison
- [LighterPack GitHub Issues](https://github.com/galenmaly/lighterpack/issues) -- user feature requests
- [OutPack](https://outpack.app/) -- modern LighterPack alternative with category breakdown graphs
- [Pack Weight Calculator Guide (BackpackPeek)](https://backpackpeek.com/blog/pack-weight-calculator-base-weight-guide) -- base weight calculation methodology
---
*Feature research for: Gear management and purchase planning*
*Researched: 2026-03-14*
*Feature research for: v1.2 Collection Power-Ups (search/filter, weight classification, visualization, candidate status, weight units)*
*Researched: 2026-03-16*