# The ugly macro that saved thousands of hours By Warren Pridgeon | Published 2026-07-13 | Category: Tech Canonical: https://warrenpridgeon.co.za/blog/the-ugly-macro-that-saved-thousands-of-hours --- Here's a story about the least impressive thing I've ever built, which also happens to be one of the most valuable. I look after the systems for a non-profit client, one of my very first clients in fact. Their first invoice was OrganiCode's 6th one ever and dates back to 2018 (the year OrganiCode started). Once or twice a year they bulk mail their whole database asking for donations. Responses to that appeal mail blast are recorded on a standalone webserver that has no direct connection to their main database (there are various reasons for this). When I started supporting them in 2018 I took over the system from another developer, who had taken it over from a previous one. There was no real documentation, for the first while whenever I needed to do something it was either crawl through the code or ask the previous dev how he'd done stuff (like the appeal mail blasts). For the appeal mail blast the process was: - Stage a bunch of data via various stored procedures and buttons clicked in the system - Click a button in the system that begins sending on a loop (I completely revamped this in later years as it would take basically a week to complete sending) - Every few days, pull a report off the response webserver and hand it over to the other staff to "process" The first year, I did it exactly like that. ## The question that changed everything The second year, I asked them what they did with the report. **Warren:** "Hey, what do you actually *do* with this data once I hand it over?" **Client:** "Oh, we go and update all the individual records through the system." That day, there were about 500 responses sitting in that report. I pulled out my trusty calculator and did some quick math. 500 * 5 mins = ... roughly 40 man-hours of work that needed to be done in a single day as the debit order run was the next day and all the records had to be updated before the debit order run. **Warren:** "Hold on... that's like 40 hours of work if it takes you five minutes per response." (5 mins per response is generous as it involves putting in the reference, hitting search, clicking the record, clicking an edit button, navigating to the debit order lines, editing the correct one) **Client:** "Yep. We normally put three people on it and work a twelve-hour shift just doing this." **Warren:** "NOOOOOOOO. Give me a few hours." Three people. A twelve-hour shift. Twice a year. Manually re-typing data from one screen into another, like a digital chain gang. And it had been running like that for years before I ever showed up. ## A few hours later I took that report dump and turned it into a VBA-macro-enabled... thing. Was it elegant? Did it solve world hunger and broker peace in the Middle East? Nope. Not even close. But it took a job that ate hours and hours of human time and turned it into a five-minute task. These days the whole process is: extract the report, drop it on the right server, hit "go." The macro does the rest. It works through the sheet row by row, finds the matching person, checks whether their response has already been processed, and updates the right records in the main system. Done. That one ugly spreadsheet has now saved them thousands of man-hours over the last few years. ## Is it impressive? Not even slightly Brutal honesty and transparency: it's basically a macro that iterates through a sheet, looks up some data, and runs a handful of if-statements and stored procedures. That's it. There's no clever architecture, no slick framework, nothing I'd put in a portfolio to make another developer nod approvingly. But I'm not here to impress other developers and inflate my ego by trying to prove that I'm a bright spark (I am so bright my father calls me son). I'm here to get stuff done and help clients get stuff done faster and more efficiently. Developers love to chase the elegant solution. The clean abstraction, the right pattern, the thing that would survive a code review with our arms folded smugly. And sometimes that matters. But it is so easy to forget who we're actually building for. The client doesn't care that it's a VBA macro held together with hope and if-statements. The client cares that three people got their twelve-hour shift back. The unglamorous truth is that the most valuable software I've written is often the least interesting to look at. Nobody (except me. HAHA) is going to write a conference talk about my donation-import macro. But it quietly hands a non-profit back days of human effort every single year, time and money they can pour into the actual mission instead of into data entry. THAT'S what gets me out of bed in the morning. ## The outcome is the whole point For me, the outcome the client receives is the most important part. Not the tech stack, not how clever the code is, not whether it would impress a stranger on the internet. The outcome. If the choice is between a beautiful solution that ships in three months and an ugly one that gives someone their weekend back tomorrow, I'll take the ugly one most days of the week. You can always make it prettier later. You can't give people back the hours they're losing right now. In many dev circles that's tantamount to heresy, but many devs never deal with clients directly... they only deal with their jira ticket list and their direct manager. The sad part about that is they very RARELY hear "this is amazing and it gives me back so much time" and hearing that kind of feedback scratches a kind of itch that silently marking a jira ticket as complete just doesn't. So if you take one thing from this: ask the question. "What do you actually *do* with this?" The previous dev said "this is how we do it", and I almost didn't question it. However, my brain is always on... always processing 20 things at once and making connections of things it often shouldn't... But on rare occasions it connects two things that make a bell ring. One question turned a twelve-hour slog into a five-minute click, and the only thing it cost was a few hours and the willingness to look slightly less clever. *Want the how, not just the why? I wrote up the technical case study on OrganiCode's blog: [How we turned a 12-hour, 3-person job into a 5-minute click](https://organicode.co.za/blog/manual-process-automation-case-study?utm_source=warrenssite&utm_medium=blog&utm_campaign=ugly-macro)*