What running my own business taught me about tech decisions

Before I advised businesses on technology, I ran one. I built and operated my own e-commerce company, selling products nationwide from a website I built myself. I was the developer, and I was also the person paying the bills, answering for the outages and deciding what we could afford.

That combination changed how I look at every technology decision. A developer can recommend a tool because it's elegant. An owner has to ask what it costs, what happens when it breaks, who keeps it running and whether the business is better off with it than without it. Those are different questions, and the second set is the one that decides whether a business stays healthy.

This is the owner's half of the idea in every web problem eventually becomes a systems problem. The system isn't just technical. Money, time and risk run through it too.

Every tool is a recurring cost

When you're the one paying, you notice something that's easy to miss from the outside: almost nothing in tech is a one-time purchase.

A new plugin needs updates. A SaaS subscription renews every month whether you used it or not. An integration needs someone to notice when it fails. A feature needs to be tested every time something around it changes. Even a free tool costs time to learn, configure and keep working.

So I stopped evaluating tools by what they do and started evaluating them by what they cost to keep. The questions I ask now:

• What does this cost per month, and what will it cost when we grow?
• How much of someone's time does it take each month to maintain?
• What else depends on it, and what happens to those things if it goes away?
• If the vendor raises prices or shuts down, how hard is it to leave?
• Does it replace something, or just add to the pile?

That last question matters most. Tools that replace something reduce your total surface. Tools that only add to it make everything a little heavier.

Reliability beats features

When your own revenue depends on a website, you learn fast that a checkout that works every time is worth more than any new feature. Customers don't give credit for clever. They leave when something is broken, slow or confusing.

That lesson made me skeptical of complexity for its own sake. Every new moving part is another thing that can fail at a bad moment. A simpler system that works consistently usually beats a richer one that works most of the time.

In practice this means:

• Fewer dependencies, even if it means building a small thing yourself or doing without.
• Changes tested before they go live, not after a customer finds the problem.
• Monitoring on the things that make money, so you hear about a failure before your customers tell you.
• Backups you have actually restored at least once, not backups you assume work.

Cash and time are the real constraints

Large companies can absorb a bad technology decision. A small business often can't. Money spent on a tool that doesn't pay off is money that isn't available for inventory, marketing or payroll. Time spent fighting a fragile system is time not spent selling.

That's why I pay close attention to when costs land. A tool that's cheap to start but expensive to leave is a different kind of risk than one that's expensive up front but easy to replace. A custom build might cost more once and less every month after. A subscription might be the reverse. Neither is automatically better. What matters is whether the business can carry the cost pattern comfortably.

Time works the same way. An owner's hours are the scarcest resource in the building. Any system that needs the owner's attention to keep running is quietly expensive, no matter what the invoice says.

Somebody has to own the outcome

The biggest thing I took from running my own company is that someone has to own the result, not just the task.

When I was the owner, there was no one to hand the problem to. If orders stopped, I had to figure out whether it was the site, the payment processor, the email notifications or something else entirely. That forced me to understand the whole chain from visitor to order to fulfillment, because a gap anywhere was my gap.

In a lot of businesses I've seen, each vendor owns a piece. The web developer owns the site. The agency owns the ads. Someone else owns the CRM. Everyone does their piece correctly, and the business still loses leads in the gaps between them, because nobody owns the path end to end. That's a structural problem, not a talent problem.

How this shapes the advice I give now

Running a business is why my recommendations tend to look practical rather than impressive. A few things I bring into every engagement:

1. Start from the business objective, not the tool. What are we trying to change in the business? Then find the least complicated way to change it.
2. Price in ownership, not just the build. Updates, hosting, subscriptions, monitoring and staff time all belong in the estimate.
3. Prefer fewer, sturdier pieces. Choose the simplest architecture that will still scale. Remove before adding.
4. Measure the thing that matters to the owner. If it isn't measured, you're guessing, and guessing with a small budget is expensive.
5. Automate only what's stable. Automation that breaks silently is worse than a manual step someone actually watches.
6. Name who owns the end-to-end result. If the answer is no one, that's the first thing to fix.

Mistakes owners make, and I made too

• Buying tools to feel productive. A new subscription feels like progress. Often it's another bill and another login.
• Deferring maintenance until something breaks. The emergency always costs more than the upkeep would have.
• Letting a vendor hold the keys. Your domain, hosting, analytics and ad accounts should be in the business's name, with the owner holding admin access.
• Assuming someone else is watching. If you haven't confirmed who gets alerted when the site goes down, assume no one is.

The owner's lens

Running my own company gave me a filter I still use on every decision: would I spend my own money on this, and would I want to be the one maintaining it a year from now? If the answer to either is no, there's usually a simpler option. If you want to talk through a decision like that for your own business, you can reach me here.