Build it to run your business. Then find out if it's a business.
The most valuable software companies in the trades were internal tools first. That is not a coincidence — it is the only reliable path.
There are two ways to start a software company. In the first, you have an idea, you raise money, you build it, and then you go find out whether anybody wants it. In the second, you have a problem that is costing you money today, you build the thing that solves it, you use it, and then your competitors ask if they can buy it.
The second path is unfashionable and it produces most of the durable companies in operator-heavy industries. ServiceTitan was built by the sons of a plumber and a contractor for their parents' shops. Basecamp was 37signals' internal project management tool. Mailchimp was a side project inside a web design agency and sold for twelve billion dollars without ever taking venture capital.
What those have in common is not luck. It is that the first user was the builder, which eliminates the most expensive failure mode in software: building something nobody needs. When you are the operator, product-market fit is not a hypothesis you test. It is a fact you already have, for at least one customer, before you write a line of code.
The practical implication for an owner considering this is that you should stop trying to decide up front whether you are building an internal tool or a product. Build the internal tool. Build it well enough that it is genuinely better than the spreadsheet. Then look at three things: whether your peers ask about it, whether the problem it solves is common in your industry or specific to how you happen to run your shop, and whether the parts that make it work are transferable or are really just your process encoded in software.
If all three point the right way, you have a product and you built it with revenue instead of dilution. If they do not, you still have a business that runs better than it did, which was the point.
The mistake is the middle position: building something ambitious enough to be a product but not useful enough to be a tool, funded by money that has to come back. That is the version that fails, and it fails for reasons that have nothing to do with the code.