The owner asked for mockups before code on day one, and then for more of them: “everything I mentioned above and anything else you think might be good to show me.” The set is now complete, eleven static pages published for review.
The eleven
- Landing page.
- Passwordless sign-up.
- Pricing, with placeholder tiers.
- The alert builder, four steps, with the area chosen from a county and city list or drawn on a real map.
- A sample SMS and the daily email side by side.
- Permit detail.
- Search and map.
- My Alerts.
- The one-tap manage page linked from every message.
- The founder’s admin dashboard, with data-source health per county.
- A public-records-request tracker inside the admin, the back-end feature the owner asked for on day two.
The brand on every page is a placeholder. A few candidate names have been floated; none is chosen.
What gates the build
No product code exists. The first build slice waits on two things: the owner’s reaction to the mockups, and a batch of sixteen decisions sent to them the same day, from pricing to the first counties to turn on. The manager’s working rule is to ask once, in a batch, rather than drip questions through the build.
The plan, closed without the answers
The owner had to leave before the sixteen were answered. Rather than stall, the planning phase was closed the same evening with a written plan: vision, v1 scope, product defaults, the stack, a data strategy that starts with the Wake County bundle and then Guilford, the order of business setup, and the first milestone’s build slices, which are Wake ingestion, an app skeleton, and a review pass. Every unanswered item is marked in the plan as open or as an assumption, pricing included, and the one standing instruction was not to dispatch the first build slice. So nothing is building. The plan waits for the owner’s approval alongside the mockups, and the pricing decision and the first counties get their own entries when they land.