A market can contain millions of potential users and still offer a small builder no practical first customer. Another market can look modest while placing a specific buyer, a recurring task, and a feasible improvement within reach.
The distinction is between a market that exists in a presentation and a market a particular team can serve. A first application has to cross that distance with limited time, credibility, support capacity, and money.
This chapter of The AI Software Factory, in the SalarsNet AI section, asks how to choose an initial customer segment when broad opportunity and immediate feasibility point in different directions. It does not argue that small markets are always better. It examines what a first app needs to accomplish before market breadth becomes useful.
Market size is context, not a route to a buyer
A population count describes a group under a definition. It does not establish how many members experience your problem, can buy your product, or will adopt it.
The SBA separates demand, market size, reach, saturation, and alternative prices in its research guidance. A first-app decision benefits from preserving those distinctions. A broad population can coexist with weak demand for a particular improvement or a difficult purchasing process. Market research and competitive analysis.
Suppose a hypothetical builder wants to serve independent retailers. That label includes businesses with different inventory, staffing, sales channels, software, and purchasing habits. A count of all retailers says little about which ones repeatedly transform supplier files or need a better intake record.
Narrow the segment through the task. “Independent sellers receiving irregular supplier spreadsheets each week” is more actionable than “retail.” Narrow further when adoption conditions differ: which systems do they use, who controls the data, and who can approve a trial?
The resulting segment may be smaller on paper. It may also be the first one whose actual work the builder can understand. That understanding can support a credible promise without requiring a general platform for every retailer.
Your first app has several jobs
The first application should deliver a useful result. It should also teach the team whether it can attract customers, onboard them, support them, and receive enough value in return to sustain the promise.
A technically successful app can fail these other jobs. Users may require extensive setup. The buyer may expect immediate support at all hours. The sales process may consume more effort than a small subscription can support. A team may learn only that it can build a demo.
Choose the first segment partly for the learning it makes possible. Can the team observe recent workflow episodes? Can it measure a bounded outcome? Can it speak with the purchasing decision-maker? Can it learn from refusal without spending months in procurement?
These conditions do not guarantee a sale. They improve the chance that a small investigation produces a clear answer. An inaccessible segment can leave the team with an ambiguous result: perhaps the product is weak, perhaps the message is wrong, perhaps the buyer was never reached.
The opportunity score organizes competing candidates. This chapter concentrates on the strategic choice of a first segment and the obligations that choice creates.
Compare a reachable niche with a broad category
Consider two hypothetical applications. One is a general planning dashboard for small businesses. The other transforms a particular supplier’s files into the format used by a specific group of independent sellers.
The dashboard’s broad audience sounds attractive. Yet it competes with many habits and tools, requires a clear reason to return, and may need extensive explanation before a buyer recognizes its value. The file tool has a narrower audience and dependency risk, but its promised result is easier to show.
Neither is automatically superior. If the supplier changes its format constantly, the narrow tool may create expensive maintenance. If the dashboard solves a demonstrated urgent task and the team has a trusted distribution channel, it may be a sensible first app.
Compare the actual conditions instead of the labels. Which promise can be tested? Which buyer can be reached? Which input can be obtained legitimately? Which result can be reviewed? Which failure can the team support?
A narrow segment helps only when it reduces meaningful uncertainty. Choosing a tiny group with no budget, no accessible channel, and highly individual needs does not create an advantage merely because the group is small.
Reach the buyer with a credible offer
A list of email addresses is not the same as access to a buyer’s attention. A first conversation depends on a legitimate channel, a recognizable problem, and enough credibility that someone will explain their work.
Credibility can come from domain understanding, a useful sample result, a trusted introduction, or a clear bounded offer. It should not come from invented testimonials, exaggerated experience, or claims that the app will transform a business before its basic value has been tested.
A builder familiar with a particular workflow may have an advantage in identifying the right question. That familiarity still has limits. One business’s process does not establish that other businesses operate similarly or want the same solution.
A useful first segment is often adjacent to knowledge the team already has, while broad enough to test whether the pattern repeats. The adjacency can shorten discovery without replacing it.
The distribution test examines channels in detail. For segment choice, the practical question is whether the team can reach a few appropriate people ethically and learn from a specific offer. If that path is missing, include the access uncertainty in the decision.
Adoption can outweigh feature quality
A product that performs a task well can still be unattractive if receiving the benefit requires a disruptive migration. Customers compare the entire change with the current method.
A first app can reduce adoption work by fitting an existing handoff. For example, a file transformation tool might accept a copy of a current export and produce an inspectable result. The customer can compare it with the present workflow before granting live-system access.
A broader tool may require historical data, employee training, account permissions, and a new operating routine. Those conditions may be justified, but they make the first value harder to obtain.
Do not confuse easy adoption with superficial value. A tool that adds another dashboard without eliminating work may be easy to try and easy to abandon. The first useful result should connect directly to the customer’s task.
Also inspect the return path. Can the customer export their records, stop the trial, and resume the prior method? A clear exit can make a bounded trial more credible. It also forces the builder to understand which data and decisions the product actually owns.
Work out the support obligation
Small markets can contain demanding customers. Broad markets can sometimes support a standardized product. The relevant question is how much variation and exception handling the chosen promise creates.
For a hypothetical file tool, support may involve new columns, ambiguous identifiers, encoding errors, and customer-specific rules. If each case requires a developer to inspect private records and write custom logic, the product behaves more like a service.
A service can be appropriate. Price and delivery terms should reflect it. Problems arise when a builder sells a low-cost self-service subscription while privately assuming unlimited individual help.
Estimate support work during a bounded pilot. Record onboarding time, repeat questions, failed jobs, correction work, and issues caused by unclear product behavior. Distinguish one-time learning from work likely to recur for every customer.
The first segment should offer a scope the team can support. An early customer outside that scope may pay well while pulling the product into a different business. Decide whether that departure is intentional rather than letting the largest request define the roadmap.
Use a simple economic illustration carefully
Suppose an illustrative app charges $40 per month. Variable hosting and transaction costs are assumed to be $5 per customer, and average monthly support uses 30 minutes valued at an assumed $30 per hour. The illustrative contribution before acquisition and fixed overhead is $40 minus $5 minus $15, or $20 per customer per month.
If support instead takes 90 minutes, the same calculation becomes $40 minus $5 minus $45, or negative $10. A larger customer count would expand that negative contribution unless price, support work, or the promise changes.
These are hypothetical inputs, not current vendor prices, labor statistics, or Salars results. Their purpose is to show why a market-size claim cannot rescue an unfavorable delivery model.
The SBA presents break-even analysis as fixed cost divided by price less variable cost for a single product. Applying that structure to software requires identifying which costs vary with customers and which remain fixed; the simplified example does not replace a full operating model. SBA break-even guidance.
A first app should make these costs observable enough to improve the estimate. A paid pilot can reveal whether support falls as documentation improves or remains tied to unique customer work. That distinction can change the appropriate product and price.
Favor a segment that can teach you about repeatability
One accommodating customer can make a product appear ready. They may tolerate interruptions, explain unclear steps, and accept manual help because they know the builder.
A second customer tests a different question: which parts of the result depend on the first customer’s particular environment? Their files, habits, roles, and exceptions can reveal assumptions that the prototype never made explicit.
The first segment should contain enough similarity to make a common promise plausible and enough variation to test it. If every customer performs an unrelated task, learning becomes fragmented. If every trial uses the same friendly environment, generalization remains untested.
Choose a boundary around the task and conditions. The product might support specified file types, a defined sales channel, or a particular handoff. Explain those limits honestly. Expansion can follow evidence that the mechanism works under additional conditions.
The concierge MVP can help discover which parts of delivery repeat before automation. Segment choice determines whether that learning has a coherent place to accumulate.
Before generalizing, ask a new customer to complete the task without the creator explaining every step. Their difficulties can expose hidden training, unclear terminology, or assumptions about the input. A successful supported trial and a successful independent use are different observations. Both can inform the product, but they should be recorded separately.
This check also reveals whether the chosen segment shares a vocabulary. If apparently similar customers use the same word for different records, the app may need a clearer contract before it can serve them reliably. Narrowness on a market chart does not guarantee sameness in daily work.
A narrow start needs an expansion logic
A niche can be a useful beginning and a difficult destination. Dependency on one supplier, channel, or customer can limit bargaining power and expose the business to changes it cannot control.
Before committing heavily, consider how the useful capability might extend. A supplier-specific converter could become a small catalog of supported formats. An intake checker could extend to related item categories. A workflow aid could become a reusable capability used by several apps.
These are options, not forecast revenue. Each expansion brings new evidence requirements. A format that looks similar may use different meanings. A neighboring customer group may have a different buyer and adoption process.
Keep the first product’s promise focused while preserving architectural choices that do not unnecessarily prevent expansion. Do not build every imagined extension in advance. That spends money before knowing whether the initial mechanism matters.
A sensible expansion note names the adjacent task, what could be reused, what would change, and what evidence would justify moving. It should fit beside the first-segment brief rather than dominate it.
Watch for traps disguised as attractive niches
A niche with strong enthusiasm can still fail if the audience expects free software, if the task occurs rarely, or if the builder cannot reach the person with authority to spend.
A niche can also be too dependent on a third-party platform. If the proposed result requires access the platform does not provide, the business has an access problem rather than a coding problem. Verify the actual supported interface before promising the outcome.
Another trap is a customer group that requires extensive customization but resists service pricing. Their requests may require a separate project for each customer. The builder needs to recognize the delivery model and decide whether it can work.
An unusually large early buyer can create concentration risk. Their requirements may be valuable but incompatible with the broader segment. A team can intentionally build a custom service for that buyer; it should not describe the result as a repeatable product without evidence.
Finally, personal interest can substitute for demand. A builder may know and enjoy a domain while its current workflows already work well. Treat familiarity as a research advantage, then investigate whether a consequential problem exists.
Choose the first segment with a decision brief
Write a brief that identifies the customer, task, recent problem evidence, current alternative, buyer, access route, first useful result, adoption work, delivery limits, and largest unresolved risk.
Compare the preferred segment with a credible alternative. A choice is stronger when the team can explain why it rejected a broader or narrower option. The explanation should rely on evidence and current constraints rather than claiming that one market is intrinsically superior.
State the next commitment separately. The choice may justify a few discovery conversations, a bounded manual service, or a small prototype with sample data. It does not automatically justify a year-long platform build.
A useful stopping condition is specific to the segment. If the task proves infrequent and inexpensive, close the candidate. If the buyer cannot adopt the workflow, investigate a different result or segment. If the support burden exceeds the price the buyer will accept, revise the delivery model or stop.
Preserve the brief after the decision changes. Later results can reveal which assumptions were wrong and which lessons transfer to another candidate.
What Would We Do at Salars?
A proposed Salars first-app choice would favor a task that operators can describe, records can support, and a bounded trial can improve. Candidate areas might include supplier-file transformation or intake-record checking; these are suggestions, not measured current needs.
The team would compare the reachable task segment with a broader application idea using actual buyer access, adoption work, input variation, and likely support obligations. A large market estimate would provide context without substituting for those conditions.
The first trial would seek a useful result for a small, defined group and record the delivery work honestly. If the result depended on custom service, the proposal would be priced and scoped as a service. If common inputs and exceptions emerged, a reusable software capability could become justified.
Expansion would remain conditional on evidence from additional customers and tasks. The team would not claim that one successful internal workflow proves a general market.
The best first app is the one whose promise a particular team can test and responsibly deliver. Market breadth becomes valuable after the business learns how to cross the distance to a customer.
Sources
- U.S. Small Business Administration: Market research and competitive analysis, official guidance distinguishing demand, reach, saturation, alternatives, and pricing.
- U.S. Small Business Administration: Calculate your startup costs, official break-even and cost guidance.
Sources inspected October 7, 2026. App comparisons, costs, and Salars choices are hypothetical or proposed. No market-size measurement, paid pilot, or support-cost experiment was executed for this article.
Loading comments…