Launch your own neighborhoodOS.

There is no one-click "launch a neighborhood" button. Anyone selling you one is lying. Most civic software fails because it treats the software as the product. The software is not the product here. Trust is the product. The software is the wrapper that makes showing up reliably a little easier.

What you will do over the first 30 days is mostly talk to people. Roughly 20 conversations. The software helps you remember what they said, spot patterns across them, and pick one sharp wedge to build around. You bring the neighborhood. You bring your own AI (OpenAI key, Anthropic key, or a local Ollama). We bring the wrapper.

1. Pre-flight, before you touch code.
   Day 0 · 2 to 3 hours

   Write a one-page NODE.md about your neighborhood. Boundary. Roughly how many households. Existing groups (HOA, neighborhood association, block captains, Facebook group). What civic meetings already happen and who shows up. What is broken that everyone already complains about. You will update this as you learn.

   Decide who else is in on this with you, even loosely. One person alone can start a node. One person alone cannot sustain one.

   • Template: wedges/_template/NODE.md in the repo
   • Budget: a notebook, a neighborhood map, and a coffee meeting with one ally
2. Install, wrap the work.
   Day 1 · 30 minutes

   Clone the repo, install dependencies, point the ingest scripts at your city open data portal (Socrata, ArcGIS, or your local equivalent), and drop in an AI key.

   git clone https://github.com/simonlpaige/neighborhoodos.git
   cd neighborhoodos
   npm install
   cp .env.example .env
   # edit .env: add OPENAI_API_KEY or ANTHROPIC_API_KEY or OLLAMA_HOST
   # edit connectors/cities.json: add your city open data endpoints

   If your city has no open data, that is fine. Skip the connectors for now. The intake and wedge work still runs.

   • Supported AI: OpenAI, Anthropic, any Ollama model locally
   • Your data never leaves your machine. AI calls go through whatever key you provide.
3. Listening, the actual work.
   Days 2 to 20 · about 20 conversations

   This is the phase where real nodes are made and fake ones die. Talk to 20 neighbors. Start with the loud ones (block captains, long-timers, the person who runs the Facebook group). Move to the quiet ones (people who moved in recently, elderly homeowners, renters if your wedge includes them).

   The intake tool in the repo gives you a 12-question conversation guide and stores anonymized notes in your local DB. After each batch of five conversations, run node intake/summarize.js and it asks your AI to pull pain patterns across them.

   • Bring snacks. Seriously.
   • Sit in on two or three existing civic meetings. Listen more than you talk.
   • Record which pains come up repeatedly, not just the loudest one once.
   You will feel like you have nothing after week two. That is normal. Patterns do not show up until around conversation twelve. Keep going.
4. Wedge selection, pick one pain.
   Days 20 to 25 · one evening, then sleep on it

   Run node wedges/suggest.js. It hands your intake summary to your AI with the four-test filter baked in. You get two or three candidate wedges ranked on:

   • Concrete. Can you describe it in one sentence at a kitchen table?
   • Costly. Are people losing money, time, or dignity to it right now?
   • Local. Does the fix work at the block level without waiting on city hall?
   • Swappable. If you build the wrong thing, can you stop without tearing out the platform?

   The AI recommends. You decide. Pick one. Write the chosen wedge into wedges/your-wedge/README.md. Tell three of the neighbors who showed up strongest in intake that this is what you are building toward, and ask if they will try v1.

5. Scaffold, the ugliest v1.
   Days 25 to 30 · a weekend

   Run node wedges/scaffold.js your-wedge. It creates a folder with an ingest script, a local data model, a basic CLI, and a README stub. It does not build you a product. It gives you the skeleton so you can start filling in what your wedge actually needs.

   The ugliest possible v1 is usually a spreadsheet or SQLite list, one script that updates it, and one human (you) sending a weekly text to the neighbors who opted in. That is fine. Ship that. Every fancier version is built on top of that skeleton once it earns trust.

   • No users yet means no product yet. Get three real users before you write your second feature.
   • Toothbrush test: does anyone use this twice a week? If not, the wedge is wrong, the UX is wrong, or it is both.
6. Run, listen, rotate.
   Day 30 onward

   After 90 days, check the signals below. If the wedge is working, keep running it and queue the next one. If it is not, rotate the wedge. The platform stays. The wedge changes. That is the whole point.

• Not a platform that runs your neighborhood for you. You run it. This is a wrapper.
• Not a social network. No feed. No likes. No algorithm. The software exists to make specific shared problems a little easier.
• Not a hosted SaaS. Every node runs locally. Your data stays with you. If two nodes want to federate, they opt in explicitly.
• Not for every neighborhood. If your block already solves its own problems informally, great, you do not need this. Come back when something is actually breaking.