DEV Community: Leon

Building a Browser-Local Moving Checklist Without User Accounts

Leon — Thu, 10 Sep 2026 03:27:47 +0000

Many planning tools begin with sign-up, cloud storage, and collaboration features. For a moving checklist, I wanted to test a narrower idea: can a useful planning tool work without requiring an account?

MovePlaybook is a browser-based moving checklist. A user starts with a move date, reviews a generated task plan, adjusts tasks when circumstances change, and can print or save the plan as a PDF.

The technical constraint was privacy: the product should remain useful even when the plan is stored locally in the browser. That shaped several decisions.

First, task identity needs to be stable. A user may complete, reschedule, hide, restore, or annotate a task, so those changes must attach to a durable task ID rather than a display position.

Second, temporary hiding must not mean deletion. A hidden task is excluded from the active checklist and PDF, but it remains recoverable through a dedicated Hidden view.

Third, schedule changes need explanations. When a user adjusts a date, the interface should distinguish between a recommended date, a tight timing window, a conflict, or something the user must confirm locally.

The product is available at https://moveplaybook.app/

I built it as a practical experiment in local-first planning. I would be interested in how other developers approach versioned browser storage, printable application state, and explainable scheduling rules.

How to convert a folder of PNGs to one PDF without uploading the files

Leon — Sat, 05 Sep 2026 12:48:21 +0000

A simple browser-local PNG-to-PDF workflow

For this kind of job, the useful workflow is straightforward:

Select the PNG, JPG, or JPEG files.
Put the pages in the order they should appear.
Choose a page size and margins if the document needs them.
Export one PDF.

The important detail is where the conversion happens. A browser-local PNG-to-PDF tool processes the images in the browser instead of uploading them to a conversion server. That makes it easier to keep control of source files while still producing one shareable PDF.

When this is useful

This workflow is handy for:

combining screenshots into a bug report or handoff document;
turning scanned pages into one file for email or printing;
arranging portfolio images or design exports in a deliberate order; and
collecting receipts or reference images without making a separate document first.

Before exporting, check the page order and decide whether each page should match the image, A4, or US Letter. A preview is useful here: it catches a stray portrait page, an oversized margin, or a screenshot in the wrong position before the PDF is created.

The tool I use for this

I maintain PNG Binder, a free PNG-to-PDF converter for this specific workflow. It accepts up to 50 PNG, JPG, or JPEG images, lets you arrange them, and creates one PDF locally in the browser. It does not require an account, and the images are not sent to a conversion server.

It creates an image-based PDF, so it does not perform OCR or rebuild text and tables. If that is the kind of result you need, try it and let me know whether page ordering, page settings, or browser compatibility could be improved.

Disclosure: I am the maker and operator of PNG Binder.

A small privacy decision that changed my web calculator

Leon — Thu, 03 Sep 2026 10:00:20 +0000

I built Calculator Toolkit for a narrow moment: someone has a restaurant bill, wants to check the tip and tax math, then needs to split the total with a few people.

At first I treated the no-account requirement as a small feature. It turned out to be the decision that shaped most of the interface.

A saved-history feature would be convenient. It would also mean sign-in, account recovery, data retention, and an extra decision for someone who only wants to settle a dinner bill. I decided that the calculator should run locally in the browser instead. There is no account and no bill-data upload.

That creates constraints. A person cannot return tomorrow and recover an earlier calculation. There is no dashboard where an unclear result can be explained later. The current screen has to do the work. It needs to make the bill amount, tax, tip basis, total, and each person's share understandable before the group pays.

I found that this was less about adding a privacy notice and more about removing places where the product could hide complexity. If the calculation is temporary, the result needs to be legible now. If somebody changes the tip basis, the change needs to be obvious. If one diner pays a different share, the total still has to add up.

I do not think local-only is a universal rule. It is a poor fit for products where history, collaboration, or handoffs are the reason people use the product. For a one-off restaurant calculation, it felt like the more honest default.

I am Leon, the maker of Calculator Toolkit. I would like feedback from other developers: when you remove accounts or saved state from a small tool, which parts of the interface become harder to get right?

Disclosure: This article was drafted with AI and reviewed by Leon.