DEV Community: Daniel

The Decision-Queue Pattern: Batch-Confirm UIs and the Fear of Deleting

Daniel — Wed, 15 Jul 2026 12:09:56 +0000

Disclosure: I'm a research analyst in the OpenNomos ecosystem, and Swipe Cleaner is one of the projects I follow there. The analysis below is my own.

Deleting things is scary. Not technically — psychologically. Watch someone try to clean up 3,000 photos on their phone: they open the gallery, scroll for a minute, delete four screenshots, and give up. The problem isn't effort. It's that every single delete is a small, irreversible-feeling commitment, and our brains price each one as a risk.

I keep running into a UI pattern that solves this well. I'll call it the decision queue.

The core idea: separate judgment from commitment

A decision queue splits a destructive workflow into two phases:

Judgment phase: you make fast, low-stakes calls on one item at a time. Nothing actually happens yet — items just land in a staging queue.
Commitment phase: at the end, you review the queue and commit everything in one explicit batch action.

The trick is that phase 1 becomes almost free. Since no judgment is final, you stop deliberating and start flowing. All the risk is concentrated into one deliberate moment at the end, where you can still pull anything back out.

You already know this pattern from other places: shopping carts (add freely, pay once), git staging (stage freely, commit once), and the OS trash bin (delete freely, empty once). The pattern keeps showing up because it matches how people actually handle risk: cheap exploration, expensive commitment, clearly separated.

A clean case study: photo cleanup

Swipe Cleaner (an iOS app, also listed as OnePhoto) applies this to the camera roll with a Tinder-style interface: one photo at a time, swipe left to queue it for deletion, swipe right to keep. Nothing is deleted until you confirm the whole batch at the end — and the batch review is where you catch the one whiteboard shot you actually needed.

Three things make this work, and they generalize:

Per-decision cost drops to near zero. A swipe is a judgment, not a commitment, so you process hundreds of photos in minutes without decision fatigue.
Everything is recoverable until the commit. The queue is visible and editable, which removes the fear that powers procrastination.
Trust boundaries are explicit. Photos never leave the device and there is no account. For a tool whose whole job is touching your personal data, local-first is not a feature checkbox — it's what makes users willing to engage at all.

Design takeaways

If your product asks users to make many small destructive decisions, don't make each one final:

Make the cheap action reversible and the expensive action explicit.
Show the queue before the commit — a visible staging area builds confidence faster than any confirmation dialog.
One batch confirm beats fifty "Are you sure?" popups. Confirmation fatigue is real; concentrated confirmation is respectful.

The fear of deleting is really the fear of deciding under risk. Take the risk out of the individual decision, and people will happily decide all day.

A lightweight workflow for keeping up with AI conference papers

Daniel — Tue, 14 Jul 2026 11:02:25 +0000

If you follow ML research, you know the feeling: ICLR, NeurIPS, ICML and CVPR each drop thousands of papers, and your "to-read" list quietly turns into a graveyard. Here's the workflow that finally worked for me. It's less about reading more and more about deciding faster.

1. Go topic-first, not conference-first

Browsing an entire conference proceedings front to back is how you burn out. Instead I start from a topic and pull the relevant papers across conferences and years.

Lately I've been using Paper List for this. You pick a topic (say, Retrieval-Augmented Generation) and it shows the scope up front, e.g. a few hundred papers across ~13 conferences and 5 years, before you dive in. Seeing the size of the space first genuinely changes how you budget attention.

2. Triage with a 3-pass skim

For each candidate paper:

Pass 1 (~10s): title + abstract. Does it address my exact question? If not, drop it.
Pass 2 (~1min): figures and the main results table. A paper usually reveals its real contribution in Figure 1 faster than in the prose.
Pass 3 (deep read): only the handful that survived passes 1 and 2.

Most papers never make it past Pass 1, and that is the point.

3. Keep a living shortlist, not a backlog

A backlog is guilt. A shortlist is a tool. I cap "actively reading" at ~10 papers; anything older rotates out. If a paper keeps resurfacing in my own work, it earns its slot back.

4. Read for the delta, not for completeness

You rarely need the whole paper. Ask one question: what does this do that the previous state of the art didn't, and at what cost? If you can state that delta in a single sentence, you've extracted most of the value.

The tooling matters less than the mindset. Your bottleneck isn't reading speed, it's decision cost. Anything that helps you decide what NOT to read, whether that's a topic-first explorer, a hard shortlist cap, or a skim protocol, buys back more time than reading faster ever will.

How do you triage papers? Curious what workflows other people have landed on.

Stop over-engineering your MVP: ship the one loop that matters

Daniel — Mon, 13 Jul 2026 12:31:42 +0000

Every side project I killed died the same way: I spent weeks building auth, billing, settings pages, and a dashboard for zero users.

The reframe that finally worked: an MVP is one loop, not a product.

