Choose a tool-shaped problem
A tool needs a defined input and useful output. A form that prepares an equipment checklist is a clearer starting point than a chatbot with unrestricted access to company files. Ask how the task is done now, who decides whether the output is correct and what a mistake would cost.
A quote-preparation tool might organize information for an estimator, calculate an approved price list or decide a custom price. Those are three scopes. Begin with organization and transparent calculation before delegating judgment.
| Candidate | Useful narrow version | Poor first promise |
|---|---|---|
| Inquiry helper | Summarize facts and identify missing fields | Qualify every customer perfectly |
| Knowledge search | Find passages in approved documents | Answer any company question |
| Proposal helper | Draft from an approved scope and rate sheet | Guarantee winning proposals |
| Reporting helper | Explain checked figures and flag anomalies | Predict the business accurately |
Validate demand with a manual version
Complete the task for a prospective user with permission. Record repeated questions and corrections. A customer who will not use the manually prepared result may not need software for it either.
Ask for a paid pilot or concrete buying criteria. “That looks interesting” does not establish willingness to adopt it, train staff or pay recurring fees. Include the actual user, not only the owner who likes the idea.
Define the operating contract
Write what the tool accepts, produces and refuses. Show “missing” for absent fields. Cite source documents when answering from business material and retain enough context for a person to check the answer.
Keep private client information out of demonstrations. Review the actual provider's data handling, retention and commercial terms before uploading records. A familiar brand does not establish the privacy settings of every plan.
Separate a proposed change from its execution. A CRM helper can display a proposed update for an authorized person to confirm. A review mechanism still needs permission checks and tests for failure, duplicate submissions and delayed responses.
Test more than friendly examples
Try misspellings, empty fields, contradictions, long text and irrelevant instructions. Check access from different user roles. If the model fails or the usage allowance runs out, explain the failure and preserve the user's work.
Keep a small evaluation set to rerun after changing a prompt, model or knowledge source. Include the difficult cases customers encounter. Three successful demonstrations do not establish reliable operation.
Work out the economics
Suppose a hypothetical customer pays $80 monthly. Model calls, hosting and supporting software cost $18; routine support averages one hour at your $35 internal labor target. That leaves $27 before other overhead, payment fees, tax and profit. An unexpected two-hour support problem could consume more than the month's remaining contribution.
Usage caps and support boundaries matter because cost can grow independently of revenue. Make's credit model is one example of why connected-workflow usage belongs in the estimate. Do not promise unlimited usage without understanding the expenses.
Deliver ownership and an exit route
Agree who owns the domain, customer data, configured accounts, source code and reusable work. Explain how the customer can export information and stop service. Identify third-party subscriptions separately from your fees.
For a first tool, a setup fee plus defined maintenance may be easier to explain than a broad subscription. Use our pricing guide and compare selling automation services.
Develop one example from input to accepted output
Imagine a fictional facilities company that needs a tool to prepare a site-visit briefing from an inquiry. The user pastes an approved inquiry and selects a service type. The output organizes facts, missing information and questions for the estimator.
Mock input: “We need shelves installed in a storage room. The wall is approximately 12 feet wide. We have not selected shelves. Access is available Tuesday afternoon.” The tool must preserve the uncertainty about materials and measurements.
A useful output might contain: “Requested work: storage-room shelving. Customer-provided width: approximately 12 feet, not verified. Materials: not selected. Access preference: Tuesday afternoon. Confirm wall construction, load requirements, exact dimensions and permission for installation.”
It should not calculate a structural load rating, promise a visit or create a final quote. Those would require different expertise and authorization.
The interface should display the source inquiry beside the briefing. Let the user correct a field before export. An obvious “information not supplied” state is better than making a sparse inquiry look complete.
Test with the person who will use it
Ask an estimator to complete several realistic cases, including incomplete and contradictory inputs. Observe whether the tool saves effort once review and corrections are included.
Acceptance might require that every briefing shows its source, labels customer estimates, keeps unsupported values empty and exports into the client's agreed format. The customer should also be able to identify a failed request and retry without losing the original input.
Keep an evaluation file with each input, expected facts, prohibited claims and the actual result. For the shelving example, prohibited claims include a guaranteed price, a verified load rating and a confirmed appointment.
A small test set cannot prove universal accuracy. It can expose important failures and give you a repeatable check when the model or instructions change.
Offer a pilot with a buying decision attached
An outreach example could say: “I build small internal tools that turn unstructured inquiries into reviewable job briefs. I have a fictional facilities example showing the original message, extracted facts and unresolved questions. A paid pilot could test whether this reduces your estimators' preparation work without producing quotes automatically.”
The next conversation should establish the actual user, approved data, current process and adoption cost. Ask what would make the client continue after the pilot. If nobody owns that decision, a technically successful demonstration may still go unused.
See getting your first clients for outreach and starting freelancing for a practical service agreement.
Make the handoff and support limits concrete
A first contract might cover one form, one approved output format, named user roles, a limited pilot period and one review round. Separate the build fee from hosting, model usage and maintenance.
Deliver the configured tool, source or export rights as agreed, account inventory, known limitations, test cases and instructions for updating approved reference material. Include a clear way to suspend use and recover the client's data.
For maintenance, distinguish defects in the agreed behavior from new features. Fixing an export that stopped working is different from adding invoicing, a mobile app or a second department.
Before final acceptance, have the client create a briefing, correct it, export it and locate the source. A product that depends on you silently fixing every output is still a service-heavy prototype. Price and describe it accordingly.
Frequently asked questions
Can a no-code tool be sold?
Yes, if relevant licenses permit the arrangement and it performs the agreed job. A visual builder does not remove your responsibility for reliability, privacy and support.
Do I own generated code?
Do not promise exclusive ownership solely because software generated it. Review provider terms, dependencies and licenses. The Copyright Office's AI analysis distinguishes human authorship from generated material.
Should I build before finding a customer?
A small demonstration can help. Validate the task and willingness to pay before committing to a substantial speculative product.
How much can I earn?
There is no dependable general figure. Acquisition, usage cost, maintenance and support determine profitability. Calculate your own unit economics rather than relying on revenue screenshots.
What happens when the AI provider changes?
Expect to rerun the evaluation cases and review pricing, behavior and compatibility. State who pays for maintenance and what happens if an underlying service is discontinued.
Sources and research notes
Source pages checked October 30, 2026. Worked examples are hypothetical; they are not observed earnings or guarantees.