How we build
Working once is not the same as being reliable
Almost anyone can write an indicator that draws the right line on a chart they are watching. The distance between that and something you run with money on the line is where most of the work is — and almost none of it is visible in a screenshot.
The market does not send tidy data
A calculation is only as good as its worst day.
On a normal session with a clean feed, most implementations of the same idea agree. The differences appear on the days that are not normal: a session that rolls over at an unexpected hour, a shortened holiday session, a contract roll, a gap, a feed that drops ticks and backfills them later.
Those days are not rare enough to ignore, and they are exactly the days a reference level matters most. A tool that quietly draws yesterday’s level on a day when yesterday was a half session is not slightly wrong — it is confidently wrong, which is worse than showing nothing.
What this means in practice: the boring cases get the attention. Rollover boundaries, session definitions and edge dates are worked out deliberately rather than inherited from whatever the platform defaults to.
Speed is a correctness requirement, not a nice-to-have
A tool that stutters in the minute that matters has failed.
Indicators run inside your platform, on the same thread as everything else you have open. Work done carelessly on every incoming tick does not stay contained: it slows the chart, and it does so hardest when the market is fastest, because that is when the ticks arrive.
This is why we treat responsiveness under live load as part of whether a tool is finished, not as tuning to do afterwards. The moment a tool costs you a fraction of a second of attention during a decision, it has taken more than it gave.
The test that counts is not whether it looks smooth on a quiet afternoon with one chart open. It is whether it stays smooth on a busy session, on the layout you actually trade, with everything else you run.
Surviving the platform, not just running on it
Software that only works on a fresh start is not finished.
Real use is untidy. Charts get closed and reopened, templates get reloaded, the same tool gets applied twice, the platform gets restarted mid-session, a data connection drops and comes back. Each of those is a moment where state can be left behind or resources can leak.
None of it is visible when a tool is working. All of it is visible three hours later, when something slows down or stops drawing and there is no obvious reason why.
What this means in practice: a tool has to clean up after itself as carefully as it sets itself up, and behave the same on its fifth reload as on its first. That is unglamorous work and it is most of the difference between a script and a product.
If we cannot explain it, we have not finished it
You cannot take responsibility for a calculation you cannot inspect.
Every reference a tool draws has a rule behind it. That rule gets written down: what the level is, how it is computed, when it updates, and what it deliberately does not tell you. Writing that fourth part is often what exposes a calculation that was never as solid as it looked.
This is the practical side of refusing to ship a black box. It also sets the standard for support: a question about how something is computed has an answer, and if it does not, that is a defect in the tool rather than an inconvenience for you.
The reference for each tool lives in the documentation, alongside the rest of what you need to run it.
Most of the decisions are about what to leave out
Every element on a chart costs attention, whether or not it earns it.
The easiest way to make a tool look valuable is to make it do more. It is also the fastest way to make it useless, because a screen with everything on it is a screen you cannot read. A feature that is merely interesting is a feature that competes with the ones that matter.
So the question we ask of anything new is not could we build this? but does this earn the space it takes and the attention it costs? Most candidate features do not, and the honest answer is to leave them out.
The same restraint decides what we refuse outright — no signals, no probability scores, no black box, no auto-trading. Those are not gaps we intend to fill later. See what we don’t do.
None of this shows up in a screenshot
Which is the awkward part of selling tools built this way: the work that makes them trustworthy is invisible, and the work that makes them look impressive is the work we deliberately do not do. We would rather explain the difference than decorate around it.