# Story: Why I Rebuilt This For The DemandOps Portfolio Move Big Rocks was rebuilt because I needed one owned instance to run the DemandOps portfolio across multiple products, brands, and countries instead of paying for separate SaaS tools, accounts, licenses, identities, and hidden workflows for each one. I also realized that building separate internal equivalents for support, forms, analytics, error tracking, and other operational needs would just create a new kind of sprawl: isolated vibe-coded apps repeating deployments, secure endpoint exposure, TLS certificates, database management, auth, and integrations. I used the earlier 2010 platform model as leverage, pushed the workspace model further, and built the extensions I needed on top of one shared operational base. I also needed a system that agents could use securely through one CLI and one controlled access model. That now replaces roughly EUR10,000 per year of SaaS spend across my own ventures and gives other teams and agents the same path. ## Summary - Built for real portfolio operations: The operating need came first: one owned instance for forms, support, analytics, error tracking, knowledge, and automation across multiple products and brands, without separate SaaS stacks for each one. - Operational leverage, not app sprawl: The key realization was that replacing SaaS with separate internal clones would still create sprawl by repeating deployments, endpoint exposure, TLS certificates, database management, auth, and integration work per tool. - 10+ years of production roots: The original system was built in 2010 and ran for more than 10 years across campuses in Australia before being rebuilt in Go for the current portfolio. - Used by the builder: Adrian McPhee runs Move Big Rocks operationally for the DemandOps portfolio across multiple brands and countries, replacing roughly EUR10,000 per year of separate SaaS spend. - Becoming transferable: The extension model was refined through that operational use and then made public so other teams and agents can use the same model instead of repeating SaaS sprawl per brand. ## The rebuild was driven by repeated cross-brand operational pressure, not abstract ambition. Running a portfolio of products across brands and countries means the same operational needs appear over and over: customer support, intake forms, analytics, error tracking, knowledge management, and automation. Buying separate SaaS tools for each brand means separate accounts, separate licenses, separate vendor relationships, separate identity integrations, separate security reviews, and separate hidden workflows. That cost and complexity compounds with every new product. It also makes secure agentic operation much harder, because an agent ends up hopping across many vendors and auth models instead of using one approved contract. I needed one substrate I could run once and reuse across the portfolio. - Multi-tenant from the start: The earlier platform was built to support multiple organizations and departments rather than a single hard-coded workflow. - Cases across boundaries: A key design concern was letting cases move between people inside a department and across departments while preserving the same shared record. - Broader than IT support: It was used to support students with all kinds of issues, not just IT support, across departments including student services. - Service model, not website theater: The important part was never brochureware. It was the operating model behind intake, routing, shared context, and durable resolution. ## Replacing SaaS one app at a time would have recreated the same fragmentation. I could have built a support tool, a forms tool, an analytics tool, an error-tracking tool, and a series of internal helpers independently. That would still have left me with a mess, only now it would be my mess: vibe-coded app sprawl instead of SaaS sprawl. Each tool would need its own deployment path, secure endpoint exposure, TLS certificates, database management, auth wiring, admin UI, background jobs, secrets, monitoring, and upgrade story. Even if each individual app looked cheaper than SaaS, the operating burden would still compound. The leverage had to come from one shared operational substrate, not from building more standalone replacements faster. - Not just buy vs build: The real problem was not only vendor cost. The real problem was repeated operational fragmentation, whether the tool came from a vendor or from my own code. - Shared operational substrate: Deployments, routed endpoints, TLS, database ownership, auth, audit, background work, and event delivery needed to be solved once and reused, not rebuilt for every capability. - Extensions on one base: That is why product depth lives in bounded extensions instead of isolated apps. A new capability should inherit the same core routing, eventing, storage, UI shell, and review model. - Better agent leverage: Agents become more useful when they can work through one visible control plane and one operating model instead of brittle browser choreography across many SaaS products and homemade apps. ## The earlier platform ran long enough to teach real lessons. The original system was used in production for more than 10 years across campuses around Australia, especially in the tertiary education sector. It became real infrastructure for supporting students with all kinds of issues across many departments, including student services, while moving work between teams without losing context. That matters because the current product inherits lessons from real service operations rather than relying on fresh theory alone. - It had to support real operational handoffs, not just demo scenarios. - It had to work for student-facing issues beyond IT support. - It had to keep context intact when work crossed teams and departments. - It had to stay useful over years, which forced the model to be more durable than a fashionable point tool. - The later move to ServiceNow came from a company change, not because the underlying operating problem disappeared. ## The model survived. The old codebase did not need to stay the final implementation. After the primary customer was acquired and moved onto ServiceNow, the earlier system stopped being the active product. What remained was a proven model sitting on an older codebase. AI-assisted migration made it practical to carry that Django and Python system forward into Go instead of treating it as a dead end. The point was not only to modernize the implementation. It was to give one owned instance a cleaner shared workspace model, a tighter agent-operable contract, and explicit extensions for the things I actually needed, while turning routing, eventing, endpoint exposure, storage, and deployment concerns into shared platform capability instead of repeated app-by-app boilerplate. - Why Go: Go offers a tighter deployment model, a single binary, strong typing, and a codebase that is easier to evolve with compiler feedback in the loop. - Why now: Operational work is fragmented across support tools, forms tools, analytics tools, recruiting tools, ticketing systems, inboxes, and internal glue. The important context is fragmented too across decks, chats, local Markdown, prompts, runbooks, and personal folders. - What changed: The rewrite tightens the architecture, pushes the shared workspace model further, makes extensions explicit, and turns operational leverage into part of the product instead of leaving deployments, certificates, endpoint wiring, and event plumbing as repeated side work. ## One goal of the rebuild was to make the system legible to capable agents. Move Big Rocks is designed so a capable agent can operate it efficiently through the same approved surfaces humans use. That was not an abstract product goal. Part of the rebuild was realizing that scattered SaaS products were a poor operating model for secure agentic work. Give the agent the Move Big Rocks repo or the instance repo, the current `mbr` CLI and machine-readable contract, and the relevant workspace and team context, and it should be able to work through the system without inventing a second control plane. - One explicit contract: Agents work through one `mbr` CLI with `--json` on every command, one GraphQL API, machine-readable bootstrap endpoints, and explicit workspace and team context. - Practical operating scope: A capable agent should be able to deploy and configure Move Big Rocks, work conversations and cases, retrieve and publish knowledge, submit forms, install and configure extensions, and help teams author private extensions. - System of record stays shared: Move Big Rocks is where records live, permissions are enforced, approvals happen, and audit trails are recorded. Agents operate through that same system instead of around it. - Concrete expectation: A user should be able to tell an agent “create me a Move Big Rocks instance repo and deploy it to one Ubuntu VPS I control” and have the agent handle most of the work through documented surfaces. ## The product is shaped by running it operationally, not only by product theory. Adrian McPhee built the original platform and has served as CTO at major firms including LeasePlan and Bol. He now runs Move Big Rocks operationally for the DemandOps portfolio, including products such as TuinPlan, across multiple brands and countries. The same pressure kept showing up at every scale: duplicated SaaS subscriptions, duplicated vendor relationships, duplicated identity integrations, duplicated hidden workflows, and weak footing for secure agentic work when each brand needed its own tool stack. - Used operationally by the builder: Move Big Rocks is not a side project. It runs the operational infrastructure for a real portfolio of products across brands and countries. - Replacing real SaaS spend: The rebuilt platform plus its extensions replace roughly EUR10,000 per year of SaaS spend across Adrian McPhee's ventures, which helps extend runway instead of funding duplicated tool stacks. - Experience at scale: The product is informed by experience running technology in larger businesses, not only by startup-era tooling preferences. - Becoming transferable: The extension model and first-party extensions were opened up after being refined in real use. Some startups the founder advises are now adopting the same model because repeated SaaS sprawl per brand is a common problem. ## There is also a written body of thinking behind the product. The books below are supplementary context, not product proof. They are useful if you want the broader argument about structural honesty, process ownership, and why shared systems matter more in an AI era. - Illusions of Work [Related writing]: A practitioner-level book for CTOs, architects, and engineering leaders about structural clarity, process ownership, and why reality needs to be made machine-readable. (https://simpleisadvanced.com/illusions-of-work/) - Illusions in the Boardroom [Related writing]: A shorter board and executive version of the same argument, focused on governance, capital allocation, and structural honesty. (https://simpleisadvanced.com/illusions-in-the-boardroom/) - The Process Is the Product: A related article on why process ownership matters and why the process itself needs to become the product boundary. https://simpleisadvanced.com/articles/the-process-is-the-product/ - The Machine That Reads Your Strategy: A related article on how AI changes the economics of reconciling organisational narratives with running systems. https://simpleisadvanced.com/articles/the-machine-that-reads-your-strategy/ - Articles: The wider article series behind the books and the broader structural argument. https://simpleisadvanced.com/articles/ ## Evaluate Move Big Rocks as a new implementation of a proven operational model. The codebase is new. The lessons are not. That is the right lens for evaluating the product. - Treat the provenance as a credibility signal, not as a substitute for technical proof. - Use `/agents`, `/docs/cli`, `/security`, and `/resources` to inspect the current implementation directly. - Use the origin story to understand why the product is shaped around shared context, handoffs, and bounded extensions. ## Related - Agents: /agents - Use cases: /use-cases - Self-host: /self-host - Resources: /resources - Illusions of Work: https://simpleisadvanced.com/illusions-of-work/ - Articles: https://simpleisadvanced.com/articles/