The Retail Systematic Trading Platform is a self-hosted trading platform for retail traders who want to operate systematically — data, strategy, execution, and risk as one coherent system they own and control, with no vendor lock-in. It is built on the RAD Stack and deployed as multiple parts around a central core, run by the trader on their own infrastructure.
It needed its own domain. This post is the record of how I chose it — and I will be open about it: this is the same structured evaluation I ran when choosing a domain name for the Digital Solution Lifecycle Model. Same criteria, same TLD-first approach. What changes is the audience, and that turns out to change enough to be worth writing down: the systematic retail trader filters on very different signals than the enterprise buyer.
The Ideal Customer
The platform is built for the technical retail trader who wants to run a disciplined, systematic operation — someone comfortable on a Linux host, who reads the source before they trust it, and who would rather own their stack than rent access to someone else’s. They are not looking to be sold an edge; they already have opinions about strategy and want infrastructure that gets out of the way. What frustrates them is exactly what the platform fixes: opaque commercial tools, metered data, platform-enforced risk rules, and lock-in that keeps their strategy and capital inside someone else’s system.
Understanding the ideal customer shapes the domain name decision. The name is not just an address — it is the first signal about who this is for and whether it is worth their attention.
What Makes a Good Domain Name
This audience has a sharper-than-usual skepticism radar, and for a specific reason: the trading space is saturated with hype. “Signals,” “bots,” “profit,” “wealth,” “get-rich” — the vocabulary of the scam is everywhere, and anyone serious about systematic trading has learned to filter it out instantly. A name that reads as a get-rich-quick product loses this audience before the first click. A name that reads as a serious engineering tool — clear, grounded, unexcited — gets through. Avoiding the hype vocabulary is not a style preference here; it is a credibility requirement.
There is a second signal that matters more for this audience than for an enterprise buyer: this is a self-hosted, technical project that will be discovered through GitHub, forums, and word of mouth, not through a sales motion. The name has to survive being typed from memory into a terminal, a git clone, and a config file — so length, spelling, and the absence of ambiguous characters carry real operational weight.
For me, the primary constraint is cost. The platform is in early development — spending on a premium domain before it is proven is the wrong allocation. The name needs to be registrable at standard rates, not negotiated out of a premium portfolio or acquired from a reseller. The other practical requirement is that the base domain is short enough to make subdomains workable — every character in the base domain adds to every URL that branches off it.
| Requirement | Rationale |
|---|---|
| Domain credibility | Credibility comes from the combination of name and top-level domain (TLD), not either one alone. For this audience it means reading as a serious engineering tool, not a trading-hype product. A developer-native TLD can reinforce that; a niche trading TLD can undermine it. |
| No hype vocabulary | The trading space is full of scam signalling — “signals,” “bots,” “profit,” “wealth.” A name that borrows that vocabulary is filtered out instantly by exactly the serious traders this is built for. |
| Terminal-friendly | This is a self-hosted project — the name gets typed into git clone, shell commands, and config files. Short, unambiguous spelling, no easily-confused characters. |
| Memorable | Discovery happens through forums, GitHub, and word of mouth. A name that sticks after one encounter travels without friction — no spelling out, no searching. |
| Cost-effective | Early-stage project — overspending on a domain before it is proven is the wrong allocation. The name should be good, not expensive. |
| Subdomain-friendly | The base domain needs to be short enough that subdomains (docs, releases, demo) remain workable — every character in it adds to every URL that branches off it. |
The Options
Before evaluating specific names, I assessed the TLD. The audience is technical and developer-adjacent, so the signals differ from an enterprise product — developer-native TLDs carry credibility here that they would not in a boardroom, and the obvious “trading” TLDs carry risk.
| TLD | Assessment |
|---|---|
| .io | Strong developer and open-tooling credibility — the de facto TLD for technical projects and infrastructure. Reads as native to this audience. Downsides: higher price than .com and a geopolitical footnote (British Indian Ocean Territory) that occasionally surfaces. |
| .sh | Terminal-native and thematically on point — sh reads as shell, reinforcing the “you run it yourself” identity of a self-hosted tool. Common for CLI and developer tooling. Priced higher than .com and technically a ccTLD (Saint Helena), but the association is exactly right for this audience. |
| .dev | Technically clean — HTTPS-enforced (HSTS preload) and run by Google — but the connotation is off. It signals a developer’s tool or documentation site, and this audience is systematic traders who happen to be technical, not developers. Worse, .dev can read as in development — not production-grade — which is exactly the wrong signal for a system trusted with live capital. |
| .com | The universal default — safe and unambiguous, but a little flat here. For a self-hosted, community-discovered tool, a plain .com reads as a commercial product-company domain rather than a developer project, giving up the native signal that .io, .sh, and .dev carry with this crowd. |
| .org | Reads as non-commercial / community project — closer to a self-hosted open tool than .com, signalling a project, not a product company. Less developer-native than .io or .sh and a little unexpected for software, but cheap and a natural fit for the ethos, which makes it a sensible companion domain rather than a primary. |
The candidates are the initials of Retail Systematic Trading Platform, differing only in whether platform is spelled out or kept as the letter P:
| Name | Notes |
|---|---|
| rstp | Four characters — the full initials. But RSTP is Rapid Spanning Tree Protocol to anyone network-literate — which this technical audience is — so it lands with instant recognition of the wrong thing. Four letters also means four syllables to say aloud, with no natural close. |
| rstplatform | The most explicit expansion — Retail Systematic Trading then “platform” in full. Eleven characters: the longest base domain and the steepest subdomain penalty, and it still carries the RSTP echo. Most descriptive, least wieldy. |
Both keep Retail up front, so the target audience is unmistakable — the signal that matters most for a product positioned as retail traders, not institutions.
There is a tension worth naming. Unlike the clean dslm abbreviation for the model, the initials here collide with an established term in this audience’s own world — RSTP is Rapid Spanning Tree Protocol to any network-literate reader. That is the cost of the initials route, and it is what the availability check has to weigh against.
Availability
| .com | .io | .dev | .sh | .org | |
|---|---|---|---|---|---|
| rstp | ❌ | ✅ | ❌ | ✅ | ❌ |
| rstplatform | ✅ | ✅ | ✅ | ✅ | ✅ |
Decision
The chosen domain is rstplatform.sh.
The name came down to brevity versus availability. rstp is shorter and cleaner to type, but it lands squarely on Rapid Spanning Tree Protocol for a network-literate audience, and its namespace is largely gone — .com, .dev, and .org are all taken, leaving only .io and .sh. rstplatform costs me length and a heavier subdomain penalty, but it reads unambiguously, softens the RSTP collision by spelling the word out, and — decisively — is available clean across every TLD I considered. For an early-stage project whose whole point was to register at standard rates without fighting for a namespace, full availability won over raw brevity.
The TLD followed from the audience. .dev was out on connotation — in development is the wrong signal for a system trusted with live capital. .com reads flat here, a commercial product-company domain for what is really a self-hosted, community-discovered tool. That left .io and .sh, both native to this crowd. I went with .sh: sh is the shell, and the entire identity of this platform is that you run it yourself on your own infrastructure — the TLD says the same thing the product does. It also sidesteps .io’s one real long-term risk, the unresolved sovereignty change hanging over that registry.
rstplatform.sh is the canonical home. Because every TLD I checked was available at standard rates, I registered the full set — .com, .io, .dev, and .sh — and added .org on top, purely because it was available and cheap (its non-commercial, community connotation is a nice fit for a self-hosted open tool). All of them redirect into rstplatform.sh; the primary is the only address that resolves directly.
Working through naming or domain decisions for your own product? Leave a comment below, or get in touch — always interested to compare how others navigate the constraints. Follow my RSS feed to keep up with the venture as it develops.