Initial planning for the Share the Search app

What it is

You type a position rather than a keyword — this policy is a disaster, the NRA is worth defending — whether you are trying to prove it or break it. What comes back is two to five paragraphs of what is actually true, sourced, at its own permanent link. Bookmark it, send it to someone, come back to it.

Not a list of ten blue links. Not a summary with a shopping cart bolted to it.

Why this shape and not the last one

The predecessor here is SHARE, which asked people to write news stories under their own byline. The idea was sound and nobody came. The sentence that explains the pivot is Michael's:

Everyone searches. Not everyone wants to be a journalist.

SHARE asked people to become something. This meets them doing what they already do forty times a day.

The second change is polarity. SHARE disclosed how it worked in detail, on a page of its own, and the honesty read as a warning label. Here the same material is the product: no selling you something, no selling you to someone, no answer shaped by who paid. That is a reason to use it rather than a disclaimer to get past.

The tension, named early because it will not go away

Accounts make the product better — a list of everything you have asked, kept and searchable. Accounts are also a record of everything you have asked, which is the exact thing the pitch promises not to build. A bookmarkable link needs no account; a history does.

Unresolved on purpose. It is a product decision, not an implementation detail, and getting it wrong in the wrong direction makes the whole position dishonest.

The path to a store

SHARE's roadmap is a reference for the process and nothing else. The order holds because it has nothing to do with what the app is:

1. Build the thing on the web first, as a PWA — manifest and service worker are the foundation a store wrapper sits on.
2. Wrap it with Capacitor, one project serving both stores.
3. Google Play first — $25 once, builds on the Windows machine.
4. Apple second — $99 a year, and the build has to be compiled and signed on the Mac.
5. Nothing costs a dollar until the build is one we are happy with. Emulator, then sideload onto a real phone, then pay.

And the one genuinely valuable thing learned over there: a real native feature is what stops Apple rejecting the app as a wrapped website.

What must not be inherited

Treat everything below as undecided. It was settled for a newspaper, and this is not one.

The architecture. SHARE chose a shell loading the live site because the site is server-rendered, has no public content API, and for news freshness beats offline. None of that describes search. A query going out and an answer coming back is API-shaped by nature, which is the one case where a real front-end against a real API stops being a second thing to maintain and starts being the obvious build. Argue it from nothing.

The native feature. Push notifications fit a newspaper — a new story can ring every phone. On a search product they are a solution hunting for a problem, and on a privacy product an app that pings you is arguing against itself. The candidate that actually fits is a system share target: highlight a claim anywhere on the phone, share it in, get the answer back. That is native, useful, impossible on the web, and it is the product rather than a hoop jumped for review. Voice input is the second candidate.

The store paperwork. Play's data-safety form and Apple's privacy labels stop being end-of-process admin here. They are a claim that has to survive being read back, which makes them a constraint on the account model above.

Standing rules

Nothing is imported and nothing is copied. SHARE is a reference for format and process only, it is being taken down shortly, and everything here is built fresh. Nothing is assumed finished because a version of it was finished somewhere else.

Closed

Not being built.