A&A INSIGHTS
Home market only, or sell abroad? Payments, time zones, accountability
Whether to take English inquiries is decided not by translation effort but by which load lands - payments, time zones, accountability - plus how to count what you drop.
日本語で読む
THE STARTING POINT
Whether to take inquiries from outside Japan is decided not by the cost of working in another language, but by which of three loads actually lands on you: payments, time zones, and accountability. AI made producing text cheap; it did not make standing behind that text cheap.
Market scope is set by three loads, not by language
A&A perspective
Whether to take an inquiry from an English-speaking customer is not decided by the effort of putting your site and your replies into English. It is decided by which of three things actually lands on your side when you accept it: payments, time zones, and accountability. The three are not equal weights, though. Payments decides what work you have to add in order to accept. Time zones decides whether the response you promised has to be rewritten. And only accountability decides whether to accept at all. So the first thing to do is not to price out a translation or research a market size. It is to count, by type, the inquiries you are currently dropping.
From the sources
Stripe's article "Solo founding is at an all-time high", published on 28 May 2026, analysed thousands of solo-founded Atlas startups incorporated in 2022 and 2023, each with at least two years of revenue data, and compared middle-decile solo founders with those in the top decile by total revenue in their first two years. According to the article, in the first month top-decile solo founders sold into an average of 10 countries, versus just three for median solo founders. The gap widened over time: by month 24, top-decile solo founders were selling into 40 non-US countries on average, compared to six for median solo founders.
A&A perspective
Reading that number as an instruction to "sell into 10 countries" usually fails. Stripe is observing an outcome, not a procedure. The article does not test causation and does not claim that selling into more countries produced the revenue - but it does not label its own findings correlational either. Reading them that way is our judgement, not a caveat the article supplied. What remains is this: the number of countries sold into had already diverged in the very first month. In other words, this shows up as a question about initial design, not as an expansion question to revisit once the business is running. In this observation, leaving the decision unmade is itself the default choice.
"Should we sell abroad" is not one decision: the narrow axis and the wide axis
From the sources
In "Do Things that Don't Scale" (July 2013), Paul Graham writes that sometimes the right unscalable trick is to focus on a deliberately narrow market, comparing it to keeping a fire contained at first so it gets really hot before you add more logs. His example is Facebook: at first it was just for Harvard students, and in that form it only had a potential market of a few thousand people, but because they felt it was really for them, a critical mass of them signed up. This is the author's own argument, written from a 2013 vantage point.
A&A perspective
At first glance the two sources say opposite things. One observes that the strongest founders were selling into ten countries in month one; the other says that sometimes the right move is to stay deliberately contained. But they are talking about different axes. The narrowness Graham argues for is the customer segment: whose problem, and which one. The width Stripe observes is where the money settled: the location axis. Staying on a single narrow job, such as reading invoices, while accepting customers who have that job wherever they happen to live, satisfies both at once.
A&A perspective
That separation is not unconditional, though. Graham's own Harvard example is a narrowing of location as much as of segment. Where the value of a product comes from its users being in the same place, the two axes genuinely overlap. They come apart only where the value lies in completing one piece of work rather than in connections between users, and that is the only case this article addresses. The Stripe article itself also quotes a founder on focusing on being the best service in her specific niche, and reports that top solo founders were more likely to build for businesses. Nowhere does it tell anyone to widen their segment. So the disagreement is not between the two sources; it is between Graham and one way of reading Stripe's number as "sell wide".
A&A perspective
The real failure comes from moving both axes at the same time without separating them. A few English inquiries arrive, so the site is translated, the industry description is generalised, and Japan-specific assumptions are stripped out of the pricing page. What moved there was not only the location axis; the segment axis widened too. The "this is for us" feeling that the Japanese page used to create gets diluted. Our expectation is that the inbound from abroad can stop as well, for the same reason: it is no longer clear who the product is for. If you widen, widen the location axis only and keep the segment axis as narrow as before. That is a reading that satisfies both sources at once.
| Inquiry type | Loads that land | Settle before widening |
|---|---|---|
| Signs up self-serve; the user checks the output themselves | Payments only | Whether your existing payment path accepts a card issued abroad |
| You are asked to guarantee output accuracy or format fitness | Payments and accountability | Whether you can write what you do and do not guarantee in one English sentence |
| Delivery or operation premised on your own first check | Payments, time zones and accountability | Whether to rewrite the response you promised against their working hours |
| Arrives from an existing domestic customer's overseas office, same job | Time zones only, most likely | How far to extend the existing contract to their other locations |
| The job sits outside your segment | Does not enter the test | Prepare a sentence that declines, and still record it as a type |
What transfers to a Japan-based founder is not "how many countries" but "which market first"
From the sources
The same Stripe article reports that international sales accounted for 51% of revenue for top-decile solo founders, compared with 2% for median solo founders. It then explains that much of that difference came down to where founders were based: top-decile solo founders were slightly more likely to be located outside the US, so many sold into the US early. The article adds that since the US is often the largest and highest-spending market for software, selling there early can accelerate growth.
A&A perspective
This is the easiest point in the data to misread. Taking "51% international" as a target produces the conclusion that you should sell into as many countries as possible. But following the article's own explanation, that figure is largely the flip side of founders sitting outside the largest market. On that one point - being outside the highest-spending market - a founder operating from Japan is in the same position as the top decile. On another point they are not. Stripe's top-decile founders sat outside the US while holding a US company incorporated through Atlas, with the US bank account and payment acceptance the article lists as part of what Atlas provides. If you sell into the US with only a Japanese entity, that gap shows up as exactly the payments load described below. So the question that transfers is not "how many countries do we sell into" but "which market spends most on our particular job, and do we sell there early". The country count is not the target; it is a by-product that may or may not grow.
A&A perspective
This reading needs its limits stated. Stripe's population is solo founders who incorporated US companies through Atlas, so it does not describe what a Japan-based founder should expect when selling abroad. The article does not test causation and does not show that selling into more countries caused the revenue. Beyond that, the article is Stripe's own analysis of its own Atlas customer data, published by the Atlas product team in the context of recommending that founders incorporate through Atlas. It is not independently verified. And the only place the article explicitly mentions software is in describing the size of the US market; it does not address how the loads fall in service work with a person in the loop. We treat that difference as our own hypothesis, set out below.
Count payments, time zones and accountability as separate loads
A&A perspective
The first is payments. What matters here is not tax or currency design but one thing further upstream: does the money arrive without you touching it for each transaction? If your existing payment path already accepts a card issued abroad, the payment load does not land. If each one means raising an invoice, waiting for a transfer and reconciling the receipt, it does. How to set billing currency, minimum invoice amounts and tax registration is outside this article's scope; tax, contracts and export control are areas that need professional confirmation.
A&A perspective
The second is time zones. The question is not "can we respond in English" but "who is awake when it breaks". A self-serve product, where users configure it themselves and check the output themselves, works even with nobody awake at 3am. But where you have promised to make the first check yourself, in delivery or ongoing operation, the promise breaks the moment the customer's working hours land in the middle of your night. The time-zone load is set by the shape of the response you promised, not by the nature of the service. Widen the market without changing that promise and this is where it fails first.
A&A perspective
The third is accountability. When the AI output is wrong, who answers, in which language, under which contract and governing law? English copy and English specifications now take minutes to produce. What does not get produced is a party who answers for the content when it is wrong, under the contract and governing law of the customer's country. Payments gets lighter when you add a path, and time zones gets lighter when you change the shape of the promise, but this one stays blank unless somebody takes it on. That, in our view, makes it the only one of the three that AI does not lighten. In a self-serve product where users verify the output themselves, almost no accountability lands. Where you have promised accuracy or fitness, selling to a customer abroad means taking on not only the language but the interpretation of what exactly you guaranteed. Our recommendation is not to make inquiries of this third type your first step abroad.
Inquiries that arrive are not evidence that the market is there
From the sources
In the same essay, Graham writes that the most common unscalable thing founders have to do at the start is to recruit users manually, and that you can't wait for users to come to you, you have to go out and get them. He also says that while there may be a handful of startups that just grew by themselves, usually it takes some sort of push - startups take off because the founders make them take off. This is the author's argument as written in 2013, not a measured law.
A&A perspective
Applied to inbound from abroad, that argument means the English inquiries arriving on their own are weak evidence that the market exists. They are not the result of acquisition; they are spillover that happened to reach you. It follows naturally that the volume is small, and a small volume is equally not evidence that demand is absent. Using the count you received to estimate demand is a mistake. Those inquiries do have another use, though: they are a free sample that shows, in advance, which loads would land on your side if you widened. Read as types rather than as volume, they tell you whether yours is a payments business, a time-zone business or an accountability business, before you spend anything on translation. Useless for estimating demand; useful for estimating load. That is how we read them.
Count for four weeks first: the list of inquiries you dropped
A&A perspective
The record is one sheet. For four weeks, list every inquiry that arrived from an English-speaking customer, named, with the date, the type of counterpart and what was actually asked for. No estimates, no impressions. Then, for each row, fill three columns - payments, time zones, accountability - with nothing more than whether that load lands. In a fourth column, write in one line the work actually required to accept that type. Not an effort estimate: the name of the work. Check whether it fits into one of "add one payment path", "rewrite the response we promised" or "restate the scope of our guarantee in English". There is nothing special about four weeks, and it is not meant to smooth out seasonality. It is set as the minimum observation window needed to collect real counts rather than estimates.
Hypothetical example
A hypothetical example. It is not our own result and not any specific customer's case. Suppose a two-person company offering self-serve invoice reading in Japanese receives six English-language inquiries over four weeks: three from sole traders asking, after using the free tier, whether a paid plan is possible; two from accounting firms asking whether English invoice formats are supported; and one from a manufacturer proposing an integration build into their own system. Filling in the three columns, the first three land payments only - time zones and accountability do not, because users check the output themselves - and the fourth column reads "add one payment path". The next two land payments plus accountability, because somebody has to promise an answer about format-reading accuracy; their fourth column reads "restate the scope of our guarantee in English". The last one lands all three, with "rewrite the response we promised" in the fourth column. Read this way, the number of inquiries being dropped is six, but the number where accountability does not land is three.
A&A perspective
Base the decision on the three, not the six. The reason to widen is not that you are dropping a lot, but that some of what you are dropping is of a type where accountability does not land. Take only that type first. Do not take the two accountability cases and the one all-three case inside the same decision. Follow that order and widening becomes what it should be: adding one payment path without changing the response you promised. Decide on the total count instead and you end up rebuilding your whole response promise for the single heaviest case.
When not to widen, and the next step
From the sources
Graham writes that it's always worth asking if there's a subset of the market in which you can get a critical mass of users quickly. In a footnote to the same essay he adds that if you have to choose between the subset that will sign up quickest and those that will pay the most, it's usually best to pick the former, because those are probably the early adopters: they will have a better influence on the product and will not make you expend as much effort on sales. He then qualifies it: though they have less money, you don't need that much to maintain your target growth rate early on. This too is the author's argument as written in 2013.
A&A perspective
That test makes the case for not widening explicit. If your domestic segment has not reached critical mass yet, and you cannot explain in your own words why people bought, then widening the location axis only adds variance to a signal you cannot already read. Inquiries may rise, but you will no longer know which change caused what. In that situation, deferring is defensible even for inquiry types where none of the three loads land. Put differently, the test in this article is for someone who can already explain what is selling.
A&A perspective
The next step is not translation work; it is starting the four-week record. There are two conditions for widening. First, inquiries of the type where accountability does not land arrive repeatedly, from different counterparts. Second, the work in the fourth column fits inside "add one payment path" and nothing more. When both hold, add the payment path alone and leave the response you promised untouched. If the same type appears only once, it cannot be told apart from chance, so wait for the repeat. These two conditions are our proposal, not a measured standard. If the conditions do not hold, you have finally put your reason for staying domestic into words, and that is also a conclusion. If only accountability-landing types arrive, what may need to change is the shape of what you offer, not the market you serve.
Whether to limit your first market to your home country is decided not by translation effort or market size, but by which of payments, time zones and accountability lands on your side when you accept an inquiry. The three are not equal weights: only accountability decides whether to accept at all. Start by listing, over four weeks, the inquiries that arrived from English-speaking customers, named, filling three columns with whether each load lands and a fourth with the work required to accept. Widen when the type where accountability does not land arrives repeatedly from different counterparts and the work required fits inside adding one payment path. Stripe's country counts and international revenue share are Stripe's own analysis of solo founders who incorporated US companies through Atlas, published in the context of recommending Atlas: not independently verified, not a forecast for selling from Japan, and not a target. Graham's argument is his own, written in 2013. Separating the two axes, counting the three loads and the two conditions for widening are our proposals, not measured methods. Billing currency, tax registration, contracts and export control are outside this article's scope and need professional confirmation.
Sources & editorial note
Primary pages read for this article. Publication dates below belong to the sources; access dates record our research.
- Solo founding is at an all-time high: Top performers have these traits in common
Stripe · 2026-05-28
Accessed 2026-10-01 - Do Things that Don't Scale
Paul Graham · 2013-07
Accessed 2026-10-01
AI-assisted editorial production
A&A uses AI for research, writing, translation and editorial checks. Source facts, our analysis and hypothetical examples are labeled separately.
Editorial check: 2026-10-01