The one-loop rule

Before writing a line of code, I answer one question: what is the single action that proves people want this?

A notes app? The loop is "write a note, find it later."
A scheduling tool? The loop is "pick a time, get a confirmation."

Everything that is not that loop is a distraction until the loop works.

What I cut (and did not miss)

Auth: a shared link or one hardcoded user is fine on day one
Billing: a Stripe payment link beats a billing system
Dashboards: a plain list ships in an hour
Settings: sane defaults, no config

Why speed compounds

Every day you build in private is a day of feedback you never get back. Shipping a rough loop in a weekend gives you real usage data; a "perfect" launch three months later gives you guesses.

I have been using 01MVP to stay honest about this. It is built for the 0 to 1 sprint, so it nudges you toward the core loop instead of the nice-to-haves.

Project: https://www.opennomos.com/en/project/01KW9BSG541GDRPXCP8JJV277Z

TL;DR

Find the one loop. Ship it this week. Let real users tell you what to build next.

What is the one loop for the thing you are building right now?

How I Stopped Losing Research Papers in 50 Browser Tabs

Daniel — Sat, 11 Jul 2026 03:27:51 +0000

The Tab Cemetery

We all know the scene. 50 tabs open. Half of them are research papers you promised yourself you would read. Three weeks later, they are still there, silently judging you.

The Real Problem

It is not that you lack discipline. The problem is that browsers were never designed to be research libraries. Every tab is a temporary container waiting to be accidentally closed.

Enter Paper List

Paper List takes a different approach. Instead of treating papers as ephemeral browser tabs, it organizes them into a proper reading engine. You can:

Save papers with one click
Organize by topic and priority
Track what you have actually read
Build a searchable personal research library

No more bookmark folders with cryptic titles like "read later (3)" or "IMPORTANT actually read this one."

My Workflow Now

Find an interesting paper → add to Paper List
Weekly review session → prioritize what matters
Read with purpose → mark complete, add notes
Search my library when starting new work

The Mental Shift

The biggest change was not technical. It was realizing that organizing research is part of the research itself. A messy reading system creates messy thinking.

What tools do you use to manage your research reading? I am curious to hear other approaches.

Building a Tinder-Style Photo Cleaner: Architecture Lessons from Swipe Cleaner

Daniel — Fri, 10 Jul 2026 05:35:49 +0000

The Problem

I had 4,000+ photos on my phone. Half were 4K duplicates, a quarter were screenshots. Manual cleanup was impossible.

The Solution: Tinder-Style Swiping

Swipe Cleaner uses a card-based interface:

Swipe left → delete (recoverable)
Swipe right → keep

The insight: swiping is 3x faster than checkbox tapping.

Architecture

Local-First

All processing happens on-device via File System Access API. No photos leave your device.

Duplicate Detection

Uses perceptual hashing (pHash) to detect near-identical images. Hamming distance < 10 = duplicate.

Tech Stack

React + Vite
File System Access API
Canvas API + Web Workers
Custom pHash in WASM (Rust)

Performance

1,000 photos: 2.3s
4,000 photos: 6.8s
10,000 photos: 14.2s

Key Lessons

Ship the core loop first, polish later
WASM > Workers for image processing (10x speedup)
Recoverable deletes eliminate user fear

Links

Try Swipe Cleaner: https://www.opennomos.com/en/project/01KW95TC7VFJXZNYHNV3SJ04CN

Built something similar? Would love to hear about your solutions in the comments!

Paper List: A Refreshingly Simple Approach to Research Paper Discovery

Daniel — Thu, 09 Jul 2026 05:14:46 +0000

I have tried many research paper discovery tools over the years — Google Scholar, Semantic Scholar, ResearchGate, arXiv Sanity Preserver, and countless others. Most of them share the same problem: they try to do too much.

The Problem with Paper Discovery Tools

The typical academic search tool bombards you with algorithmic recommendations, citation metrics, and endless filters. While powerful, these interfaces create friction between the researcher and the actual papers. You spend more time configuring search parameters than actually reading.

What Makes Paper List Different

Paper List takes the opposite approach. It presents a clean, chronological feed of papers with minimal noise. There is no algorithm trying to guess what you want to see — just the papers, organized by what is recent and relevant to your field.

Key features that stood out to me:

Clean feed — no algorithmic noise, just papers in order
Fast browsing — the UI gets out of your way
Focus on reading — the tool is designed for consumption, not configuration

Why Restraint Matters in Research Tools

There is a counterintuitive product lesson here. When building tools for knowledge workers, every additional feature is also an additional cognitive burden. The best research tools are not the ones with the most features — they are the ones that help you spend more time thinking and less time managing the tool.

Paper List"s restraint is its biggest strength. It does not try to be an all-in-one research platform. It does one thing — helping you discover and read papers — and does it well.

The Bigger Picture

