An internal script compares two supplier files and flags margin changes. The owner knows which columns matter, repairs an unusual input and interprets the result. A colleague suggests selling the tool. The useful calculation is real, but much of the product still lives in the owner’s knowledge and access.
Commercialization requires proving that an outside customer can obtain the promised result under a separate account, clear terms and a maintained operating boundary. Internal usefulness is evidence about one workflow. It is not yet evidence of external demand, safe tenancy or sustainable service.
This article closes a practical transition in The AI Software Factory. Service to software examines standardizing a repeatable service. Turning knowledge into software examines maintainable rules. Here the question is the readiness delta between a useful private tool and a commercial SaaS obligation.
Inventory the knowledge surrounding the tool
An internal user may know which source files are trustworthy, which supplier names are aliases and which discrepancies deserve attention. The code may assume all that knowledge without representing it explicitly.
Observe the entire internal task. Record input preparation, interpretation, manual correction and the final decision. A screen recording or case ledger can reveal work that the function’s successful return value does not show.
Separate stable rules from business-specific conventions. A date parser may generalize. A supplier mapping unique to one account may need customer configuration. A judgment based on a private relationship may belong with the user rather than in a global model prompt.
The first commercial artifact may be a clearer specification, not a public signup page. That is progress because it defines what an outside customer would need and what the provider would owe.
Validate an outside job before building outside access
Find a prospective customer with the relevant problem and examine a consented workflow. Does the internal result support the same decision? Are the input conditions comparable? Does the customer already have a satisfactory alternative?
A useful private tool can address an idiosyncratic need with little outside demand. Naming a broader market does not establish that other people share the owner’s pain or will pay to solve it.
A concierge MVP can test the result manually with an explicit scope. Record the assistance and exception work. A founder-supported pilot is evidence about that service path, not proof of self-service readiness.
Ask for a consequential commitment appropriate to the stage. A supplied sample, scheduled review or paid bounded pilot can reveal more than praise. Each still needs scope and does not establish broad product-market fit.
Choose a supported variation boundary
External customers bring different formats, terminology, volumes and expectations. Decide which variation belongs in the first product and which requires another path.
A proposed supplier comparison might support one export format with required identifiers and currency fields. It might reject ambiguous identifiers and request a correction. That narrow boundary can create a complete useful product if it solves the intended customer’s job.
Avoid allowing every pilot exception to become a mandatory feature. Record frequency, value and delivery burden, then choose which variation deserves support. A one-off customization may be a separate service or a reason to decline the account.
Make the boundary visible in the offer and readiness check. Outside customers should not learn that their format is unsupported only after paying and sharing sensitive files.
Replace ambient internal trust with explicit identity
An internal tool may assume that anyone reaching it belongs to the same trusted team. Commercial service needs a defined account identity, authenticated users and roles appropriate to the job.
Authentication establishes who is presenting a request. Authorization determines whether that identity may perform the requested action on the specific resource. Do not treat a successful login as permission to inspect every report.
OWASP’s object-level authorization guidance describes the risk of manipulating object identifiers and calls for checks on the requested action and object. An unpredictable identifier alone is not the authorization boundary.
A proposed release test should include one account attempting to read, modify, export and delete another account’s resources. Passing a few cases is scoped evidence, not a complete security certification, but these denial cases are essential to the commercialization question.
Trace tenancy through background work
Tenant isolation extends beyond the page request. A queued job, stored file, generated report, support view and export all need the correct account context.
Bind the account identity when work is created and validate it again at relevant access boundaries. A worker should not accept a tenant identifier from untrusted input as sufficient authority. The tool or service layer must enforce the relationship.
Caches deserve particular care. A result reused across accounts may reveal private data even if the underlying calculation is similar. Reuse should preserve the data and authorization boundary, not merely match an input filename.
Test the full path with distinct synthetic accounts and distinguish production validation from a local exercise. The proposed app needs evidence about isolation under its actual architecture before handling outside private data.
Remove internal credentials and private fixtures
An internal repository may contain broad tokens, example files from real operations or configuration that assumes one privileged account. Commercializing it requires an explicit credential and fixture review.
Use safe representative data for tests and demos. Do not carry a private supplier report into a public sample because it made the first script convenient to verify. Consent and the actual data-use boundary apply independently of the tool’s usefulness.
Separate development, test and production identities. Scope credentials to the resources and actions required. Agent security treats coding agents as contractors; the same principle applies when they help prepare the commercial version.
Record who owns rotation and revocation. A token that remains hidden from the interface can still create broad authority. The product’s read-only claim must be enforced by the integration and tools, not merely described in the sales copy.
Design onboarding for someone without the owner nearby
An outside user needs to understand readiness, input preparation, validation and the first accepted result. Internal shorthand and undocumented repair steps should become clear product behavior or an explicit service boundary.
Test onboarding with a person who has not seen the tool. Ask them to complete the supported job and explain what the result means. Record where assistance is required rather than quietly supplying it and declaring the flow self-service.
Time to value defines the first accepted outcome and its start event. For commercialization, compare assisted and unassisted paths and retain failures in the evidence.
A sample can orient the buyer, but it should not conceal the customer’s own input requirements. A polished sample report is a demonstration, not proof that the buyer can obtain the same useful result.
Turn implicit responsibility into an offer
The internal owner can make a private business decision with the tool. An outside customer needs to know whether the service prepares evidence, recommends an action or executes a change.
State the accepted result and the decision the customer retains. A proposed supplier report might identify changed costs and unresolved matches while leaving purchasing decisions with the merchant. It should not promise increased profit without suitable evidence and attribution.
Material terms should address included scope, charges, support, cancellation, data use and exit. The actual arrangement and applicable jurisdiction require appropriate review; this article proposes an operating checklist rather than a universal contract.
Keep the offer, interface and billing consistent. A plan promising an accepted report should not charge for every failed internal retry without a clear agreed policy. A read-only promise should not quietly gain publishing authority later.
Build metering around the commercial obligation
An internal tool may not need customer billing, usage allowances or payment-failure behavior. A commercial app needs records that explain what was purchased and delivered.
Pricing architecture compares subscriptions, usage, seats and outcomes. Choose the customer unit before implementing the meter. A convenient internal event may not be a fair billable event.
Record stable operation identities so duplicate submissions and delayed events can be reconciled. Keep resource cost distinct from customer charges. A provider retry can create expense without creating a new customer obligation.
Test the customer view. Can the buyer predict an ordinary bill, inspect usage and understand a credit? Does cancellation stop the intended future charge? Billing behavior belongs in product acceptance, not only the payment integration’s unit tests.
Establish support as a maintained workflow
An internal user can ask the owner directly and share context informally. Outside support needs a channel, service window, account-safe evidence and a way to resolve the original problem.
Provide useful job references and failure states. Support should not routinely request full private files when an operation identity and safe diagnostic information can answer the question.
Define the boundary between product assistance and custom consulting. Help correcting a product error differs from interpreting an unsupported business case. Clear terms let the customer choose the relevant service rather than negotiate it after failure.
Record support and manual exceptions in the economics. A commercial product can be viable with human assistance, but the price and operation should acknowledge that delivery model.
Make exit and deletion real product paths
Outside customers may need to export work, cancel service and request deletion. An internal script’s folder structure is not automatically an adequate commercial exit path.
Design exports that preserve useful records and their context. Explain which results remain readable outside the app and which integrations or live features do not transfer.
Privacy design traces collection, retention, processors, logs and backups. A deletion claim must match those actual paths. Do not promise instant removal of every copy if the system retains backups under a stated schedule.
Test exit before public growth. A customer should not need the original developer to assemble an ad hoc archive, and an export must not cross account boundaries. The offboarding path is part of the product the buyer accepts.
Replace private recovery with an operating process
An internal owner may repair a database manually after a failed run. A commercial service needs a controlled response that preserves customer work and authority.
Record accepted state, unresolved jobs and external effects. A code rollback may not restore changed data or undo a completed third-party operation. Recovery should identify the customer’s remaining obligation, not merely restore the interface.
A proposed drill can include an interrupted import, a lost acknowledgment and a corrected result. Use safe test accounts and distinguish the exercise from proven production recovery.
Assign maintenance and incident ownership. The SaaS obligation continues after the first sale, including dependency updates, integration changes and support. A tool with no available owner is not ready for a maintained commercial promise.
Decide whether to share a platform or isolate a product
Internal capabilities can support more than one app, but shared infrastructure creates shared failure and update obligations. Decide what should be common and what needs independent state, access and release control.
GitHub’s repository-template documentation describes copying structures and files into a new project. That copy does not automatically receive future fixes; a template-created project starts with its own initial history rather than becoming an update subscription.
Track the template version and inherited components. A security correction in a shared starting point needs a way to identify affected products and review the update. Copying faster can multiply maintenance if the dependency relationship is lost.
Build capabilities, not apps addresses reusable contracts. Commercial readiness asks which inherited promise the specific app actually enforces and who owns it after the copy.
Make commercialization a gated commitment
A readiness review should end in a concrete decision: continue internal use, offer a bounded assisted pilot, release a narrow commercial version or stop. It should not treat every useful script as destined for SaaS.
Keep eligibility separate from preference. Missing isolation, unclear rights to data or no maintenance owner can block a commercial release even when the idea looks attractive. A weaker sales forecast may instead justify a smaller experiment.
State the evidence required for the next commitment and its budget. A proposed unassisted onboarding test or paid pilot can answer a specific uncertainty. Do not demand evidence that only a later stage can produce, or use that absence to justify skipping essential boundaries.
Preserve counterexamples. A pilot customer who succeeds only through extensive founder work is not proof of self-service. A customer who pays but cannot obtain the accepted result is not a successful product validation.
Test volume beyond the private owner’s ordinary use
An internal workflow may run once a week with a small known file. Commercial customers can submit simultaneous jobs, larger supported inputs and repeated requests. The product needs a stated resource boundary and evidence appropriate to its promised workload.
A proposed capacity review would include ordinary supported work, the upper supported size and concurrent accounts within the intended first-release scope. It would examine accepted outcomes, queues, failures and cost rather than a vendor’s advertised scaling alone.
Set safe limits before opening access. A job rejected with a clear explanation can be preferable to an unbounded request that consumes the service or blocks other accounts. The commercial terms should describe meaningful limits without forcing buyers to understand internal runtime quotas.
Surface assumptions that are obvious only inside the business
The internal owner may assume one currency, one timezone, one supplier identifier scheme and one authority model. Outside customers can differ on each. Decide which assumptions remain fixed in the first offer and which become explicit configuration.
Do not silently interpret an unfamiliar date or amount in the owner’s preferred format. Validate or request clarification when the difference affects the accepted result. A wrong but polished comparison can be harder for an outside user to detect than an honest rejection.
Document supported conditions alongside representative examples. The goal is not to generalize every possible variation before launch. It is to make the chosen boundary understandable and enforceable so outside use does not depend on hidden familiarity with the founder’s business.
What Would We Do at Salars?
For a proposed Supplier Margin Guard internal tool, we would first record the full private workflow and identify the knowledge the owner supplies around the code. Supplier Margin Guard remains a proposal; no implemented internal tool, customer base or measured margin benefit is asserted here.
We would test one outside customer’s bounded job with consented or safe representative inputs. The pilot record would preserve assistance, exceptions and a consequential commercial commitment. A useful result would justify the next investigation, not automatically a public launch.
Before commercial private-data handling, we would review tenant identity through requests, jobs, files, reports, support and exports. The accepted offer would state read-only preparation, supported formats, billing treatment and the customer’s remaining decision.
A proposed readiness review would also examine unassisted onboarding, cancellation, deletion, recovery and maintenance ownership. If those obligations exceeded the available operation, we would keep the capability internal or offer an honestly priced service rather than call it ready SaaS.
The transition is complete when an outside customer can understand, obtain and leave the service under a promise the provider can maintain. The broader AI collection connects that readiness decision to the venture engine’s next resource commitment.
Sources
- OWASP: Broken object-level authorization — action-and-object access checks; unpredictable identifiers do not replace authorization.
- GitHub: Creating a repository from a template — copied project structure and history distinction; no automatic update inheritance.
Loading comments…