What a Platform Owes
The difference between a tool and a platform isn’t a feature count. It’s a different relationship to the people who use it. A tool is built for a purpose; a platform is built for people whose purposes you haven’t fully anticipated. The discipline that follows from that distinction is less about shipping capabilities and more about discharging obligations — to cost, to continuity, to trust, to the right to fail safely before you’re forced to fail expensively.
plutarc launched on March 10. What I want to write about here isn’t the launch — it’s the four things that have shipped since, each one a different answer to the same question: what does infrastructure that manages real capital actually owe the people who run it on it?
Organisations and RBAC
For the first several weeks, plutarc was structurally personal. An account held strategies, bots, exchange connections, and billing — all owned by a single user. That’s a reasonable model for a solo trader. It’s a structural mismatch for anyone operating as part of a team: a prop desk that shares a strategy library, a fund that wants separate environments for different portfolios, a firm that needs more than one person to be able to see what’s running.
The answer that’s been live for a few weeks now is Organisations — a first-class workspace layer that sits alongside personal accounts, with a full five-role hierarchy: owner, admin, manager, trader, and viewer. Thirty-four granular permissions distributed across those roles, with invitation flows, an audit log, and an account switcher that lets a single user move between their personal workspace and one or more organisations without touching two separate sessions.
The audit log is the thing I keep coming back to. For individual use it looks like overhead. For any operational context where more than one person has the ability to touch a live bot, it’s basic hygiene — you need to know who changed what and when, not as a punitive mechanism but because debugging at 2am requires a timeline. Without one, you’re reconstructing from memory and inference. The log makes that question answerable.
The structural separation of personal and organisation workspaces also matters in a way that’s easy to understate. It means your personal experimentation doesn’t live in the same namespace as a team’s live infrastructure. The environments can have different risk parameters, different strategies, different billing contacts. The line between what you’re testing and what’s running is a hard architectural boundary, not a naming convention.
Compute That Sleeps
Every bot on plutarc runs on a dedicated compute instance — a real server, not a shared runtime. That decision was deliberate from the beginning: consistent performance, no noisy neighbours, isolated failure domains. It also means that when a bot isn’t doing anything useful, there’s a server running anyway. For a user who trades the Tokyo open and goes dark for sixteen hours, that’s sixteen hours of idle infrastructure at full cost.
The feature that went live recently changes this. Bots can now be configured with trading sessions — defined windows when the bot is actually meant to be active. Outside those windows, if the bot has no open positions to manage, the compute instance is deprovisioned. Not suspended. Deprovisioned — the server is actually released. When the next session window approaches, the instance is reprovisioned with the same IP address and the bot is woken back up. From the exchange’s perspective, the connection comes from a consistent origin. From the user’s billing statement, idle time costs nothing.
The same-IP behaviour is not incidental. A reinstated connection from a different IP can trigger re-authentication requirements, additional rate limit scrutiny, or just the kind of operational friction that compounds at inconvenient moments. Preserving address continuity across sleep cycles was a constraint on the implementation, not an afterthought to it.
What this feature actually does is align the cost model with how trading actually works. Markets have sessions. Volatility has rhythms. An algorithmic strategy operating on the Tokyo open doesn’t generate edge at 4pm London time — it generates liability, because a bot left running in low-volume, thin conditions is as likely to accumulate bad fills as good ones. The infrastructure should reflect that reality. Compute that sleeps when you sleep costs less and runs cleaner.
Support That Works
I built the support system myself, from the schema up. There are SaaS products that would have handled this — and would have handled it adequately. Adequately wasn’t the target.
What’s live now is a full ticketing system: users can open tickets from inside the dashboard, with category and priority, and the full conversation history is preserved in a thread. Every ticket that comes in surfaces a Telegram notification on my end immediately. Auto-close triggers after seven days of inactivity, with a notification to the user first.
The internal side matters too. Tickets support internal notes — visible to operators only, not to the user who raised the ticket. That distinction is easy to omit and harder to retrofit, so it went into the schema first. What it enables is operational triage that doesn’t surface in the user’s thread: technical notes, references to related issues, decisions about escalation, implementation observations that belong in the record but not in the conversation.
The reason I built this rather than reaching for an off-the-shelf tool is partly control — I wanted the ticketing surface to feel native to the platform, not bolted on — and partly philosophy. Support is where trust is actually stress-tested. It’s the interaction that happens when something has gone wrong, when a user is uncertain or frustrated or just needs an answer quickly. That interaction deserves the same attention to craft as the features themselves. An embedded system that I fully own and can extend is worth more to me than a faster path to something I’ll later have to work around.
Paper Trading
plutarc now supports testnet and paper trading across all ten exchanges, with a live/testnet toggle that lets a bot switch contexts without any change to its strategy configuration.
The argument for paper trading is usually framed as risk reduction before going live. That’s true but undersells it. The more precise value is this: it separates the question of whether the strategy is configured correctly from the question of whether it’s profitable. Those are different questions, and conflating them is expensive. If a bot misbehaves on live capital, you can’t easily tell whether the strategy logic is wrong, the configuration is wrong, the exchange connection is behaving unexpectedly, or the strategy just isn’t profitable in current conditions. Paper trading lets you isolate the first three. If a bot runs correctly on testnet — enters and exits where it should, respects position limits, handles errors without crashing — then the performance question is the only one that remains.
There’s also a trust curve that testnet supports, independent of the technical validation question. Starting on paper lets a new user develop genuine familiarity with how the platform behaves before they commit real capital to it. What the interface looks like when a position opens. What the analytics surface after a trade closes. How the risk parameters interact with strategy signals under market conditions. This knowledge is available in documentation, but it’s absorbed in operation. Paper trading is where the learning is cheap.
What Comes Next
These four things are not the most visible features plutarc has shipped. They don’t make the kind of screenshots that anchor a launch post. But they’re the features that answer the harder question — not “what can the platform do” but “can the platform be trusted” — and that question matters more as the platform becomes infrastructure other people’s workflows depend on.
plutarc is now reaching feature completion, but theoretical engineering has its limits. Due to UK residency, I am geographically locked out of the KYC processes required to access most crypto exchanges for testing—even for testnet and paper trading—save for BitMEX. To truly validate this infrastructure, it needs live fire. If you are reading this and have a viable solution or the ability to help test across these blocked exchanges, please don’t hesitate to reach out via the Contact Us form.
