Wiki
Proof of concept
The next prototype should make the concept concrete enough for a pitch conversation. It does not need to prove the full organization, all data integrations, or the final technical stack. It needs to show the product backbone.
What The Prototype Must Prove
- A user can move through cascading location scales: street, buurt, city.
- A user can filter by themes and see different civic objects at each scale.
- Residents, government, and entrepreneurs can all participate without becoming one generic feed.
- Questionnaires can turn local needs into structured priorities.
- Events can bridge digital participation into physical-world gathering.
- Open data and public plans can become a contextual civic inbox.
Six Wireframes
| Wireframe | Purpose |
|---|---|
| Map Lens | Shows the main interaction: location scale plus theme filters |
| Theme View | Shows one theme across scales and roles |
| Questionnaire | Shows budget and policy prioritization as a civic mechanism |
| Events | Shows adoption through physical-world activity |
| Civic Inbox | Shows push-based public information from government and open data |
| Governance | Shows roles, ownership, formal/informal communities, and moderation boards |
What To Avoid
- Do not lead with a chronological feed.
- Do not frame the concept as a Nextdoor clone.
- Do not make municipal integration the whole story.
- Do not overexplain ActivityPub, identity, or long-term architecture in the first pitch.
- Do not make the first prototype depend on perfect data coverage.
Pitch Flow
Start with the map lens, because it shows the backbone immediately. Then move into a theme view, because it proves the concept is not just geography. Then show a questionnaire and an event, because they demonstrate civic participation and physical-world action. Close with the civic inbox and governance model, because they explain why Amsterdam would care and why society ownership matters.
Tags
#year/2026 #city/amsterdam