Case study / Application development
HuntSomewhere
A trip planner for Maryland hunters. Describe a trip or set preferences by hand, edit them, save the trip to a unique link, and see which curated public wildlife management areas fall in your counties, each with its official source and a clear note on what isn’t confirmed.
Built for Maryland hunters who want a quicker start on where to look, without being told that a place is open or legal to hunt when the data doesn’t say so.
- My role
- I defined the problem and application workflow, guided AI-assisted implementation, reviewed the results, and refined how users review suggested trip preferences and understand the limits of the location data.
- Built with
- Next.js, React, and TypeScript with Prisma on Neon PostgreSQL, zod validation, and the OpenAI Responses API, deployed on Railway.
- Status
- Deployed on Railway. Trip planning, saved trips, and county-based discovery of six curated public areas work today. Accounts, private-land listings, access requests, and maps are planned.
01 / Problem
Where to look, and what’s really known.
Planning a hunt in Maryland means piecing together where public land is, which county it’s in, what you’re after, and how you’ll hunt, from sources that weren’t built to answer those questions together. Public ownership records say who owns a parcel, not whether hunting is allowed there, which species are present, or when seasons run.
HuntSomewhere’s long-term goal is a hub that connects hunters with public areas and willing private landowners. The working version tackles the first step: turning a hunter’s plans into clear search preferences and pointing to public areas in the right counties, while being upfront about what the data doesn’t establish.
02 / How it works
Describe, review, save, discover.
-
Describe or set preferences
A hunter can write a short description (up to 300 characters) and let the AI step suggest counties, species, methods, and dates, or skip AI entirely and pick the same options from lists. The description is used for that one request and isn’t stored.
-
Review and save
Each preference shows up as a choice the hunter can remove or add to. Saving validates the selections on the server and stores them in PostgreSQL under a randomly generated link. Anyone who has that link can view the trip; it isn’t protected by an account.
-
Discover public areas
From a saved trip, the hunter can list curated wildlife management areas in the trip’s counties. Matching is by county only, and the results page says that species, methods, dates, and hunting access aren’t confirmed. A result is not a recommendation or a confirmed place to hunt.
03 / Implementation decisions
Clear about what the data says.
The AI suggests; code validates
The model is instructed to extract only what the description states, to treat it as untrusted text, and not to infer seasons, bag limits, permission, or access. Its reply must match a strict JSON schema and is validated again against the allowed counties, species, and methods; a reply that doesn’t validate isn’t applied. Broad terms such as “deer” are expanded into specific options by code, so each one is visible and removable.
Uncertain terms stay unresolved
The model is instructed to leave season terms and vague dates, such as “opening day” or “early November”, as unresolved notes rather than dates. Code adds a check of its own: dates that aren’t real or are out of order become unresolved instead of being applied.
A database-enforced limit on AI requests
Before each AI request, a single conditional database update reserves one request from a fixed allowance. The update only succeeds while requests remain, so simultaneous requests can’t take the count past the limit. Reservations aren’t released, even if a request fails or times out. An environment switch or a database flag can turn AI off, and the manual form keeps working either way.
Source data kept with its provenance
The six areas come from the State of Maryland’s protected-lands dataset (MD iMAP / Maryland DNR). The source files are kept unchanged with recorded checksums and a provenance note, and each area carries only what the source establishes: its name, county, and DNR page link. The pages show the data credit, the retrieval date, that the source’s update date is unknown, the source’s as-is disclaimer, and a notice that public ownership doesn’t by itself mean hunting is allowed.
04 / The interface
A demonstration trip, start to finish.
The trip shown is a fictional example entered through the manual form, with no AI involved: Garrett County, white-tailed deer, vertical bow, and two November dates. Garrett County returns the two curated areas the source places there.
05 / Scope
What it does, and doesn’t.
What is implemented
- AI-suggested county, species, method, and date preferences from a short description, with unresolved terms shown separately
- A manual preference form that works without AI
- Saved trips in PostgreSQL behind a randomly generated link, validated when saved and again when loaded
- A list of six curated wildlife management areas in four counties (Garrett, Allegany, Washington, and Montgomery), each with its source and DNR page link
- County-based discovery of those areas from a saved trip, with uncertainty and coverage notices
- A data-sources page with attribution and the source’s published reuse terms
- AI safeguards: input limits, a 10-second timeout, a database-enforced request limit, an off switch, and a specific message for each failure
What it does not do
- There are no accounts. Anyone who has a trip’s link can view it.
- Coverage is six areas in four counties, not a statewide inventory.
- Matching uses county only. It doesn’t establish hunting access, eligibility, seasons, or suitability for a species or method.
- Maps, private-land listings, access requests, permission documents, and messaging are planned, not built.
06 / Contribution
What I contributed.
I defined the problem and application workflow, guided AI-assisted implementation, reviewed the results, and refined how users review suggested trip preferences and understand the limits of the location data.
Built with
- Next.js and React App Router pages and server actions, written in TypeScript.
- Tailwind CSS Interface styling, with light and dark themes.
- Prisma and Neon PostgreSQL Models and migrations for trips, the AI request allowance, and data sources.
- zod Validation of trip preferences and of the AI’s structured output.
- OpenAI Responses API Structured output against a strict JSON schema, called from the server.
- Railway Hosting for the deployed application.
Next / Have a similar problem?
Let’s talk it through.
Tell me what you need to organize or the workflow you want to simplify, and we’ll work out together whether a tool like this would help.
Start a conversation