Developing AnchorPoint: From Frustration to Blueprint (Part 2)

There’s a stretch of road between Moody Air Force Base and our home in Valdosta that lives in my head rent-free. It’s about ~10 minutes of nothing. No gas stations. No coffee shops. Just trees, humidity, empty or rundown husks of former businesses pre-hurricane, and the occasional armadillo casualty.

When we first got the orders to Moody, Anna and I did what any modern military family does: we opened Google Maps, Zillow, and Reddit. We were still in Korea at Kunsan but coming “from” our experience at Scott Air Force Base in Illinois, where the town of Shiloh is practically part of the base. Need groceries? Three minutes. Decent coffee? There’s a place right outside the gate. Community? You’re swimming in it. The highway? Right there- takes you straight into St Louis, 20 minutes max.

Moody… isn’t like that.

The base felt isolated. Valdosta was a solid 15-20 minute drive, and online information was sparse, contradictory, or just plain absent. Forum posts were years old. Zillow showed houses but not neighborhoods. Google Maps knew distances but not vibes.

We weren’t just looking for data. We were looking for context. For someone to say, “Hey, this is normal—the good stuff’s in town, here’s where people actually hang out (we haven’t actually figured out where people hang out, by the way… I’m pretty sure they don’t).”

That gap—between raw information and lived experience—is where AnchorPoint was born. Not in a boardroom, but on one of our long drives from Valdosta to the closest real airport in Jacksonville- with Anna asleep in the passenger seat while I sketched out the system in my mind, wondering why no one had built the tool we would have desperately needed. We would’ve probably never picked Moody had we known we’d always be a 2 hour drive from being able to fly anywhere from our home. Why didn’t we know this before we got here? How would we have known to really ask?

Defining the MVP Scope

I’ve been in software long enough to know that the fastest way to kill a good idea is to over-scope it. So naturally when I sat down to plan AnchorPoint, I threw all my PM knowledge out the window- I ignored every over-scope project I’d ever had, every budget blown, and started with a massive vision. Forums. User profiles. Real-time chat. Custom maps. A whole ecosystem.

It was beautiful. It was also completely unbuildable—at least by me, a non-developer with limited coding skills. Oh look, it’s those pesky project constraints I thought I could throw away because it was ‘just me’…

So I did what any good product manager does: I ruthlessly prioritized. One night I said out loud to our cat, “Damn, this means I’ll need a Trello board for this, doesn’t it? At this point it’s basically work.”

After chastising myself for waking the cat, I then asked myself: What’s the smallest thing I can build that still delivers real value?

The answer was simple: a search bar.

Not an account system. Not a social network. Just a clean, simple interface where someone could type a question—“What’s the commute like from Remerton to Moody?” or “Where do military families usually live around JB Charleston?”—and get a clear, synthesized, human-readable answer.

That became the North Star for the MVP.

Here’s a snippet from the actual requirements doc I drafted:

### Project Overview

**Project Name:** AnchorPoint  
**Purpose:** Perplexica-powered web application to help U.S. military spouses connect, share local knowledge, and rebuild community after PCS moves.

**MVP Goal:**  
Build a working proof of concept of a stylized frontend with a query bar that:
1. Accepts user input.
2. Sends queries to a Perplexica backend instance (API passthrough only).
3. Displays results in styled UI using the provided DESIGN_SYSTEM.md.

This is a validation build to test functionality and market interest. No authentication, database, or profile features yet. Ensure copy and UX guidelines are maintained.

This wasn’t just a technical constraint—it was a philosophical one. By focusing on the core interaction (ask a question, get an answer), I could ship faster, learn sooner, and avoid the classic side-project graveyard of half-built features.

Requirements Documentation

A good requirements doc is part blueprint, part battle plan. It has to be specific enough to build from, but flexible enough to adapt when (not if) things change.

I broke things down into a few key areas:

Functional Requirements:

A query input and submit button
API integration with a self-hosted Perplexica instance
Clean, styled results output
Loading and error states
Environment variable configuration for API keys and URLs

Non-Functional Requirements:

Fast response time (< 3 seconds per query)
Accessible, mobile-friendly UI
Clear, empathetic tone in all copy
No login required for MVP

Use Cases: As a military spouse, I want to:

Quickly assess commute times from nearby neighborhoods
Understand the local school options without reading 100 forum threads
Find family-friendly areas near base
Get a feel for the community vibe before committing to a lease

