Keeping 24 jurisdictions from becoming 24 products

Stellar was the record of a company’s legal existence. Registered entity details, director and shareholder records, who held how many shares, the files that proved it, and the calendar of everything that had to be filed and when. We sold to small companies operating across more than one market, which is exactly the customer for whom this is hard.

The people using it daily on our side were the ops manager on an account, in practice a registered agent, company secretary, tax preparer or accountant, depending on what the customer had bought.

A US entity is not in one jurisdiction. A company incorporated in Delaware and foreign-qualified in California and Indiana carries obligations in all three at the same time: three sets of filings, three calendars, three sets of field names for the same facts. So when we added a state we were never adding one thing — we added the state, and we added it as a foreign qualification available to every entity already on the platform.

That is what made a per-market build impossible rather than merely expensive. Twenty-four variants would have meant a single customer needing three of them at once.

We started as software sold to company secretaries in Singapore. ACRA, the company registrar there, had an API we could pull entity data from, and the rules were comparatively straightforward.

Malaysia looked like a bigger version of the same problem: similar company law, a much larger market, less to pull from the Malaysian registrar than ACRA gave us, and Malay language support to add.

Malaysia did ship, but under Stellar rather than Starboard. Before we built it we pivoted — from selling software to company secretaries to being the registered agent ourselves — and turned to the US. We started with Delaware because Delaware is the one everybody has heard of.

Delaware is where the assumptions broke. There was no API. The authoritative source was a PDF on a state government site, and the answer to “when is this due” was usually common practice rather than the rule itself. The two are not always the same. Every state after it was the same problem, and a different answer.

I built the field map first, while there was still only one real market in production.

It is a grid. Every row is a field as the product knows it. Every column is a jurisdiction. A cell is filled only where that jurisdiction diverges from the default. Blank means inherit.

The clearest row is the trading name: one field in the product, seven different legal names underneath it. Most states call it “doing business as”, but Florida calls it a fictitious name, Massachusetts a transacting name, Texas an assumed name, Washington a business name.

The registration number row runs the same way, down to Singapore’s UEN and New York’s DOS ID.

None of that is a design decision. It is the law using different words for the same fact, and the only question is whether the product absorbs the difference in one place or scatters it across twenty-four.

People got the same treatment. Every role — director, CEO, auditor, lawyer, accountant — resolves into one of four groups: board, team, shareholders and members, collaborators. The jurisdiction changes the label. It does not change the structure.

The map became the reference engineers, the CPO and I all worked from, and it stayed current the whole time I was there rather than becoming a document nobody opened.

Filing dates were the part that could not be normalised into a single rule, and I did not try. What I normalised was the language the rules were written in.

Every date is an expression against a small set of anchors — incorporation date, fiscal year end, foreign qualification registration date, the date a role was appointed:

On top of that sits a set of base rules that hold everywhere: what happens to a date when the customer changes their financial year end, that a cessated director stops generating renewal dates, that unticking an event deletes its dates unless one has been resolved.

Then each jurisdiction’s own rules sit on top of the shared base. Singapore hangs almost everything off financial year end — estimated chargeable income at three months, the annual general meeting at six, the annual return at seven, each with its own extension. The US hangs its federal filings off the fiscal date and its state filings off incorporation, and needs two years of dates generated rather than one.

So the rules fork. The grammar does not. A new jurisdiction is new expressions in a language the system already speaks, which is why it did not need new screens.

The grammar was the easy part. Filling it in correctly was not, and at the start I got it wrong. I used AI to work out filing dates because it was fast and it sounded right. What it was actually giving me was the consensus of what most companies do, rather than what a given jurisdiction requires. The two agree often enough to be dangerous.

Customers were the ones who told us the dates were wrong. Real filings were at risk.

After that I read the source documents myself, state by state, and used AI only to point me at where to look — then took anything I was unsure about to a tax professional or a registered agent to confirm. That is why the process in the next section starts with reading a state’s own filing sites, and why nothing ships until QA has checked every date it generates.

By the end the process was routine enough to write down:

None of that was true of Delaware. It was the first state I did, and it started as a copy of the Singapore model — which is the wrong shape for a US state — so it took weeks of iteration before it stopped behaving like one. Everything I learned pulling it apart is what the field map is made of.

After that the rhythm was steady rather than dramatic. Six states went in during a single sprint in February 2024: Massachusetts, New York, Colorado, Michigan, Wyoming and Arizona. Nevada followed in April, in the same release as automatic date rollover for Singapore and Malaysia. I finished mapping Montana at the end of April and it was live on 3 May. By early June we covered eighteen states, with North Carolina, Georgia, Pennsylvania and Rhode Island going out that week and Washington, Minnesota and Texas next. Hawaii went in last, which is why the guide below still lists twenty-three.

The interesting part is where the bottleneck ended up. Nobody ever argued for a state-specific screen. Engineering had made adding a state genuinely easy, and everyone wanted new markets faster. The constraint was me: how quickly one person could read a state’s statutes and turn them into rules.

Entity records on the platform went from 534 in mid-February 2024 to 673 by early September, across all twenty-four jurisdictions, on one set of screens.

Reading the source and confirming it with a professional was the right method. I just arrived at it backwards, after customers had been affected.

What I would do differently is go to those people first. Shadowing registered agents and company secretaries through real registrations and filings would have given me in a week what took me months to assemble from documents, and it would have taught me what a document cannot: which rules practitioners treat as immovable, and which ones they have watched bend in practice.

It would have fixed the other problem too. By the end, adding a state cost engineering about a day, and everyone was waiting on me — one person reading statutes and turning them into rules. I never asked for standing time with the registered agents and accountants who already knew this material, because I assumed working it out alone was the job. It wasn’t, and asking would have made the whole thing faster.