Internal tool or SaaS product? Decide before you build

A founder at an illustrative regional logistics company builds a scheduling tool for their own dispatch team. It works well. A customer asks to use it. A competitor asks too. Within a month, a project that was meant to save the team four hours a week is being priced as a product. That jump is where many companies stumble, because the two are different jobs.

What changes when other companies use it

An internal tool has one customer, who sits down the hall. If it breaks, you walk over. If a field is missing, you add it on Friday. You can skip the sign-up page, because everyone is already added.

A SaaS product has many customers who never speak to you. They need to sign up on their own, get started without help, pay, ask for support, and trust that their data is not visible to anyone else. Every one of those is a feature, and none of them appears in the internal version.

A quick test

Answer these four questions honestly.

1. Who pays? If the answer is "the business, through savings", it is a tool. If the answer is "other companies, through a subscription", it is a product.
2. Who supports it? A product needs a support route that is not the founder's phone.
3. Does it need to work the same for different customers, or does each one want their own variation? If every customer wants something different, you are building consulting with software attached.
4. Is the idea defensible, or is it a feature of someone else's platform? Check before you commit.

If you can answer "tool" to three of four, build a tool and keep it simple. If you answer "product" to three, plan for a product and fund it as one.

The tool-first path is legitimate

Many good products began as internal tools, used by the company that built them until the shape was right. There is nothing wrong with that route, as long as you pick it on purpose. Build the tool for your own team first, and keep the code organized so that adding customers later is possible, not free. The next article, the tenant questions that are expensive to fix later, covers what to keep in mind.

The costs people miss

For a tool: ongoing changes as the process changes, plus someone who owns it when its builder leaves.

For a product: onboarding, billing, security reviews from customers, support, documentation, uptime commitments and a roadmap you can say no to. Budget for these before writing the first screen, not after the first customer asks.

Decide in a week

Write one page: who the user is, who pays, what you will not build in the first release, and what would make you stop. Share it with one person who has run a product, and one who has run a team that uses tools. Their objections are worth more than the feature list.

If the page says "tool", our web apps and automation practice builds those to be run by your team. If it says "product", we can help you size the first release before you commit to it.