Market Constraints

The assumptions you did not know you made

A product designed in a wealthy, well-connected market carries assumptions that are invisible until they break:

Each is a product decision to revisit, not a customer deficiency to work around.

Connectivity and devices

For AI products this bites harder than for ordinary software, because these products are inherently network-dependent — the model is not on the device.

Design for intermittence, not just for slowness. A request that fails because a connection dropped mid-generation should not lose the user's work. Save input locally, retry, and make it obvious what state things are in.

Mind payload size. Streaming helps perceived latency as module 5 said, and on a metered or slow connection the total bytes matter too. Sending a large document up and a long answer down is a real cost to a user paying by the megabyte.

Do not assume a large screen. A product designed around a wide interface with source documents beside the answer — module 2's verification design — needs a genuinely different layout on a small screen, and verification is exactly the thing that degrades when you collapse it.

Consider what works offline. Usually little for a model-dependent product, but the surrounding workflow can often continue: capture now, process when connected. That is a real design option and it changes which markets you can serve.

Price where unit costs do not fall

The hard commercial reality of this course's economics module in an international context.

Conventional software can price regionally almost at will, because the cost of serving a customer is near zero everywhere. An AI product cannot, because inference costs roughly the same regardless of where the user is — and as module 7.1 showed, it may cost more in languages that tokenise less efficiently.

So a product priced at a level that works in a high-income market may be unaffordable in a lower-income one, while a price affordable there may not cover the cost of serving it.

The available responses:

• A cheaper model tier for price-sensitive markets, accepting lower quality where it is acceptable — an honest trade if disclosed.
• Tighter usage bounds at lower price points, rather than the same product for less.
• A narrower product — fewer features, shorter outputs, less context — engineered to a lower cost per request.
• Serving through a partner who bundles it into something already being paid for.
• Deciding not to serve the market until unit costs fall.

The one that does not work is discounting the same product and hoping. That converts every new customer into a larger loss, which is the module 4 dynamic operating at national scale.

Choosing which markets to serve

A short screen, answerable before any investment:

1. Is the language well served by available models? Test it, do not assume.
2. Is there a compliant place to process the data? Module 6.
3. Is there acceptable latency from an available region? Module 5's arithmetic.
4. Does the unit economics work at a price the market will pay? Including the token multiplier.
5. Can we support and escalate in-market? Hours and language.

A market failing one of these may still be worth entering with a modified product. A market failing three is not a market you are ready for, and saying so early is far better than a launch that quietly underperforms and is blamed on marketing.