Custom Trading Solutions: What a Bespoke Build Actually Involves

The brief arrives as one sentence: "I need a copier that mirrors my trades to four prop accounts." Eleven words. The build behind them contains something like forty decisions, and the person who wrote the sentence has opinions about maybe six of them.

That gap is where custom trading software goes wrong. Not in the code — in the space between what somebody asked for and what they assumed came with it. This is a tour of what a bespoke build actually contains, so that when you commission one you are pricing the whole thing rather than the first sentence of it.

The spec is the job

Every hour spent arguing about a specification before code exists saves several after it. Take that eleven-word brief and start asking the questions a developer will have to answer one way or another, with you or without you:

• When the source account opens 2.0 lots, what do the four destinations open? The same size, a balance-proportional size, a fixed percentage risk, or a per-destination multiplier?
• What happens when one destination rejects the order because it breaches a prop firm's maximum-lot rule? Does the whole copy fail, or do the other three proceed?
• The source uses XAUUSD. Destination three calls it XAUUSD.r and destination four does not offer gold at all. What then?
• The source is a hedging account with two opposing EURUSD positions. Destination two is netting and can only hold one net position. Which behaviour is correct?
• Source closes half a position. Do destinations close half of their own size, or half of the source's original size scaled down?
• You place a manual trade directly on a destination account. Is that trade managed, ignored, or closed as an orphan?
• The copier restarts at 03:00 with four positions already open on the source. Does it copy them now, or only copy what opens from this moment on?

None of those are exotic. Every one of them has to have an answer in the code. If the brief does not contain the answer, the developer picks one, and you find out which one they picked during the first week your money is on it.

The platform is not a detail

Each trading platform hands you a different set of constraints, and they are not interchangeable. A brief that says "make it work on all platforms" is four builds wearing a trench coat.

MT4 runs MQL4 inside the terminal. It is single-threaded per chart, historically weak at outbound network calls, and the terminal has to be running on a machine somewhere. Hedging is native. The account is reached either through a terminal-side program or through the manager side, which a retail trader does not have.

MT5 runs MQL5, has both netting and hedging account types, a richer order model, and a stricter validation layer that rejects orders MT4 would have quietly accepted. Code does not port from MT4; it gets rewritten.

cTrader gives you a proper Open API over a documented protocol plus cAlgo in C#. That is a genuinely different engineering shape — you can build server-side rather than terminal-side — and it is why cTrader work usually looks nothing like MetaTrader work.

TradingView is not an execution venue. Pine Script produces alerts; something else has to receive the webhook and place the order, which means the interesting part of the build is the receiver, not the script.

Tradovate and NinjaTrader are futures-first. Contract specifications, tick values, session times and rollover are the whole problem, and none of the forex habits transfer cleanly.

A realistic multi-platform build is one core engine plus a thin adapter per platform, with the differences pushed into the adapters. Getting that boundary right is most of the architecture, and it is also why the second platform costs far less than the first if the first was built properly, and roughly the same again if it was not.

Testing is not a phase, it is a percentage

The part of the quote that people try to negotiate away is testing, and it is the part that determines whether the thing survives contact with a real broker.

Meaningful testing for a trading tool looks like this:

1. 01Unit tests on the arithmetic. Lot sizing, risk conversion, tick value, partial-close volumes. These are pure functions and there is no excuse for them being wrong.
2. 02Replay tests on recorded events. Feed the engine a recorded sequence — open, partial close, modify, reconnect, duplicate event — and assert the resulting state. This is where reconnection bugs surface.
3. 03Demo soak. Weeks, not days, on demo accounts that include at least one losing streak, one high-impact news event, one broker-side disconnect, and one deliberate VPS reboot.
4. 04Mismatch testing. Deliberately pair accounts with different suffixes, different contract sizes, different account currencies, and one netting against one hedging.

Budget roughly a third of the build for this. If a quote contains no testing line at all, the testing has not been removed from the project; it has been moved onto your live account.

Licensing, ownership and the exit

These are the clauses people skip and then regret.

• Who owns the source? Work-for-hire with full assignment, a licence to use a product the developer keeps selling, or something between. All three are legitimate. Only one of them lets you hire a different developer next year.
• Where does the code live? In your repository, under your account, from day one. Not on a laptop you have never seen.
• What is the handover? Source, build instructions, dependency versions, deployment steps, and a document describing the scenarios above and what the code does in each.
• What is the maintenance arrangement? Platforms ship builds, brokers change symbol conventions, prop firms change rules. A tool with no maintenance arrangement has a shelf life of about a year.
• If the tool is licensed rather than owned, what happens when the licence server is down? Ask the question in writing.

When off-the-shelf is the better answer

Bespoke is the right call when your requirement is genuinely unusual, when the logic is proprietary and you do not want it in someone else's product, or when you need to own the roadmap. It is the wrong call more often than people expect.

Buy rather than build when:

• The requirement is common. Mirroring trades between accounts, parsing a Telegram channel, logging trades to a journal — these are solved categories. A product that has been run by thousands of accounts has had its edge cases found by other people's money.
• You need it this month. A realistic bespoke copier is months, including the testing above. An off-the-shelf tool is an evening.
• You will not maintain it. Bespoke software you do not maintain becomes a liability the first time a broker renames a symbol.
• The cost of being wrong is high and the volume is low. Paying a subscription for someone else's tested reconnection logic is usually cheaper than discovering your own has a duplicate-open bug.

A sensible middle path is to buy the infrastructure and build only the thin layer that is actually yours. Our own products sit on that side of the line deliberately — a copier, a signal copier, a journal and a fundamentals desk are infrastructure, and the strategy on top of them is yours to keep.

How to brief a developer

A brief that gets an accurate quote contains six things:

1. 01The scenario list — twenty lines of "when X happens, the system does Y". Written by you, in your words.
2. 02The platforms and the brokers, named, with account types. "MT5" is not enough; "MT5 hedging on broker A, MT5 netting on broker B" is.
3. 03The non-goals. What you explicitly do not want it to do. This is as valuable as the goals and is almost always missing.
4. 04The operating environment. VPS or desktop, who restarts it, what the monitoring is, who gets woken up.
5. 05The acceptance test. The specific demo run you will do before you pay the final instalment.
6. 06The ownership and maintenance terms, agreed before work starts rather than after.

Write those six and you will get quotes you can actually compare, because every developer is pricing the same thing. Skip them and you will get three wildly different numbers, all of which are guesses about what you meant.

Where this fits

If part of what you are weighing is the licensing side of the bill, /blog/mt4-server-license-cost separates what a broker pays to run a platform from what a trader pays for tooling on top of it. And before any bespoke build touches a funded account, /blog/demo-testing-protocol-for-automation sets out the soak test that turns "it compiled" into "it survives a Tuesday".