Market data is the hardest part
Charts and prices look like the easy part. They are the hardest operational problem in the stack, because 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 exclude adjacent asset classes.
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 had no volume data for currency pairs because real spot forex has none to report. Every source fails differently, and a trading product has to keep prices flowing through all of it.
We ended up with a dedicated feed service of our own, running on licensed commercial data with independent failover and operated as infrastructure. Market data is a product you operate. Budget for it that way, whether you build or buy.
Sample market data and sample clients.
Money paths are different code
A price chart that renders a second late is an annoyance. A deposit credited twice is an incident. The biggest 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 appears to have arrived and a wire that has cleared are different facts. It means a trade can only be filled at a price that existed in the feed, never at a stale or interpolated one, because a fill at a price that never traded leads to 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.
This is ordinary engineering, done with discipline every time. It is also 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.
Sample data and sample clients.
The limits of serverless hosting
Serverless hosting works well for websites and badly for 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 in the database because the filesystem does not persist between invocations.
We learned each of those the hard way, and the architecture is better for it: idempotent by habit, resumable everywhere and cheap to run. But that learning took months of engineering that a founder budgeting a build would never think to include, because no architecture diagram shows the constraint until you hit it.
The brand has to be part of the build
White-labelling sounds like a styling task until you try to carry it through the whole product. A brand that is 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. 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.
A sales demo does not show that decision, and it shapes the platform for years. It is also the origin of the One-Database Question we suggest founders ask every vendor: whose tables does your client data live in?
What it cost, and what that means for your decision
There is no single cost figure. 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 the unglamorous work described above: data resilience, money-path discipline, auditability, brand isolation. And the spend never ends, because a trading platform must be maintained as the market keeps moving.
That is what the build-versus-buy decision comes down to. 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.
Pelris builds brokerage software and is not a law firm or a broker. Nothing in this guide is legal, regulatory, financial or investment advice. Confirm your own position with a lawyer who practises in your jurisdiction before acting.

