I started my first company in 1998 with a $100-a-day equipment lease and a truck. By the time I stepped back from day-to-day operations, I had 40 employees, 12 field units running across Texas, and over $2 million in annual revenue. I did not set out to become a software developer. I set out to solve problems that were costing me money, and code turned out to be the best tool for the job.

That background shapes everything about how I build software today. Here are the things I have learned that I think most developers miss.

Software That Nobody Uses Is Worth Nothing

This sounds obvious, but it is the most common failure mode I see. A developer builds something technically impressive. It has clean architecture, good test coverage, follows all the best practices. And nobody uses it because it does not solve the actual problem the business has.

When I was running field crews in the oilfield, I needed software that a mud logger could operate at 2 AM on a drilling rig floor with diesel fumes and a bad attitude. I did not need elegant UX. I needed something that worked when someone was tired and the rig was making pipe. That constraint — real people in real conditions — changed every design decision I made.

Every project I take on now starts with the same question: who is going to use this, and what does their day actually look like? If I cannot answer that clearly, I am not ready to write code yet.

The Last 20% Is Where the Value Lives

Off-the-shelf software gets you about 80% of the way to what you need. The remaining 20% — the part that is specific to your industry, your workflow, your data — is where the actual competitive advantage lives. It is also the part that no generic tool will ever handle.

I built custom SCADA systems because the off-the-shelf options did not integrate with the specific instrumentation we used. I built dispatch software because no trucking platform handled the way our operations actually moved equipment. In every case, the custom solution paid for itself within months because it solved the exact problem instead of a general approximation of it.

When clients come to me saying they need a "simple app," I always ask what they are currently doing manually. The answer is usually a spreadsheet, a whiteboard, or a person whose entire job is moving information from one system to another. That manual process is the 20% that custom software eliminates.

Reliability Beats Features Every Time

On a drilling rig, if the monitoring software crashes at 3 AM, you have a crew standing around doing nothing while equipment worth thousands of dollars per hour sits idle. I learned very early that reliability is not a feature — it is the foundation everything else is built on.

I carry this into every project. I would rather ship something with fewer features that works every single time than something ambitious that fails under load. My clients are running businesses, not evaluating demo software. When they log in Monday morning, it needs to work. Period.

This also means I think carefully about infrastructure. I run my own Linux servers. I understand what happens at the operating system level when things go wrong. I am not just writing application code and hoping the platform handles the rest.

The Best Spec Is a Conversation

I have seen projects fail because someone spent two months writing a 40-page requirements document that nobody read carefully enough. Then the developer built exactly what was specified, and the client said, "That is not what I meant."

The best results come from short feedback loops. Build something small, show it to the person who will use it, listen to what they say, adjust, repeat. I learned this running a company where plans changed every day based on what happened downhole. You cannot predict everything upfront. You have to stay responsive.

As a solo developer, I can do this naturally. There is no telephone game between the client, a project manager, a team lead, and a developer. You talk to me, I build it, you see it. If something needs to change, we change it that day.

Understanding the Business Matters More Than the Tech Stack

I have worked in oil and gas, healthcare, legal, manufacturing, automotive, defense, transportation, and financial analysis. In every industry, the business logic is more complex than the code. Understanding why a home health agency schedules visits the way it does, or why a backflow testing company tracks compliance dates, or why a drilling rig needs to monitor lag depth — that understanding is what makes the software actually useful.

A technically skilled developer who does not understand your business will build you something that looks right but misses the point. I have been the person making operational decisions under pressure. I know what it feels like when the software does not do what you need it to do. That empathy is not something you can learn from a tutorial.

Ship It

The hardest lesson I learned in business was that done is better than perfect. I wasted months early on trying to get things exactly right before showing anyone. The reality is that the market will tell you what right looks like much faster than your own analysis will.

In software, the same principle applies. Get a working version in front of people quickly. The feedback you get from real usage is worth more than any amount of internal planning. I have built products — including a complete hardware and software instrumentation platform — and the version that shipped looked nothing like the version I originally designed. Every change was driven by what I learned from actual users.

If you are thinking about building custom software for your business, I am happy to talk through it. I have been where you are — running operations, dealing with problems that software could solve, trying to figure out whether custom development is worth the investment. The answer depends on your situation, and I will give you an honest assessment. Send me a message or call 903-339-5048.