Nation Analytics is a government-spend-tracking consultancy. They needed a first website to establish public presence and verify the business as legitimate to potential clients. I built it.
The project was small and bounded: a WordPress brochure site describing the business, frontend-only, no custom backend. What made it interesting wasn't the engineering. It was that this was one of my first freelance engagements and the first payment I ever received for web development work. It also taught me the part of the job that engineers most often skip and product-engineer roles at AI-applied teams ask for hardest: communicating with a real customer, gathering requirements, and shipping when the customer goes quiet.
A small project with a long client-requirements arc
Most of the work wasn't the WordPress build. It was the client work that surrounds any small-business website:
- Helping the client choose a domain name based on what was actually available to buy. They hadn't worked through the inventory.
- Purchasing the domain on their behalf and getting it pointed at the site.
- Surfacing requirements. What the site should say, who it was speaking to, what language should represent the business publicly. Most of this was extracted from a client who wasn't very responsive, which made the requirements work its own kind of work.
- WordPress development. Basic CSS, web design, technical implementation across the standard pages a brochure site needs.
The technical build was the smaller piece. The communications and requirements work (getting unblocked when the client went quiet, asking the right questions to surface what they actually wanted, making decisions on their behalf when responses didn't come) was the larger one.
Why it mattered for the work I want next
This was an early project, but it was a pivotal one. First freelance engagement that paid. First time taking a project from "client wants a website" to "site is live at their domain name." First time working through the messy, non-engineering parts of being the only person responsible for a software outcome: purchasing the domain, surfacing requirements, making decisions when the client went quiet.
Those reps are exactly the muscles a product engineer at an AI-applied team has to exercise daily. Sit close to a customer, drive the requirements conversation, make calls when the customer can't, and ship something the customer can actually use. Everything that came after (the rest of my freelance work, FedNow's discovery sessions with the Federal Reserve, the discovery work on the open-source agent projects) used these reps.