A1

Every day we’re surrounded by products competing for our attention. Billions of dollars are spent persuading us to buy more, upgrade sooner, and have us believe the next purchase will finally be the right one. In a world driven by overconsumption, the average consumer is filled with uncertainty when trying to make a decision.

We first shipped Zozy as a home-inventory app: price what you already own, total it on a dashboard. It worked but it asked for a behavior almost nobody performs since a person catalogs their belongings maybe once a year. What people do most weeks though is stand in a shop wondering whether to buy something. Pointing the same engine at the intent before purchase created Zozy 2.0.

Discovery

The pivot was a frequency argument. Having seen v1’s usage shape, we noticed that the highest-value feature was sitting at the lowest-frequency moment. Value multiplied by how often it can fire made the pivot obvious.

Framing

The version that wins is the version that feels most natural to adopt. Someone holding a jacket has thirty seconds and no interest in figuring anything out, so the app has to be understood at a glance by a person who has never opened it.

Tradeoffs

• Unhelpful and visibly wrong over flattering and silently wrong
• Answer the question myself over adding a control that moves it onto the buyer
• Reversibility over cleanliness: leave deprecated features branched if a flag might flip back

The estimation engine never sees the asking price.

A model shown the asking price will price toward it. The fix is architectural instead of a line of instruction: the model reports what an item goes for, then Zozy does the comparison. An anchoring failure the code cannot reach beats one the prompt asks the model to avoid.

Comparable listings are evidence the model may reject.

Where a size-M jacket returns five size-XS listings, that median is arithmetically clean and factually irrelevant. Only a model reading the titles can discard them.

An iOS app that independently informs people before they buy, so they can spend on what deserves their money, walk away from what doesn’t, and feel good about both.

Core loop

Snap the item → read the estimate against the asking price → decide: buy it, keep watching it, or pass.

Subtraction over over-engineering.

I wrote a simplification spec expecting to build five things. Two were already shipped, so the work was mostly hiding surfaces. The retention loop I wanted to bet on already existed and was buried under everything else I’d added. Shipping more had made the good feature harder to find, and the fix was a flag that hides, deletes nothing, and changes nothing about what gets written.