Can Your Internal Tool Become a Product Customers Will Buy?

• Your team using a tool is evidence of usefulness inside one company. It is not proof that another business will change how it works or pay for the product.

• Subtract the original company's people, data, rules and customer relationships. Whatever stops working without them is part of the commercialization problem.

• Research the job and the alternatives buyers already use. Another product may not be the main competitor. A spreadsheet, a staff member, an outsourced service or doing nothing can win.

• Interest is cheap. Commitment looks like real workflow access, usable data, named users, scheduled trial work and a concrete buying step.

• The first sellable product is one complete workflow for one customer type, not the internal tool with billing and a new login page.

• Onboarding, support, data separation and operating ownership belong in the decision before a rebuild, even when they stay manual during the first test.

• Approve one bounded experiment with continue, change and stop conditions. Do not approve the whole product because the next test looks promising.

Your team using a tool every day proves that it helps your company. It doesn't prove another business will buy it. Internal use tells you the workflow exists and that one company has learned to operate the tool. External demand starts when somebody outside that environment changes their behaviour, supplies real work and accepts a concrete next commitment.

That distinction is easy to blur because an internal tool begins with an advantage. It has users, data and a problem it already handles. It also has invisible support from the company that made it: people who know every exception, records in the expected shape and a process built around the screen. Commercialization means finding out which parts travel before paying to rebuild the parts that do not.

Open the tool beside the last real job it handled. For every step, ask what the software did and what the company quietly supplied. The second list is usually longer than anyone expects.

• People. Who recognised incomplete data, interpreted an exception, corrected the output or knew whom to call?

• Data. Which records arrived already cleaned, labelled or connected because your team has handled them for years?

• Process. Which approvals, workarounds and business rules live in habit rather than in the tool?

• Existing systems. What login, spreadsheet, inbox or back-office system supplies an input or receives the result?

• Trust. Does the customer act because the tool produced something, or because they trust the service company and the expert standing behind it?

A sellable product does not have to remove every dependency. It does have to make them explicit. You may discover that the real offer is software with onboarding, a productized service with a tool inside it, or a narrow workflow that connects to software customers already own. All three can be good businesses. Pretending they are the same business is what makes the first product scope unreliable.

Do not grade the code yet. A fragile internal build can still expose a strong customer problem, and a polished build can still have no external buyer. Product demand and technical readiness are separate questions. Settle the first one before using the second as a reason to rebuild.

Potential customers are not being asked whether your tool is clever. They are being asked to replace something that already gets the job done. Sometimes that is another product. More often it is a tolerated mix of spreadsheets, email, staff judgment and delay.

GOV.UK's user-needs guidance, published in 2016 and last updated in 2017, gives the useful research order: learn who likely users are, what they are trying to do, how they do it now and where the problems occur. It also says that suggestions not grounded in users should be treated as assumptions. The age of the page does not make this a current market statistic. It makes it a clear research principle.

Ask a prospective customer to walk through the last time the job happened. Keep the proposed product out of the first half of the conversation.

1. What triggered the work?

Find the event that made someone act. A customer request, a report due, a handoff, a failed check. A workflow without a recognisable trigger is hard to sell because nobody knows when to start it.

2. What did they use instead?

Follow every document, person and system. Ask what they already pay for, what they have tried and why the current approach survives. The strongest alternative may be familiar enough that the pain is cheaper than change.

3. Who owns the consequence?

The user feels the friction. The buyer controls the budget. The person accountable for the result may be somebody else. A useful interview with the wrong role can teach you the workflow and nothing about the purchase.

4. What would make them test a change?

Ask for the next action, not a prediction. Will they show a recent example, introduce the user, supply permissioned test data, schedule onboarding or take a pilot through procurement? Each step costs them something and therefore carries more information than enthusiasm.

A public first-person r/SaaS account from 2026 describes customers asking about an internal dashboard and the owner worrying that a second product would distract the company. It is one anonymous account, not evidence that this pattern is common. It is useful because it names the right tension: interest can be real while the operating case is still unresolved.

A compliment tells you the idea is understandable. A request tells you a feature sounds useful. Neither tells you what a buyer will replace, who will operate the change or whether the problem survives contact with their real data.

The sequence matters more than a universal pass mark. A long procurement process may produce a serious commitment before payment. A small owner may pay quickly and still need heavy founder support. Write down what action would change your decision, then ask for that action. Do not upgrade a polite conversation into demand after the fact.

The internal tool probably does several things because it grew beside the business. The first external offer should do one complete job for one customer type. Complete means the workflow has a trigger, the minimum inputs, a responsible user, a customer-visible output and a clear handoff afterwards.

