AddressUpdater

A Laravel app that kept an address book accurate by handing each record back to its owner. Contacts opened a private link, corrected their own details, and the finished list printed as mailing labels. It began as CS50 coursework and grew a dashboard, Google import and batch sends.
AddressUpdater

Built 2017 to 2018  ·  Status Retired  ·  Stack Laravel 5.5 to 5.6, PHP 7, MySQL, Blade, Twilio, Google People API, Amazon SES

AddressUpdater was a web application for keeping an address book accurate without chasing anyone down. Instead of emailing contacts one at a time to ask whether they had moved, I sent each of them a private link and let them correct their own record. The cleaned-up list then printed as mailing labels.

Purpose

Address books go stale quietly. People move, change phone numbers and abandon email addresses, and the only person who reliably knows any of that is the contact. The work of finding out falls on whoever keeps the list, and it is tedious enough that most lists simply stay wrong.

The first version started as coursework for Harvard's CS50, aimed at two chores at once: managing contacts, and generating mailing labels from them. The second version was a rewrite that pushed the same idea further, adding a dashboard, Google contact import and batch operations for email and text.

What it did

The core mechanic was the update link. Any contact record could generate a unique URL, and opening it let that person edit their own details and save them. The correction went straight into the address book with no retyping at my end. Those links went out individually or in batches, by email or by text message, so refreshing an entire list became one action instead of dozens of separate conversations.

Getting contacts into the system was the other half of the problem. It accepted CSV uploads with or without a header row, and it imported contacts directly from a Google account, which covered the two places most people already kept their contacts. Adding, editing and bulk deletion all ran from a single list view. Version 2 put a dashboard on top of that, reporting usage and how contacts were engaging with the update links they had been sent.

It was a Laravel application, and the admin side was built on AdminLTE.

Features

  • Share link gave each contact a unique URL where they could update their own information.
  • Batch email sent those unique update links to many contacts in one operation.
  • Batch text sent the same links by text message.
  • CSV import loaded contacts in bulk from a file, with or without a header row.
  • Google import pulled contacts straight from a Gmail account.
  • Batch delete removed multiple contacts at once rather than one at a time.
  • Address book listed every contact in one view for adding and editing.
  • Mailing labels generated printable label sheets from the current contact list.
  • Dashboard summarized usage and contact engagement across the account.

Impact

The honest scope here is small. This was a personal tool that grew out of a class assignment, it stayed in beta, and I have no usage figures to quote. What it did settle for me was the design idea behind it: the cheapest way to keep data accurate is to hand each record back to the person it describes, rather than trying to verify it yourself. I took the application offline and the hosting is gone.

Screens

The original write-up pointed at two GitHub repositories, one per version. Neither is public any more, so there is no code to link to.