I also included technical and design constraints:

### Style & Architecture Principles
- Clarity over cleverness: Write clean, readable React components.
- Design system first: Always implement UI using tokens and styles from DESIGN_SYSTEM.md.
- Encapsulation: Encapsulate API logic in a reusable `usePerplexicaQuery` hook.

Every design and content decision was filtered through one question: Will this make a stressed-out military family feel more confident and less alone?

Architecture Planning & Workflow

Here’s where my non-developer background actually became an advantage. I didn’t know how to build a traditional full-stack application, but I know how to architect systems and integrate technologies.

The original plan was… ambitious. I planned to manually build a JSON dataset for every major base, then use a local LLM with a Model Context Protocol (MCP) server to query it. I spent about a week trying to make this work before realizing it was a bottomless pit of data entry and configuration. Seriously- I thought I was going to comb the internet for every base, input structured data for each, and then… basically rely on the community to help me keep it updated. I was basically just building yet another source for bad data which was the whole original problem I wanted to solve! Sorta like that XKCD comic about ‘standards’.

Then I discovered Perplexica.

Perplexica is an open-source AI search tool that can connect to multiple data sources—including the live web. By self-hosting an instance, I could point it at relevant military forums, local guides, and community resources, then let it do the heavy lifting of synthesizing information. It combines with SearXNG: another selfhosted tool that is a ‘metasearch’ engine: it basically searches the results of other search engines to build authoritative examples for whatever you search for. Google will spit out some things, Yahoo others, DuckDuckGo others, AskJeeves (is that still around?) others yet- but SearXNG searches them ALL, compiles the lot for the user.

The architecture became elegantly simple:

Frontend: React + Vite + Tailwind (hosted on Cloudflare Pages)
API Layer: A lightweight proxy to handle requests to Perplexica
Backend: Self-hosted Perplexica instance with SearXNG for real-time search

So the user input on the frontend goes to Perplexica, which formats the query by utilizing a LLM to break it into constituent pieces (eg. finding what base the user is talking about, figuring out which elements are the question and which are backstory), and then punches those queries into SearXNG. SearXNG searches EVERYWHERE for it and pushes those results back to Perplexica, where a different (more powerful) AI model parses all the raw data, puts it up against the original user’s query and my secret sauce system prompt and then the user gets a natural-language response to their question. Elegant, no?

That still sounds overly technical. Think of it like this: if traditional software development is building a car from scratch, what I did was connect a really good engine (Perplexica) to a well-designed chassis (React frontend) and focused on making the driving experience seamless.

My role wasn’t to be the mechanic—it was to be the architect and driver. I used AI coding tools (Cursor with Roo Code, OpenRouter models, LibreChat) to help with the implementation, but the vision, structure, and integration strategy were all mine.

Design Philosophy & User Experience

Every design decision in AnchorPoint comes back to two principles: clarity and empathy.

The UI is built with Tailwind using a custom design system that prioritizes:

Readability (clean fonts, generous spacing)
Accessibility (proper contrast, semantic HTML)
Trustworthiness (honest messaging, clear sourcing)

The tone is human and reassuring—no corporate jargon, no marketing fluff. Microcopy matters. Instead of a blank page while we wait for that robust search to be executed, we say “Searching AnchorPoint’s AI-powered Database” with a spinning wheel so you know something is happening. Instead of a generic “Submit” button, we use “Search” or “Find Answers.”

These small choices add up. They signal that this tool was built by someone who understands the stress and uncertainty of a PCS move—because it was.

Human + Professional Lens

Building AnchorPoint has been a exercise in leveraging my entire professional toolkit:

As a military spouse, I understood the pain points intimately
As a lawyer, I knew how to structure requirements and mitigate risk
As a product leader, I knew how to prioritize and scope effectively and work with a development team (more on my AI “developer” later)
As a marketer, I knew how to communicate value and build trust

This isn’t a story about a developer building an app. It’s about a problem-solver using every available tool to address a real human need. AnchorPoint is a labor of love, but it’s also professionally considered and strategically built.

What’s Next?

In the next post, I’ll walk through how I actually built this thing—how I turned this requirements doc into a working product using AI-assisted coding, strategic integrations, and a healthy dose of stubbornness.

Spoiler: it involved more tea, more late nights, and more respect for actual developers than I ever anticipated.

Stay tuned,
—Chris

Posts in this series

now personal technology AI military development PM anchorpoint korea usaf