The same engineering team can work on an internal scheduling tool and a device- control application licensed to customers. The cost route turns on product purpose and customer rights, not the developer, repository, or programming language.
The scope memo records whether the software is sold, leased, licensed, or otherwise marketed, how customers receive it, whether a cloud service changes the analysis, and which maintenance obligations remain. Only then does the technological-feasibility clock become relevant.
A future marketing idea is not automatically external-use scope, and a cloud delivery label does not answer whether the customer receives software or a service. Missing contract and product-plan facts produce a stop condition.
Apply the distinction
External-product scope starts with what customers receive and how the software is marketed. A product plan, contract, and delivery model must support that route before the technological-feasibility window can affect any cost.
Authority
Read ASC 985-20-05-2 for the cost model for software to be sold, leased, or marketed.
Put the concept to work
Apply this concept
- Use supplied product purpose, customer rights, marketing, delivery, and maintenance facts to establish or withhold the external-use software scope conclusion.
Learning resources
Choose a lesson, try an application, or inspect the sources behind this concept.
Build on these ideas
- Internal-use software — Apply
To apply this concept: Helpful. Contrasting internal and external purpose prevents technology labels from deciding scope.
Lessons
Worked examples and cases
Practice
Common mistaken ideas
Sources
Standard references
Broader topics
More specific topics
Related concepts
Use this idea next
- Technological feasibility — Analyze
Required level here: apply. Required. The threshold belongs to software within the external-product scope.