The BIXSO Experiment, episode 1: three products, three live domains, one calendar day

Solution by Thanh Dao · strategy · 4 min read

<!-- md piece: bixso-experiment-ep01 · pillar: proof · kind: solution --> <!-- Voice: BIXSO-VOICE-AND-MESSAGING.md · CTA duy nhất: Book a consult --> <!-- Facts phải verify được — nguồn ghi ở cuối file --> <!-- Serial: The BIXSO Experiment, ep. 1 · psych beats: hook/model/analysis/agentic/mirror/door -->

The BIXSO Experiment, episode 1: three products, three live domains, one calendar day

This is the first entry in a monthly series where we open our own books. One founder, a small set of AI agents running the company's own functions, nine products in build or live. Every month: what shipped, what it took, what we measured. This one starts with the number that made us want to write the series in the first place.

The number

On 9 July 2026, three separate products in the BIXSO ecosystem had their domains pointed at live hosting in the same calendar day: ecosport.com.au, auslandscape.com.au, and wikistay.com. One was a full rebuild of an existing product into a new market — sport instead of education. The other two didn't have a single line of code that morning. By evening, all three had a working sign-in flow, a first real feature, and a real domain behind them.

You can check this against public commit history. We're not asking you to take our word for it — that's the whole point of a series like this.

The model this is actually testing

The company behind those three launches isn't a team. It's one founder and a small standing set of AI agents, each with a fixed area of responsibility — one owns engineering execution, one owns brand and content, one owns the money, one owns the health of the other agents. What we're testing with days like 9 July isn't whether AI can write code. That question was settled a while ago. What we're testing is a venture-studio model: whether one small operating layer can keep launching child products without adding a person for every new one, as long as the scaffolding underneath is genuinely reusable.

What actually made that day possible

Here's the part that isn't obvious from the outside: the speed didn't come from any agent working faster than a person types or thinks. It came from removing the waiting between roles.

A normal product launch is a chain of handoffs — brief to designer, designer to developer, developer to infrastructure, infrastructure to whoever has the login for the domain registrar. Each handoff is usually measured in hours or days, even when the actual work inside each step is short, because someone has to notice the last step finished and pick up the next one.

On 9 July, that chain collapsed into one continuous run. The brand-token agent didn't wait for a separate design review before handing off — its output was already in the format the build agent needed. The infrastructure agent didn't file a ticket for DNS — it ran the same registrar steps it had already run for the previous product, adjusted for the new domain. The only real waits left in the day were the two decisions that should always require a person: which colour palette actually represents the brand, and whether to register a new domain or use one already owned.

How it's actually built, not just described

None of this runs on improvisation. It runs on a written build standard that every new product follows, so the work that's specific to product nine is only the part that's actually different from products one through eight — not the boilerplate underneath it. Concretely: a fixed frontend-plus-backend scaffold, a repeatable hosting-project setup, a sign-in flow that's configured the same way every time. The agents aren't inventing a new architecture per product. They're filling in a known shape, fast, because the shape itself stopped being a decision a long time ago.

There's one deliberate exception worth naming: a handful of setup steps only exist behind a web console, not an API — the kind of step most platforms gate behind a human click on purpose, because it's security-sensitive. We don't route around that. An agent still has to hand that specific step to a person. That's not a gap in the system. That's the system working as intended — autonomy for the repeatable work, a person for the steps that should never be fully automatic.

Worth asking about your own business

You're probably not launching three products in a day. But most businesses have a version of this same coordination cost — a new offer, a new location, a new service line that's genuinely simple once someone actually does it, but keeps getting pushed back because getting the right people and the right handoffs lined up feels bigger than the work itself.

What's the thing in your business that would take an afternoon if the coordination cost disappeared — and how long has it been on the list because it doesn't?

Next episode

Every month, this space gets a real number from how we actually run — what shipped, what it cost, what we're still building out. If you want to see what this model looks like applied to your own operation instead of ours, book a consult — the first one is free.

--- Sources:

wikistay.com same-day scaffold-to-live, both 09/07/2026: internal build log, CLAUDE.md (root) "Tiến độ" section and apps/{ecosport,auslandscape,wikistay}/frontend/CLAUDE.md (internal, verifiable against public GitHub commit history for each repo).

agent): BIXSO's own operating structure, verifiable in BIXSO-CSUITE.md and agents/registry.json (internal).

TECH-INVENTORY.md and per-app frontend/CLAUDE.md` files (internal).

Open in bixso.net →