I've lost count of how many small tools start with a sentence like this:

"Surely someone has already fixed this."

That was the thought behind LabelChop, a boring little desktop app for Australian sellers who use MyPost Business and 4x6 thermal label printers.

The problem sounds too small to be a product. MyPost Business gives you an A4 PDF. Your thermal printer wants a 4x6 or 100x150mm label. Somewhere between those two facts, people end up opening Acrobat, cropping, screenshotting, resizing, changing print settings, wasting labels, and swearing at a Dymo or Zebra printer.

I know. Not exactly glamorous SaaS.

But it was the kind of problem that kept showing up in the same shape. Sellers were not asking for an ecommerce operating system. They just wanted the stupid label to print correctly.

The workflow I wanted to remove

The old flow looked something like this:

1. Download the A4 PDF from MyPost Business.
2. Open it in Acrobat or Chrome.
3. Try to crop the label.
4. Find out the PDF tool does not quite do what you need.
5. Screenshot or export something.
6. Resize it to 4x6.
7. Open the printer dialog.
8. Pick the correct paper size.
9. Print it slightly off centre anyway.
10. Try again.

That is fine once.

It is not fine if you ship every day.

So the product became very narrow: watch a folder, detect the label inside the PDF, crop it to 4x6, and send it to the thermal printer.

No dashboard addiction. No warehouse suite. No pretending this is bigger than it is.

Just this:

Download MyPost label. Label prints.

The weird part was not the PDF

The PDF work was annoying, but predictable.

The harder part was getting the product shape right.

As a developer, my instinct was to make it more flexible:

• carrier integrations
• order imports
• batch workflows
• dashboards
• printer profiles
• shipping analytics
• maybe Shopify sync later

Some of those might happen eventually.

But the product got clearer every time I cut it back.

The first version did not need to solve shipping. It needed to solve the moment where a seller has a label PDF in Downloads and a thermal printer sitting next to them doing nothing useful.

That constraint helped more than any brainstorming session.

The stack

The app is a desktop utility built with Electron and Next.js.

A few bits under the hood:

• chokidar watches the selected folder
• pdf-lib handles PDF manipulation
• pdf-to-printer sends the output to the selected printer on Windows
• electron-store keeps local settings
• Supabase and Stripe handle accounts, trials, and billing

There is a web app too, but the core product is local. That matters because printing is local. The app needs to know about the user's printer, their Downloads folder, and the actual PDF that just arrived.

A browser-only SaaS would have been cleaner for me as a developer, but worse for the person trying to print labels.

That is the tradeoff I keep coming back to. The best architecture is not always the neatest one. Sometimes it is the one that sits closest to the annoying part of the workflow.

I made a free version of the pain first

One thing that helped was building a free tool before trying to explain the full app.

The free tool is here: A4 to 4x6 shipping label converter

It does the manual version. Upload an A4 shipping label PDF, crop it, download a 4x6 PDF, then print it yourself.

That is useful on its own, but it also makes the product easier to understand.

If you only need to fix one label, use the free tool.

If you do this all week, use the desktop app and stop touching the PDF at all.

That positioning felt much less forced than a normal landing page pitch. The free tool lets the user feel the problem and the fix in the same minute.

What I would do differently

I would have started with the smallest distribution asset earlier.

Not the app. Not the billing. Not the dashboard.

A page that says:

Convert a MyPost Business A4 label to 4x6.

That one page explains the product better than a feature list.

The lesson for me is that boring tools need boring distribution. People do not wake up wanting "shipping workflow automation". They search for the exact thing that broke:

• MyPost Business label too big
• print Australia Post label on Dymo 4XL
• crop A4 shipping label to 4x6
• 100x150mm label printer settings
• Australia Post thermal label printer

Those searches are not sexy. They are usually typed by someone already annoyed.

That is a good place to meet them.

The product is intentionally small

The pricing is small too: $9 AUD/month, $79/year, or a lifetime option.

That forced some discipline. At that price, the product cannot require handholding. It cannot have a sales call. It cannot need three onboarding sessions and a Slack channel.

It has to be obvious enough that a seller can try it, print a label, and decide if it saved them time.

That is the part I like about tiny utilities. They are honest. Either the label prints correctly or it does not.

The thing I keep learning

A lot of developer products are built around what is technically interesting.

This one was the opposite. The technical work only mattered because the workflow was irritating enough.

Nobody cares that the app crops PDFs.

They care that they no longer have to open Acrobat, resize a label, fight the printer dialog, and waste another sheet because the output was off centre.

That is probably the whole lesson.

If the problem sounds boring but people hit it every day, it might be worth building.

And if you can describe it in one sentence without saying "platform", you are probably closer than you think.

For this one, the sentence is:

LabelChop prints MyPost Business A4 labels on 4x6 thermal printers automatically.

That is enough.