Why I built GrowX

GrowX began as a weekend project to scratch my own itch. I wanted a Chrome extension that lived in my browser, used the session I was already logged into, and never sent my data to a server I didn't control. The unfollower tracker became the feature I used most, so I want to explain how it works conceptually.

How an unfollower tracker works

The core idea is surprisingly simple: you can't ask "who left?", but you can compare "who was here before" with "who is here now."

1. Periodic snapshots

Every so often, the extension reads your follower list and records it as a snapshot: basically a set of user IDs (plus handles for display). I store IDs rather than handles, because people change their usernames all the time, and a handle-based diff would report false departures.

2. Local storage

Each snapshot is saved in the browser using chrome.storage.local or IndexedDB. Nothing leaves the device. This was a deliberate design choice. A follower list tied to your account is personal data, and I didn't want to run a backend that holds thousands of people's social graphs. Keeping it on-device also meant I had no servers to pay for, which matters when you're a student.

3. Diffing

Once I have two snapshots, finding who left is a set difference:

const previous = new Set(oldSnapshot.map(u => u.id));
const current = new Set(newSnapshot.map(u => u.id));

const unfollowers = [...previous].filter(id => !current.has(id));
const newFollowers = [...current].filter(id => !previous.has(id));

That's the whole algorithm. Everything else is plumbing: handling pagination, remembering when each snapshot was taken, and showing the results in a readable way. I also keep a short history so you can see the trend over weeks instead of only the latest change.

4. Pacing and rate limits

Reading a big follower list means many paginated requests. If you fire them all at once, you'll hit rate limits fast, or make your account look strange. So the extension spaces out its requests with small randomized delays, reads in modest batches, and backs off when it sees a rate-limit response instead of retrying harder. It also doesn't need to run constantly. One snapshot a day is enough to catch changes, and the snapshot can pause and resume if it gets interrupted partway through.

5. Edge cases

A few things tripped me up:

• Suspended or deactivated accounts vanish from the list and look like unfollows. I flag these separately when I can.
• Partial reads are dangerous. If a snapshot stops halfway because of an error, diffing it against a full one would report hundreds of fake unfollowers. I only save a snapshot after the full list was read successfully.
• Very large accounts take longer to read, so progress has to be saved as you go.

Lessons learned

Start with the data model. Choosing stable IDs over handles saved me from a whole category of bugs.

Fail loudly and save nothing on failure. A wrong result is worse than no result. People trust a tracker only if its numbers are right.

Privacy is a feature, and also a simplification. Doing everything locally removed accounts, servers, and a lot of legal worry in one decision.

Go slow on purpose. Being gentle with request pacing made the extension more reliable, not less. Speed was never the goal.

Ship the small version. My first release was ugly, but it worked, and real feedback shaped everything after it.

Wrapping up

Building this taught me more about browser extensions, storage, and defensive programming than any course did. If you want to try the tracker, it's part of GrowX (https://www.growxapp.org), and you can install it from the Chrome Web Store: https://chromewebstore.google.com/detail/growx-unlimited-auto-foll/ofiancichfcakbdgekhcahflpoglfgbh

I'd love to hear how you'd improve the approach. Thanks for reading!