Case study
Contact record extractor
Parses several thousand irregular contact records out of one text file into a clean spreadsheet, keyed on a repeating delimiter rather than on absent fields.
Overview
Not one script. A small family of browser-based tools built and maintained for one client across three contracts, all doing the same underlying job: pulling usable contact records out of exports that were never designed to be parsed.
The first took a text file of several thousand entries with no consistent layout and turned it into columns. What followed came from using it: an address validator, a suppression-list tool that removes anything on a REMOVE list from a MASTER list, and a second extractor for an older export format whose field names had changed years earlier.
Complexities tackled
There were no fields, only a repeating boundary. Entries had no consistent labels, ordering or line count. The one reliable signal was that each record began with an opening bracket. The parse keys on that boundary and infers each record’s shape from what falls between them, rather than expecting a format the data never had.
The client’s own data was mislabelled and he knew it. In the legacy export, phone numbers sat in the email column and names sat elsewhere, the result of a form that had been collecting into the wrong fields for years. He did not want it corrected, he wanted it extracted verbatim so he could sort it separately. Building what was asked for rather than what looked correct was the right call: silently repairing the data would have destroyed the only signal he had about which records were affected.
Small tools still need a revision policy. After the first delivery it became clear these would each attract a run of small changes. Rather than quoting per change, the price was set once to cover the revisions, with the alternative offered explicitly: a lower price and a charge for every subsequent tweak. Naming that choice up front is what stopped a five dollar tool becoming an argument.
Delivered as web pages, not scripts. Each tool was put behind a URL the client could open and use, rather than something he had to install or run. He was not going to run Python, and a tool that requires a developer to operate is not finished.
Stack
Python behind a browser interface, reading text and spreadsheet exports, writing CSV.
Working on something similar?
Tell me what you are building and what is in the way. I will tell you honestly whether I am the right person for it.