TrackYourPack

Package tracking, shortened to TYP. It supported InPost and nothing else, which was the decision the whole thing rested on, and it had two front ends: an Android app and a terminal client.

one carrier, on purpose#

Every tracking app is an aggregator. Paste any number, we support forty carriers.

The problem with forty carriers is that supporting them means finding the subset of information all forty can provide, which is roughly: in transit, out for delivery, delivered, exception. Four statuses and a timestamp. That's the intersection, and the intersection is nobody's actual experience of a delivery.

InPost isn't shaped like that. It's parcel lockers — the useful questions are which locker, is it there yet, which compartment, how long before it goes back. None of that survives being flattened into a status enum that also has to describe a courier van. Supporting one carrier meant the app could be about the parcel locker rather than about the abstraction over parcel lockers.

It's the same instinct as building School Tinder as one Next.js codebase instead of a frontend and an API: the general version costs something real and immediate, and the reasons to pay it — here, users on other carriers — were reasons I didn't have. I only used InPost. So did everyone I'd have given it to.

two clients, and the one I used#

The Android app came first — Android Studio, written in Java. The terminal client came after it and was fully Kotlin.

The terminal one is the one I actually used, and in hindsight it's the one that should have existed first. Package tracking is a lookup: you have an identifier, you want a status, you want it in under a second. On a phone that's unlock, find the app, wait for a splash, wait for a list to load, read one line. In a terminal it's a command and a line of output, and I was already in a terminal.

That's not a general claim that CLIs beat apps. It's specific to this: the interaction is one query and one short answer, with no browsing and nothing to manage. A GUI adds navigation to something that has nowhere to navigate to.

Writing both is also how the difference became obvious. Same data, same carrier, same person — and one of them I opened daily while the other sat on a home screen.

the last of the JVM work#

Java on Android, Kotlin in the terminal, and the end of the run that started with BeePack and the obfuscator. After this the work moved to TypeScript and mostly stayed there.

Kotlin is a good language and this isn't a story about growing out of it. It's just that what I wanted to build next was on the web, and the web has an obvious answer.

why it stopped#

Same year it started, and the honest reason is that it solved a problem I'd already mostly solved.

Tracking a package is a thing you do for about four seconds, a few times a month, and the carrier's own app already does it. The terminal client was genuinely better for the way I did it — but "better at something you do for four seconds" is not a gap anyone else was going to switch over, and I'd built the thing I wanted on day one. After that there was nothing left to add that I'd have used.

Both scope decisions were still right. If I'd built the forty-carrier version it would have taken ten times as long to reach the same conclusion, and the Android app is the part I'd skip if I did it again — which I only know because I built it.