A company we know signed what looked like a great deal in China in 2022. Clean terms, reasonable numbers, a sensible product. By the second half of the following year they wanted to push the same business into Singapore and the US. That was when they discovered the contract did not specify what happened to data ownership across borders, that the core codebase’s copyright sat on two entities at once, and that the founders’ stake in a Delaware C-corp did not line up with the shareholding structure of the onshore WFOE.
None of that is a legal problem. It is an architecture problem that has been there from day one, dressed up as a contract problem until the moment you try to go cross-border.
This piece is for two audiences: clients who are buying from us, and clients who are thinking about it. I want to describe one specific thing. Every deliverable we ship — from the SOW to the codebase to the database schema to the trademark filing list — has already passed through what we call, internally, the legal filter. This is not a free legal service. It does not replace your outside counsel. It is something more basic. The architecture we give you has room for you to go cross-border when you decide to.
What the legal filter actually does
It isn’t “show the contract to a lawyer before it gets signed.” It is that by the time we’re drawing the first system diagram, four things are already on the table at the same time.
The first is where the data lives. China has PIPL §41 on cross-border transfer of personal information, DSL on classification of important data, and CSL on the extra obligations that attach to critical information infrastructure. Europe has GDPR Chapter V on cross-border transfer rules. The US works sector by sector — HIPAA for health, GLBA for finance, FERPA for education, plus state regimes like CCPA. That list isn’t trivia. It is a set of hard constraints on how your database is partitioned, where your backups live, who can read what from which jurisdiction. An architecture that defaults to single-region deployment almost always has to be rewritten when the business tries to cross a border.
The second is who owns which slice of the IP. Default copyright ownership under Chinese law for “职务作品” (work-for-employer) and “委托作品” (commissioned work) is not the same as US work-for-hire doctrine. Code a founder writes in a personal capacity is not the same, in ownership terms, as code the same founder writes on a company device using a company email. Outsourcing contracts with no IP-assignment clause, or with a clause but no consideration, or with assignment of source but not derivatives, all fail at slightly different points in due diligence. We’ve seen each of those three failure modes in a single year.
The third is entity structure. A WFOE unlocks onshore operations and invoicing. A Hong Kong Ltd unlocks foreign exchange, USD accounts, and a layer of international banking access. A Singapore Pte Ltd unlocks ASEAN business and a relatively flexible shareholding regime. A Delaware C-corp unlocks USD fundraising and a clean path to a US exit. Each of those carries cost — annual fees, compliance burden, audit requirements, director liability. A company that starts with only a WFOE and tries to do a Cayman + Delaware restructure at Series C spends, in legal fees and time, roughly what a whole funding round would have otherwise bought them.
The fourth is the contract surface. Who signs. In what language. Where disputes go. What governing law controls. The arbitration rules at HKIAC and SIAC differ on discovery and interim relief; CIETAC awards add a layer of effort when enforcement is sought in Western jurisdictions. Whether a bilingual contract says the Chinese or the English version prevails looks cosmetic until the day there’s a real dispute — at which point it can be the difference between a 30% and a 70% outcome.
We put those four things on the same page during the architecture review. Not because we’re giving you legal advice — our engagement letters are clear that formal legal opinions come from your outside counsel — but because getting any of those four wrong cannot be fixed by writing cleaner code later.
IP layout for going out: what to do, in what order
The most common mistake I see is that product gets built, overseas opportunity starts looking real, and only then does someone remember to file trademarks abroad. At that point it’s usually too late. Either a squatter has filed ahead of you, or you’re into an expensive opposition process.
A reasonable sequence looks like this. File your trademark in China first — application to registration runs nine to twelve months. Once you have a China filing date, you have a six-month priority window in which you can extend via the Madrid Protocol to any of the 130-plus member states. Most companies miss that window, lose the cheap priority date, and end up filing country-by-country at double the cost. Covering the US, EU, Japan, Korea, and Hong Kong through Madrid from a China base generally runs in the low five figures in USD.
Software copyright works on parallel tracks that do not interoperate but both matter. In China, 著作权登记 is fast and cheap, and the certificate is genuinely useful in Chinese litigation. In the US, a Copyright Office TX-form filing is required before you can sue for infringement in federal court. Both should be done, and neither costs much.
Patents are a separate conversation. A lot of software businesses do not actually benefit from patents — trade secrets plus contractual protection usually wins. But if your core is a genuinely formalizable algorithm or a piece of hardware, the PCT route is the standard path: file the PCT out of China, buy yourself thirty months in the international phase, and decide during those thirty months which national phases are worth entering. Those thirty months aren’t delay. They’re time to see which markets deserve the spend.
Trade secret versus patent comes down to one question. Is the cost of reverse-engineering your tech lower or higher than the cost of publishing it through the patent system? Cheap to reverse-engineer, and a patent gives you exclusivity in return for publication — usually worth it. Hard to reverse-engineer (think an accumulated operational playbook), and you’re better off keeping it secret and defending it through confidentiality and non-compete clauses.
Domains and brand portfolios are the smallest line item and the one most often skipped. Beyond the obvious .com, grab the two or three ccTLDs where you actually plan to operate (.cn, .hk, .sg, .us), one or two relevant new TLDs (.ai, .io where it fits), and the handles on the platforms you care about. Do this before the product is public.
What changes in what you get from us
The industry default is that you get four things from four vendors: a strategy document from a consultant, a Figma file from a designer, a codebase from an engineering shop, and a memo from a law firm. You then integrate those four deliverables yourself. In practice, most clients don’t have the internal legal bench to do that integration cleanly, so it gets deferred until something breaks.
Our default is the opposite. What you get from us is integrated from the first day. The data-flow language in the SOW lines up with the database configuration in the code. The IP-ownership language in the contract lines up with the actual copyright registrations in your name. The overseas nodes in the architecture diagram line up with a Hong Kong Ltd or Delaware C-corp that already exists, or that has a concrete plan and timeline to exist.
Along with the product itself, you get a short document we call a going-out map. If you want to go to Hong Kong, here’s the next step. Singapore, here’s the next step. The US, here’s the next step. Each with a time estimate and a cost range. It is not a full legal plan — when you actually do any of those moves you’ll still need local counsel. But it gives you a timeline clear enough to make the decision knowing what you’re deciding.
What we will not do
Last thing, and I think the most important. Saying what we won’t help with is more useful than padding the list of what we will.
We don’t build shell-company structures whose only purpose is tax engineering. Cross-border work we do because your operations genuinely need to land in multiple places. Pure profit-shifting into low-tax jurisdictions is both outside our expertise and outside what we’ll attach our name to. That work belongs with a dedicated international tax team, and we’re happy to refer one.
We don’t handle US sanctions risk. OFAC, Entity List, export controls — that is a specialist domain that needs continuous compliance monitoring and an annual training program we don’t run. If your business touches that space in any way, we’ll flag it in the architecture phase and tell you to retain dedicated compliance counsel before you enter the US market.
We don’t take on heavily regulated industries where we lack depth. Banking and licensed financial services, defense and dual-use technology, certain medical device categories (particularly FDA Class III) — in those sectors, a half-informed advisor is more dangerous than none at all. We won’t pretend otherwise.
What’s left — consumer products, B2B SaaS, hardware for museums and cultural institutions, cross-border e-commerce, brand-side work, the non-heavily-regulated parts of ed-tech — is where we’ll stand on your side of the table. What we give you is not just software. It’s an architecture where the entity layer, the code, and the contracts are coherent with each other, and where the space you’ll need when you decide to go out has already been left open.