Most IT problems don't announce themselves.
There's no error message, no crash, no moment where the system visibly fails. The business just runs slower than it should. More people than necessary. More hours than necessary. The same friction, every week, that everyone has learned to work around without questioning whether it should exist.
The following five signs are a self-diagnostic. You don't need to score 5 out of 5. Three is enough to warrant a serious look.
1. Someone Is Doing Something by Hand That Feels Like It Should Be Automatic
The specific version varies by company, but the pattern is always recognizable.
Copying data from one system and typing it into another. Generating the same report every Monday morning by pulling numbers from three different places and pasting them into a spreadsheet. Re-entering an order from the e-commerce platform into the accounting system because they don't connect. Sending a manual confirmation email because the system doesn't do it automatically.
These tasks usually take 30–60 minutes each. They happen multiple times a week. They are never urgent enough to fix and never small enough to ignore. They are automation debt, and it accumulates silently until someone actually counts the hours.
Count the hours. If one person spends 90 minutes a week on a task like this, that's roughly 75 hours a year — nearly two full working weeks — on something that a properly configured system would handle without human involvement. I've seen this exact dynamic at Pikkuna, where order processing consumed 15–30 minutes per order until full automation reduced it to under two minutes with zero manual steps.
2. One Person Knows How a Critical System Works
You probably know exactly who I'm talking about.
When that person is on vacation, there's a moment of mild anxiety every time something unusual happens. When they get sick unexpectedly, someone has to figure out where things stand. If they were to leave the company, there would be a problem that wouldn't be solved quickly.
This isn't a people problem. It's an architecture problem. Critical systems shouldn't live inside one person's head. The knowledge of how things work — the exceptions, the workarounds, the reason the billing process has that extra step on the third of the month — should be documented, transferable, and not dependent on anyone's continued employment.
Single points of failure in IT are manageable risks when they're acknowledged and planned for. They become expensive problems when they materialize without warning.
3. Your "Database" Is a Spreadsheet
Excel and Google Sheets are genuinely excellent tools. They're also the most consistent indicator that a business has outgrown its infrastructure without realizing it.
When the customer list is a spreadsheet, the inventory is a spreadsheet, the order history is a spreadsheet, and the pricing table is a spreadsheet — you don't have four databases. You have four systems that have no way to talk to each other, that will eventually disagree with each other, and that can each only be used by one person at a time.
The fragility isn't obvious until it matters. The spreadsheet works fine until two people edit it simultaneously and one person's version overwrites the other. It works fine until someone sorts a column without selecting all columns and the data is now silently mismatched. It works fine until the person who built the formulas is no longer there to explain what they do.
This isn't a criticism of spreadsheets. It's a recognition that a spreadsheet doing a database's job is a workaround, not a solution — and workarounds have a carrying cost that grows with the business.
4. Your IT Projects Always Cost More and Take Longer Than Planned
One project that runs over budget and timeline — that's a project. Two — possibly a coincidence or a difficult vendor. Three in a row is a structural problem.
Either the planning process doesn't work (scope is defined too loosely, requirements shift without anyone tracking the implications), or the vendors or developers you hire can't estimate honestly, or there's no one on your side managing technical scope and catching when it drifts.
Most small businesses don't have a technical person in the room when they're agreeing to a project scope with a vendor. This means the vendor defines what's in scope, how it's measured, and what counts as done. That's not a dynamic that favors the client.
When every IT project surprises you with costs, the surprise is the symptom. The cause is usually that nobody is representing your interests on the technical side of the conversation. Technical due diligence before you sign — or before you start a rescue — is exactly where that representation matters.
slug="fractional-cto"
text="If your IT keeps surprising you with costs and no one is accountable for the whole picture, I step in as a fractional CTO or IT partner — owning technical direction for growing businesses that have outgrown ad-hoc solutions."
/>
5. The "Fix It Later" List Is Over a Year Old
Every business has one. The list of technical things that need attention eventually — the integration that doesn't quite work right, the process that has an unnecessary manual step, the system that should be replaced, the security thing that's been on the agenda since last spring.
When "eventually" becomes 18 months, those items are no longer on a to-do list. They're permanent fixtures. The team has adapted to them. New employees learn the workarounds as if they're standard procedure. The original problem is forgotten; the workaround is now the process.
That list is a balance sheet of technical debt. Every item on it is accumulating interest in the form of wasted time, increased risk, or reduced capability. The longer it sits, the more expensive each item becomes to address — both because the workarounds compound and because the people who remember why the original problem existed keep moving on.
What to Do With This
You don't need a perfect score to have a problem worth addressing.
Three of these applying to your business means IT is a structural cost, not just an operational inconvenience. The question isn't whether to fix it — it's what to fix first, in what order, and who should be responsible for the outcome. If you're not sure who owns that answer, that's the first problem to solve.
If three of these sound familiar, let's talk. An honest look at your IT usually surfaces more opportunity than risk.