Most small businesses do not run on the software you would expect. They run on one spreadsheet.
It has macros in it. It was written years ago, probably by someone who has since moved on. There is a tab nobody fully understands and everybody knows not to delete. And every day, quietly, it produces the file the rest of the operation waits on.
On my custom web apps page I list five symptoms that usually mean a business has outgrown its tools. The one I see most often is this: “A spreadsheet is doing the job of a real application, and people are afraid to touch it.” This is a story about what that looks like when the spreadsheet is holding up a label factory.
A wholesale label manufacturer in Tempe
Star Graphics is a wholesale label manufacturer in Tempe. Wholesale means the output is physical product going out to other businesses — not a dashboard somebody checks when they get around to it. When the day’s file is what the next step is waiting on, “we’ll sort it out tomorrow” is not a real option.
It is a long-running engagement, and it is the one I point to when someone asks what “ongoing infrastructure stewardship” actually means in practice. But it did not start as stewardship. It started as an emergency.
It started as an emergency
Most engagements I take start with thirty minutes on the phone, a written scope, and an hours estimate. This one started somewhere else. The description on my clients page is plain about it: the engagement “started as an emergency spreadsheet migration.”
In 2023 the macro-enabled workbook the daily process ran on stopped being usable. Not corrupted, not deleted — the file was still right there. It simply could no longer be opened and run by the people who needed it, and the macros were the process.
That is a worse problem than it sounds, because there is no error message to search for and no vendor to escalate to. The file exists and does nothing. Meanwhile the orders do not stop arriving, and every hour the process is down, work stacks up behind it.
What I can say generally is that these calls all have a similar shape. Nobody phones a consultant because a spreadsheet is inelegant. They phone because the thing that worked fine for years stopped working on a day it needed to work, and there is no obvious person to call — no vendor, no support line, no documentation. The system is load-bearing and undocumented at the same time.
What a spreadsheet becomes when it runs a business
A spreadsheet with macros in it is not a bad tool. It is a bad foundation, and the difference only shows up under load.
A real database has types and constraints, so a quantity cannot quietly become a date. A real application has logins, so you know who changed what, and a version history, so a bad change gets rolled back in a minute instead of reconstructed from memory. It has somewhere to put an error, so a failure announces itself instead of producing a slightly wrong file that nobody notices for two weeks.
A macro-driven workbook has none of that. It usually also has one more property that matters more than all the technical ones: exactly one person is comfortable opening it. That is not a software problem. That is a business-continuity problem wearing a software costume.
The Star Graphics workbook was not a single-purpose tool. It was doing four jobs at once, all of which belong in software:
- Aggregating orders. Hundreds a day, arriving continuously from a large national customer, needing to be collected and made sense of as a batch.
- Invoicing. Getting those orders into QuickBooks and associated with the right records, so the accounting side reflected what actually shipped.
- Tracking numbers. Taking FedEx tracking numbers, matching each one back to the order it belonged to, and pushing that association back into the customer’s own system keyed by order and tracking number.
- The daily outbound file. Applying custom business logic and emitting a file in the exact layout a trading partner requires.
Any one of those is a reasonable thing to ask a spreadsheet to help with. All four, at hundreds of orders a day, with the accounting system and two outside parties depending on the output, is not a spreadsheet job. It is an application that happened to be wearing a spreadsheet.
Their own server
Part of the same engagement was hosting. They were on a shared-hosting setup that was hanging about once a week. A server that hangs weekly is not a hosting inconvenience; it is a recurring operational fire.
So one piece of this was not an application at all. It was a properly-configured Virtual Private Server (VPS) — their own machine, their own configuration, with monitoring in place and deployments scripted.
I would defend doing the hosting layer early on any project: building a nice web portal on top of hosting that hangs weekly just means you have a nicer thing to be down. That unglamorous layer looks about the same everywhere. What follows is the general playbook off my hosting page, not a description of what was scoped here:
- A server that is yours, tuned for what you actually run
- Auto-renewing SSL, so nobody discovers an expired certificate the way customers usually discover one
- Automated backups — with restores actually tested, because a backup is theory until you have restored from it
- Scripted deployments, so a change goes out the same way every time
- Monitoring, so somebody hears about a problem before the customer does
Portals and databases instead of macros
The workbook logic came apart into pieces that belong in software. The line on the clients page is deliberately plain: I replaced finicky spreadsheet macros with web portals, databases, and other automations.
“Finicky” is doing a lot of work in that sentence, and it is the right word. Macro fragility is rarely dramatic. It is a column that got inserted, a regional date format, a cell pasted as text, a file left open on someone’s machine. Every one of those is a five-minute fix and a half-day of figuring out what went wrong first.
Moving that into a database and a web portal does not make the business more complicated. It makes it more boring, which is the goal. That is what any move from macros to a portal and a database buys you, whatever the screens end up being: data goes in through a form that validates it, lives in tables other things can query, and more than one person can be logged in at once. The logic that used to hide inside a macro nobody wanted to open now lives in code I can read, change, and put back.
Concretely, that meant a portal where the order flow lives: incoming orders land in a worklist, get worked through step by step, and carry a history you can look at afterwards. Tracking numbers get matched to orders there rather than in a macro. The export runs from the same data instead of from whatever happened to be pasted into a tab that morning. And because it is a portal with logins, more than one person can be in it, and you can see who did what.
The daily file
This is the part that people outside manufacturing tend to underestimate.
A lot of business-to-business relationships come with a data obligation attached. You do not just ship product; you also ship a file, in a specific layout, on a specific cadence.
Orders arrive continuously from a large national customer. A file goes out daily to a trading partner on the other side of the operation, in a layout that is theirs and specific to how they run, with custom logic deciding what belongs on it. The daily volume is in the hundreds of orders, and the file goes out by email on a schedule — nobody presses a button.
Meanwhile the tracking numbers go back the other way: matched to their orders and pushed into the customer’s system automatically, which is the part that used to be somebody’s afternoon.
What I will say is that “formatted to spec” is never as simple as it sounds. In my experience these specs come down to a pile of small, unforgiving rules — column order, exact header text, a date format that is not the one you would choose, fixed-width padding, a delimiter, a filename pattern with the date in it. Miss any one of them and the file is rejected on the other end, usually with an error message that does not tell you which rule you broke.
Getting that right once is the easy part. Getting it right every single day without a human involved is the thing that changes how a business feels.
The part that never ends — and that is the point
Here is the part I did not fully appreciate early in my career: the export automation was not the deliverable. Staying current with it is the deliverable.
Formats change. The other side adds a column, renames a field, tightens a validation rule, or switches systems entirely. When that happens, an unmaintained integration does not degrade gracefully — it just starts failing, and the business finds out from the party that did not receive the file.
The third bullet on the Star Graphics card is the one that describes the relationship ever since: ongoing on-call updates to match changes in our customer’s data. When the format moves, I move the code. It is usually not a big job. The value is not in the size of the job; it is in the fact that nobody at Star Graphics has to own it, chase it, or even notice it most of the time.
Set it, forget it
Thomas Harty put it better than I could, so here it is in his words:
“Joey stepped in and revamped our daily business flow. He migrated us to our own server, automated the daily file generation, and stays on top of it whenever our customer’s format changes. Years in, I don’t think about our infrastructure anymore — which is exactly what I wanted.”
— Thomas Harty, Star Graphics Inc.
That last sentence is the one I am proudest of, and not because it is flattering — it barely is. It describes an absence: a category of worry that used to take up space in an owner’s head and now does not.
That is the actual product. Not the portal, not the database, not the export script. The product is that the people who run a label company get to spend their attention on running a label company.
If this sounds like your shop
I am based in Tempe, and most of my local work has been across the East Valley and greater Phoenix. The pattern in this story is not specific to labels, though. It shows up in print shops, distributors, fabricators, and anyone else who has to send a formatted file to a larger partner on a schedule. The tells are consistent:
- One workbook produces something the business genuinely depends on
- One person is comfortable opening it, and their vacation is a risk item
- Someone exports a file from one system every week and uploads it to another
- A partner’s format changed once and it cost you a day, or a customer
- Your hosting has gone down more than once and nobody on staff knew where to start
None of that means replacing everything. It means moving the fragile parts into software one at a time, in an order where the business keeps running the whole way through.
If you have a spreadsheet like this one — and if you felt a small twinge reading that sentence, you do — it is worth talking through before it becomes an emergency call. You can see what I build and run, or email me at support@techefficientllc.com — there is a “Schedule a free consultation” button on the home page as well. I reply within a day. The first conversation is thirty minutes with no deck attached, and if it turns into work, pricing is hourly with a clear estimate up front.