# Build brief — a focused alternative to HuntStand

> **Verdict:** Not faithfully · **Buildability:** 18/100 · **Category:** Productivity Utilities
> **Source:** https://www.canitbevibecoded.com/huntstand
> Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from HuntStand. Verify current pricing and capabilities before acting.

## Context

**HuntStand** — Mobile mapping app for hunters: property boundaries, stand and camera markers, wind and weather overlays, and shared hunt logs for a hunting club. It currently costs $2.92/mo.

Drawing pins on a map and logging what you saw at dawn is a trivial build, and an agent will hand you a working offline map with a focused implementation. The part people actually pay for is the data underneath: nationwide parcel boundaries with owner names, recent high resolution aerial and topo imagery, and radar and wind layers stitched into one mobile app that works with no signal. That parcel layer is licensed, not scraped, and the imagery bill is real. Add the club side of it, where four people share the same map and see each other's stand check-ins live, and your local-only build stops covering the use case. Build the personal scouting notebook, keep paying if you need to know who owns the ridge behind you.

This brief describes a focused, single-operator replacement for the part of HuntStand that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

## What you are building

An offline-capable PWA map where you drop stands, cameras, food plots and trails, draw your own property polygon, log sits with wind and moon data, and export everything as GeoJSON.

- Automate one repetitive personal workflow end to end with real persistence.
- A responsive interface with real empty, loading, success, and error states.

## Requirements

### Functional

- County or state GIS parcel exports downloaded by hand for the properties you care about.
- A phone that will actually install a PWA and cache tiles.

### Data and integrations

- A MapTiler or Mapbox key for satellite and topo tiles, or plain OpenStreetMap tiles if you accept no imagery.
- Open-Meteo for forecast and wind, no key needed.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

### Non-functional

- Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.
- Security: server-side secrets, validated input, and no credentials in the client bundle.
- Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.
- Portability: the operator can export their data and leave without losing it.

## Implementation brief

Build a personal, offline-first hunting scouting map as a PWA. No accounts, no server, no telemetry. All data stays on the device.

Stack, no substitutions:
- Vite + React + TypeScript
- MapLibre GL JS for the map
- Dexie (IndexedDB) for all storage
- vite-plugin-pwa for installability and tile caching
- Tailwind for styling, keep it plain and thumb-friendly

Map:
- Base layers switchable: satellite and topo from MapTiler using VITE_MAPTILER_KEY from .env, plus an OpenStreetMap raster fallback that needs no key
- "Download this area" button: prefetch tiles for the current viewport at zoom 12 to 16 into the service worker cache, show progress and cache size, allow clearing

Data model in Dexie: properties (name, GeoJSON polygon, acres computed), markers (type: stand, blind, camera, plot, trail cam, gate, sign, custom; lat, lng, notes, photo blob), tracks (recorded GPS line, timestamps), sits (marker id, start, end, wind dir and speed, temp, moon phase, sightings list with species, count, sex, time, free notes).

Features:
- Tap map to add a marker, choose type from an icon grid, attach a photo from the camera input
- Draw or import property polygons: file import for GeoJSON, KML and GPX, since county GIS portals hand those out. Show acreage.
- Record a walk: watchPosition into a track, works with screen on, stop and save
- Wind overlay: fetch current and hourly wind direction and speed from Open-Meteo for the map center, draw an arrow and a compass rose, and shade a simple downwind cone from any selected stand so it is obvious which stands are burned today
- Sunrise, sunset and moon phase computed locally with suncalc, no API
- Sit log: start a sit from a stand marker, it snapshots wind, temp and moon, then log sightings as you go
- Export and import everything as one JSON file, plus GeoJSON export of markers and tracks

Explicitly out of scope: parcel boundaries or landowner names (no legal source to pull from, the user imports their own), multi-user sharing, sync, push notifications, deer movement predictions.

Seed with two example markers and a sample property polygon so the UI is not empty. Write a README that states plainly what it does not do.

## Delivery standard

- Inspect the repository first, then write a short implementation plan before writing code.
- Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.
- Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.
- Include responsive layouts plus genuine empty, loading, success, validation, and failure states.
- Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.
- Add structured logs around every external call and return actionable errors without leaking sensitive details.
- Write unit tests for the core logic and one automated test of the main user journey.
- Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

## Acceptance criteria

- [ ] A clean install starts the app using only the README and .env.example.
- [ ] The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.
- [ ] Invalid input, missing configuration, provider failure, and an empty database each have a usable state.
- [ ] The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.
- [ ] Tests, type checking, linting, and a production build all pass with no ignored failures.
- [ ] No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

## Non-goals

Do not build these, and do not claim to have replaced them:

- Nationwide parcel boundaries and landowner names, which are licensed data you cannot regenerate.
- Fresh leaf-off aerial imagery and multi-source topo layers across the whole country.
- Live sharing with a hunting party: shared markers, check-ins, and who is sitting where right now.
- Native app polish offline: reliable background GPS tracks, tile prefetch, battery behavior.
- Weather radar, rut and deer movement forecasts, and the constant map data refreshes.

## What you still own after launch

- Secure credentials, rotate secrets, and handle provider rate limits.
- Run migrations, backups, restores, and dependency updates.
- Test the critical journey after every model, API, or hosting change.
- Monitor failures and fix the edge cases a first prompt will miss.

## Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: medium. No reviewed project implementation is linked yet.

---

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/huntstand