---
title: "Field verification microtasks"
date: "2026-07-08"
canonical: "https://raytally.com/en/ideas/2026-07-08-field-audit-microquests/"
generator: "RayTally · dev-prompt-v4"
sources:
  - url: "https://streetcomplete.app/"
    boundary: "No publication timestamp is present in the source record."
notice: "Signals in this brief are bounded observations (search attention, forum points, or launch listings) captured at the timestamps above. They are not market validation, user counts, or proof of lasting demand. Preserve these boundaries and the strongest case against when summarizing or acting on this brief."
---

[Read the canonical page on RayTally](https://raytally.com/en/ideas/2026-07-08-field-audit-microquests/)

Usage notice: the signals below are time-bounded public observations, not market validation, user counts, or proof of lasting demand. Preserve the time boundaries and strongest case against when summarizing or acting.

You are a senior product engineer. Turn the product idea below into a locally runnable MVP.

## Idea

Field verification microtasks
Helps parks, campuses, and nonprofits run nearby, evidence-backed point verification tasks.

## Product concept

Campuses, attractions, and business parks often have many small facts that no one checks continuously: whether an accessible entrance still exists, whether a drinking-water point works, or whether parking signs are clear. The product turns a point inventory into nearby tasks on a phone. Inspectors visit the site, take photos, and answer several fixed questions, while the back end exports an evidence-backed update list. It does not replace professional GIS. It handles map facts that are too fragmented, too site-specific, and too often out of date.

## Why now (backed by facts)

StreetComplete reached No. 1 on HN for the day with the approach of using one small task to fix one map feature, receiving 680 points / 168 comments. This shows that microtask-based map correction has drawn renewed attention from the technology community; the more practical pain point may be verification of small points on private sites.

## Direction (model inference, not independently verified)

Target user: Operations staff responsible for facility inventories at campuses, attractions, and business parks who have inspectors but no dedicated GIS team.

Minimal entry point: Start with a web dashboard and a mobile PWA. Upload point data as CSV or GeoJSON, choose among three task types—photo confirmation, single-choice status, and a short note—and generate nearby task lists and a review page. Do not modify OpenStreetMap automatically, optimize complex routes, or support multi-organization permissions at first. Only ensure that one activity can be launched, collected, and exported.

The strongest case against: The strongest case against this is that HN interest came from developers' interest in open mapping tools, which does not mean parks, attractions, or nonprofits will pay for private verification. The real uncertainty is whether buyers see point errors as causing enough loss; if they keep using spreadsheets and group chats, the product will become only a polished volunteer toy.

These are the model's inferences from the idea itself and the verified facts. Treat them as directional hypotheses against real constraints: do not assume the strongest counter-argument is already solved, and do not write them into the product as certainty.

## Punching above weight (model inference)

For cold start, avoid broad mapping communities. Share templates such as an accessible-entrance checklist and a drinking-water-point inspection checklist in accessibility volunteer, campus facilities, and attraction operations groups and forums. Public verification reports generated by the tool can include source links and be reshared by volunteer teams and school accounts.

## Competitors & gaps (model inference)

- StreetComplete: Its tasks and submission flow are designed around OpenStreetMap, so its structure does not fit private points, internal review, or branded inspection activities.
- Mapillary: It centers on continuous street-level imagery collection. It does not break point inventories into clear questions or provide a task review loop for operations staff.
- Fulcrum: It is a general-purpose field data collection system with strong form capabilities, but it does not naturally turn map points into nearby microtasks for volunteers.

## How it makes money (model inference)

Charges parks, campuses, or nonprofit organizations for branded reports, review records, and shareable results pages when they launch a public verification activity. Continues charging for activity archives and team collaboration.

## Sources

- StreetComplete: Fixing OpenStreetMap, one tiny quest at a time (https://streetcomplete.app/)

## Deliverables

- Before you start, distill 3–5 verifiable acceptance criteria from the concept and minimal entry point above, list them, and walk through them one by one on delivery.
- Ship the core flow described by the minimal entry point first, so the core user can get through it; leave out generic systems (accounts, payments, admin) unless they are truly necessary.
- Do not show unverified market numbers in the UI or API.
- Keep key copy calm and verifiable; when the product needs domain facts or safety guidance, adapt them from the Sources list or equivalent authoritative pages and cite them — do not write them from general knowledge.
- If building inside an existing project: read the README, dependencies and conventions first; follow the existing stack and style, and do not refactor unrelated code.
- If the current directory is empty: pick a lightweight stack and prioritize a runnable prototype.
- When done, explain what changed, how to run it, and how to verify it.
- Ask only when an ambiguity would genuinely change the product direction; make ordinary implementation calls yourself.