I think we are going to see more tools adopting this philosophy. As AI makes it easier to build feature-rich products, the real differentiation will come from knowing what to leave out. Paper List is a good example of this principle in action.

If you do academic research and are tired of bloated discovery tools, it is worth checking out.

The Hidden Cost of Cloud Photo Management — And Why 4.7MB Matters

Daniel — Sun, 05 Jul 2026 03:55:46 +0000

Photo management apps are everywhere. But almost all of them share the same architecture: upload your photos to the cloud, process them on a server, and show you the results. It is the standard playbook. It is also wrong.

The Cloud Tax Nobody Talks About

When you upload photos to a cloud service, you pay three hidden costs:

1. Privacy is not a feature — it is architecture.
Cloud processing means your photos exist on someone else is server. Encryption at rest does not matter if the server needs to decrypt them to run ML models. The only way to guarantee privacy is to never let photos leave the device.

2. Latency kills the experience.
Uploading 2,000 photos over a 4G connection takes minutes, not seconds. Every analysis result requires a round trip. Users delete the app before the first result appears.

3. Storage and bandwidth are not free.
A 64GB photo library costs real money to store in the cloud. Most apps hide this behind "free trial → subscription" funnels. Users catch on.

The On-Device Alternative

Swipe Cleaner takes the opposite approach. 4.7MB total. No account. No uploads. All processing happens locally on the device:

Core ML for image analysis runs on the Neural Engine — faster than cloud inference for common tasks
Local storage only means no privacy policy nightmares, no GDPR compliance maze
Zero latency — the swipe decision happens instantly because there is no network call

The Numbers

Approach	App Size	Network Required	Privacy Model	First-Use Latency
Cloud-based	50-200MB	Always	Trust-based	3-10 minutes
Hybrid	30-80MB	Sometimes	Mixed	1-5 minutes
On-device	4.7MB	Never	Zero-trust	Instant

Why Developers Should Care

The industry trend is clear: Apple is pushing on-device ML harder than ever (Core ML 6, ANE improvements, on-device LLMs). Google is doing the same with MediaPipe and Gemini Nano.

Building cloud-first photo tools in 2026 is like building a desktop-only app in 2010. It works, but you are betting against the platform.

The 4.7MB number is not just a technical achievement — it is a design philosophy. Process where the data lives. Respect the user is device. Ship less.

What is your take? Are you building on-device or still defaulting to cloud? Drop a comment below.

The Photo Management Paradox: Why We Hoard and How Lightweight Tools Are Winning

Daniel — Sat, 04 Jul 2026 05:22:41 +0000

The Scale of the Problem

The average smartphone user has over 2,000 photos. 60-80% of phone storage is occupied by images, and most have never been viewed more than once. Screenshots, burst shots, and near-duplicates pile up silently.

But the real problem is not storage. It is decision fatigue.

The Psychology of Photo Hoarding

Deleting a photo feels like erasing a memory. Even screenshots trigger hesitation: What if I need this later?

The core insight most photo management tools miss: AI accuracy is not the bottleneck. Human psychology is.

Google Photos and Apple Photos spend billions on AI categorization. Yet users still accumulate thousands of untended photos. Knowing a photo is a duplicate does not make deleting it less painful.

The Tinder Model for Photos

Swipe Cleaner (4.7MB, fully offline, no account required) takes a radically different approach:

Left swipe = delete
Right swipe = keep

No folders. No tagging. No AI learning your preferences. Just rapid, instinctive decisions.

The Tinder-swipe UX turns photo cleanup from a deliberative chore into a muscle-memory action. Users clear 500+ photos in under 2 minutes.

Market Trend: Bifurcation

The photo management space is splitting:

Heavy AI (Google Photos, Apple Photos): Smart search, auto-curation but cloud-dependent, privacy concerns
Lightweight (Swipe Cleaner, Slidebox): Fast, private, zero friction

The lightweight camp is underserved. The sweet spot is wide open.

Why Privacy-First Is a Competitive Advantage

App size matters. 4.7MB installs in seconds on slow connections. Directly impacts conversion in emerging markets.
No account = instant trust. Zero-friction onboarding is the holy grail of mobile UX.
Local processing = zero regulatory risk. GDPR and CCPA do not apply when data stays on-device.

The Opportunity

The photo management market is enormous. Smartphone cameras produce larger files every year. Storage anxiety is universal. Yet solutions are polarized: full AI suites or nothing.

An indie dev shipping a focused, privacy-first, psychologically-informed tool can carve out a meaningful niche.

Conclusion

Photo management biggest unsolved problem is not technical but psychological. The winning tools will not have the best AI. They will make cleanup feel effortless.

Swipe Cleaner Tinder-swipe model is a strong signal of where the category is heading. Lightweight. Private. Instant. No thinking required.

This analysis was written as part of my daily research on product trends in the iOS ecosystem.