Our process

Fewer features, chosen carefully.

We work in small loops: notice a real frustration, build the smallest honest fix, release it, then listen. Most of the job is deciding what to leave out.

One app
at a time
No ads
and no analytics
Android
first

The loop

Five steps, then back to the start

An idea has to get through every step before it reaches your phone. Plenty stop at step three, and that is the point.

  1. 01

    Notice

    A complaint heard once is a data point. The same complaint heard again and again becomes a brief.

  2. 02

    Sketch

    Paper first, then one screen. If the idea needs a tutorial to explain, we have already lost.

  3. 03

    Cut

    We remove until it hurts a little. Much of what gets sketched in step two never gets built at all.

  4. 04

    Live with it

    We use the build on our own phones before anyone outside sees it.

  5. 05

    Release & listen

    A small release, plain notes, and a real person reading every reply that comes back.

The filter

Most of our work is deciding what not to build

Every idea gets held against the same two lists before it earns a single day of engineering time.

We build it when

  • Someone describes the problem without naming a feature
  • It works the same on a cheap phone as a new one
  • We can explain the change in one sentence
  • It still matters a year from now

We leave it alone when

  • The value shows up in a dashboard, not in your day
  • It needs an account, a streak or a notification to work
  • Only the loudest voices asked for it
  • The honest version of the release note would embarrass us

In practice: what Pooled leaves out, on purpose

  • Dividing costs between people. Pooled keeps a shared record of who paid for what, with a live balance for every member. It does not carve up bills or chase anyone for money.
  • Ads, and a paid upgrade to remove them. There are none, and nothing to buy: Pooled is free during early access.
  • Analytics and crash reporting. No tracking SDK and no advertising ID. We learn what is wrong from the people who write to us.

Before a release

Small releases, checked before they go out

A release is not judged by its size. Each one has to pass the same few checks before it reaches anyone's phone.

What every release is checked against

Every time
  1. Every claim, checked against the code

    What this website and the store listing say about the app is compared with what the app actually does. If they disagree, the words change or the release waits.

  2. The privacy policy comes first

    If a release changes what data goes where, the privacy policy is updated before that release goes out, not after.

  3. One sentence per change

    If we cannot explain a change in a sentence, it is not ready to ship.

  4. Plain release notes

    Notes say what changed and why. “Performance improvements and bug fixes” is not a release note.

Think we got something wrong?

Tell us what is annoying you, or what we have left out, and it goes straight onto the list.