Case Study 07. VizMarket, Regional Business Intelligence Directory
Industry: Data Products and Regional Commerce. Timeline: Approximately 2010 to 2025.
The Problem.
VizMarket was a deep regional data platform for Southwest Florida. It cross-referenced local businesses, the people who worked at them, and the commercial buildings they occupied, down to building-level detail like square footage and layout, which made it genuinely useful for real estate, sales, and market research. But it was also a complex, aging system, and valuable software that nobody can keep running is not much use to anyone. By the time it reached me, the platform had already cycled through several developers, each engagement ending for its own reasons, and the technology underneath it was only getting older and harder to maintain.
The Solution.
I was the fourth developer to take VizMarket on, and the one who stabilized it. For roughly fifteen years I kept a genuinely complicated legacy system running reliably through constant change. The architecture was a MySQL database behind a PHP interface, with APIs exposed for the applications and an admin section the owner used to enter and update data himself. It included full-text search built on Sphinx, the serious option of its day, well before Elasticsearch made that kind of search routine. On the front end were native iPhone and Android apps, both maintained on their app stores, along with advertising and, for a time, subscription integrations.
Keeping all of that alive was the work. The iPhone code predated Swift, the Android was aging Java, and the PHP and database schema had grown intricate over years of additions. Maintaining someone else’s complex legacy system, through platform updates and shifting requirements, without the luxury of rebuilding it from scratch, is a different and in some ways harder discipline than building something new. I held a small equity stake in the platform and treated its continuity as my responsibility.
The Outcome.
The most valuable thing I did for VizMarket was tell its owner when to stop. Eventually the cost of keeping the aging applications current outweighed what the platform returned, and pouring more development money into it no longer made sense. I gave the owner that honest assessment and helped him make the business decision to retire it, even though the platform was his life’s work and hard to let go of. We took it offline in 2025 after a long run.
I made sure it ended with the data intact rather than lost. The apps had already been pulled from the stores once we stopped updating them, and the old back end had aged to the point that the cloud provider itself eventually shut the instance down. I brought the database back up in a Docker container to extract it and the core of the application, so the owner kept the data he had spent years building.
Knowing when to keep a system alive, and knowing when its time is honestly over, are both part of the job. This engagement is where that lesson settled in for good: telling a client the true thing, including that something is not worth continuing, is worth more than the billable work of continuing it.