SpecialX
← All posts

From autocomplete to an AI-native company: ten months of building SpecialX

RRokFounder, SpecialX · November 3, 2026

In January 2026 I opened an empty Next.js project and typed the first commit message: "Initial commit from Create Next App". The plan was modest: a simple AI video generator. Upload a picture, pick a model, get a clip back.

Ten months and more than 2,500 commits later, SpecialX is something I could not have described back then. It runs online stores, a team chat, a double-entry ledger, meeting bookings, a Mac app and an iPhone app, and a fleet of agents that work while nobody is watching. More importantly, it can change itself.

This is the story of how the way we build changed, and why that change is the whole point.

Phase one: AI as a very fast keyboard

At the start, Claude was a coding assistant in the narrow sense. I wrote the plan, and it filled in the gaps:

  • "Make this button disabled while the request is pending."
  • "Add a column for the Kling task id."
  • "Why does this credit deduction run twice?"

Small UI tweaks, one backend function at a time, granular work at the level of autocomplete. Very useful, but I was still the one holding the whole system in my head. Every commit message in those first weeks was literally wip.

Phase two: agents that finish things

Somewhere in spring the unit of work changed. Instead of asking for a function, I started asking for a feature: build the storefront, wire the checkout, add the workflow canvas, write the tests, open the PR.

The agents stopped being autocomplete and became colleagues. They read the codebase, made plans, ran the test suites, reviewed each other's diffs, and merged. Our repository rules (branch per task, worktree per branch, review the full diff, never deploy unmerged code) were written as much for agents as for humans.

That is when the product exploded in scope:

  • Workflows: a canvas where image, video, audio and editing models chain together and run headlessly.
  • Stores: whole e-commerce brands running on SpecialX, with checkout, email flows, quizzes, advertorials and analytics.
  • Supercomputer: an agent with its own sandboxed computer that can build and ship apps.
  • Native apps: a SwiftUI iPhone app and a macOS app, both talking to the same action layer.
  • An action registry: today more than 340 actions, each one automatically exposed to the web app, the CLI, the MCP server and the agents.

Phase three: a system that shapes itself

The big shift was not any single feature. It was closing the loop.

When every capability is an action, and every action is available to an agent, the agent can operate the product the same way a person can. So now:

  • Orbs, our unattended agents, run on schedules they set themselves, pick up work from a queue and report back.
  • A memory cultivator watches how people use the system and turns repeated intent into lasting context.
  • A daily security loop finds vulnerable dependencies and ships patched builds without anyone asking.
  • Ad, funnel and content agents read live analytics and propose (or make) the next change.

The code is no longer something only I change. The system is a participant in its own development.

Replacing the subscription stack

One side effect of building this way: every SaaS subscription started to look like a feature we could own.

So we replaced them. Comms replaced Slack: channels, threads, DMs, peer-to-peer calls, and an @specialx agent you can mention in any conversation to do real work on the backlog. Our own email sending replaced a third-party provider. Bookings replaced the scheduling tool. The ledger replaced spreadsheets, and does Australian GST. Files, projects, communities and integrations followed.

Each one is cheaper, yes. But the real win is that each one lives inside the same system as the agents. A booking, a ledger entry and a chat message are all things an agent can read and act on, with no glue code and no API limits.

Leaving Supabase for D1 and Durable Objects

Supabase got us remarkably far. But one shared Postgres for every user, every store and every agent has a ceiling, and we could see it.

So we are moving to an architecture built for effectively unlimited scale on Cloudflare:

  • A small global D1 database for things that are truly global: identity, directory, public index.
  • A Durable Object space per organisation (and per app), each with its own SQLite storage, living close to its users.
  • An app-side query layer shaped like the one we already used, so features move over one at a time.

Bookings, the ledger, the project tracker, files and workflows have moved into org spaces wave by wave, with comms next, behind flags, with the old path kept until each cutover is verified. No organisation can slow down another, and adding a customer adds capacity instead of load.

Where we are headed

The goal is simple to say and hard to build: a complete operating system for AI-native companies.

  • Thousands of tools, already connected. Every integration exposed as an action that both people and agents can use.
  • Payments built in. Stores, subscriptions, credits, payouts and the books that track them, in one place.
  • True human and AI collaboration in real time. People and agents in the same channels, the same documents, the same canvas, seeing each other's cursors and picking up each other's work.
  • A self-optimisation loop. The system measures what happens, proposes changes, ships them through review, and measures again. For your stores, your funnels, your operations, and for SpecialX itself.

Ten months ago, AI helped me write a button. Today it helps run a company. I can't wait to see what the next ten months look like, and I'd love to hear what you would build on it. Leave a comment below.

Like0 likes

Comments (0)

Sign in to like and comment.

    © 2026 SpecialX™. All rights reserved.