We built a trading platform from scratch. Here is what it actually took.

Charts and prices look like the easy part. They are the hardest operational problem in the entire stack, and the reason is that market data is not one product. Crypto prices stream freely from exchange endpoints. Foreign exchange has no central tape at all, so retail platforms live on dealer feeds and unofficial endpoints. Equities data is licensed, priced per exchange, and the affordable tiers quietly refuse adjacent asset classes.

Our own history makes the point. We went through free and keyless endpoints, unofficial chart feeds and free-tier data vendors, and each one failed in its own way: one blocked requests from cloud data centre addresses, one returned nothing for forex on the free tier, one simply had no volume data for currency pairs because real spot forex has none to report. The lesson was not that these sources are bad. It is that every source fails differently, and a trading product has to keep prices flowing through all of it.

We ended with the only durable answer: a dedicated feed service of our own, running on licensed commercial data with independent failover, operated as infrastructure rather than called as an API. Market data is a product you operate. Budget for it that way, whether you build or buy.

A price chart that renders a second late is an annoyance. A deposit credited twice is an incident. The single deepest difference between a demo and a platform is that every path money takes is engineered to a different standard from everything else.

Concretely, that means settlement logic that can run twice without crediting twice, because in distributed systems things run twice. It means bank wires are never automatically credited, because a wire that looks arrived and a wire that has cleared are different facts. It means a trade can only ever be filled at a price that actually existed in the feed, never at a stale or interpolated one, because a fill at a price that never traded is not a bug, it is a dispute. And it means every one of those decisions leaves an audit trail, because a supervised business will one day be asked to show one.

None of this is exotic computer science. It is discipline, applied uniformly, forever. It is also precisely the part that a small team building under launch pressure is most tempted to defer, and the part that cannot be retrofitted after the first real client incident.

Modern serverless hosting is superb for websites and quietly hostile to trading systems. Functions that stop existing between requests cannot hold a background worker, so anything continuous, from price distribution to copy trade execution, has to be rebuilt as polling and queues. Long-lived streaming connections hit hard timeouts. Persistent state has to live entirely in the database because the filesystem evaporates between invocations.

We learned each of those the practical way, and the architecture that came out the other side is genuinely better for it: idempotent by habit, resumable everywhere, and cheap to run. But that learning consumed real engineering months that a founder budgeting a build would never think to include, because no architecture diagram shows the constraint until it bites.

White labelling sounds like a styling task until you try to do it honestly. A brand that is genuinely the broker's own has to reach the terminal, the CRM, the emails, the app icons and the domain, and the broker's data has to live in its own database rather than as rows in a shared one. We built brand and deployment as configuration, one codebase producing fully separate branded deployments, because the alternative, forking the code per customer, turns every future fix into work multiplied by the number of customers.

That decision is invisible in a sales demo and decisive three years in. It is also the origin of the One-Database Question we suggest founders ask every vendor: whose tables does your client data live in?

The honest accounting is not a single number, it is a shape. The first working version is months of full-time engineering. The version a supervised business can run is several times that, because the gap between the two is exactly the unglamorous work described above: data resilience, money-path discipline, auditability, brand isolation. And the spend never ends, because a trading platform is never finished, only maintained against a market that keeps moving.

That is the real content of the build-versus-buy decision. Building is the right call when proprietary technology is itself the business. For a brokerage whose edge is distribution, service or a market niche, the build is an expensive detour through problems that have already been solved. We say that having taken the detour ourselves, which is also why the platform exists: so the next founder does not have to.