Write it as one sentence: When [trigger] happens, [user] supplies [inputs], the product helps them [steps], and they finish with [output] that [next person or system] can use.

Then write the exclusions. No scheduling. No invoicing. No mobile app. No automatic decision where a qualified person must approve the result. The right exclusions depend on the workflow, but they must be visible. An internal tool can lean on adjacent systems because the team knows the boundary. An external customer needs to be told where the product stops.

This is also where you decide what not to automate. Manual workspace setup, guided import and direct support can be reasonable in an early pilot if they help test the buying and usage assumptions. Hiding manual professional judgment inside the product is different. If the original company's expert must make the core decision every time, the product has not yet become independent of the service.

Only after the workflow survives outside the company does a detailed build scope earn its place. The same rule applies to any software engagement: scope needs a written boundary before a number means anything.

A customer does not buy only the screen. They buy the ability to start, trust the result, get help and know who is responsible when the workflow fails. Those obligations exist before the architecture is final.

Do not translate data separation into an automatic order to rebuild as a shared SaaS platform. Microsoft's multitenant guidance, updated in June 2025, treats tenancy as both a commercial and technical choice and describes a spectrum from dedicated customer resources to shared infrastructure. The right choice depends on customer expectations, isolation, operating capacity and scale. A pilot can use a simpler boundary as long as access and responsibility are real rather than implied.

The operating owner is the hardest field to leave blank. A second product competes with the established business for attention, support and decisions. If nobody can own that work after the enthusiastic founder returns to the main company, stopping is more responsible than turning maintenance into an unassigned future problem.

Put the decision on one page. The goal is not to score the idea until it passes. The goal is to expose the assumption that should receive the next investment.

Continue when an external customer completes the bounded workflow, provides the access and ownership needed to run it and accepts a concrete commercial next step. Continue means another experiment, not the whole roadmap.

Change when the problem is real but the customer, workflow, delivery model or dependency is different from the first assumption. A change decision protects the opportunity from a premature product shape.

Stop when outside customers will not commit real work, the original company's people must make the core decisions, an acceptable alternative wins or nobody can own the product after the experiment. A stop decision preserves the internal tool's value. It does not declare the tool a failure.

This example is fictional. It is not a Rigoris client, case study, research result or claim about market demand. The assumed interviews and commitments exist only to show how the decision works.

An established commercial building inspection company uses an internal tool to turn field checklists and photos into a draft action plan. A senior inspector reviews the plan before it goes to the customer. The owner believes other inspection firms may want the same product.

The first research round finds a repeated external job. Four peer firms walk through a recent inspection. Two supply redacted examples. One offers a real workflow for a supervised trial. None has started a purchase process. The tool also depends on the original firm's inspection categories and on a senior inspector resolving ambiguous findings.

The decision is Change, not Continue and not Stop. Keep the current tool. Test one narrow workflow with the interested firm: its field inspector supplies the checklist and photos, the tool prepares the draft and its own supervisor approves the result. Scheduling, invoicing and customer messaging stay outside the test. The original company's senior inspector cannot edit the output.

The continue condition is an external supervisor approving a useful result, the firm naming an operating owner and the buyer accepting a paid-pilot or procurement next step. Change the product boundary if local rules need a setup service or the useful workflow is narrower than expected. Stop this direction if the external supervisor cannot finish without the original company's judgment, if no firm supplies real work or if the existing field-service setup is good enough once configured.

Nothing in that experiment requires a new SaaS architecture. It requires access boundaries, explicit responsibility and a customer doing real work. The architecture decision comes after the test has earned it.

Give the next decision a date. Over the next 30 days, recruit a small set of potential buyers who have recently done the workflow and can show it. Ask for the evidence that costs them something: a real example, the user, usable data, scheduled trial work and access to the person who can approve a purchase.

Put no more than two real external workflows through the narrowest version of the product. Guided onboarding and manual setup are allowed. The original company's hidden judgment is not. Record every question, correction, handoff and support request. At the end, decide with the conditions written before the test began.

• Continue if an external business completes the workflow, owns its decisions and accepts a concrete commercial next step.

• Change if the job matters but the buyer, boundary, onboarding or service layer is different from what you assumed.

• Stop if nobody will supply real work, the current alternative wins or the original company still has to operate the product for the customer.

If the uncertainty is still about the customer, the alternatives and willingness to change, the next work belongs in user and market research. If the workflow is proven and the question is what a first release must include, move into software discovery. Keep those decisions separate. It is cheaper to learn that the product should change before a rebuild than to make the architecture carry an assumption nobody tested.