We ship software for a living, not trade signals. But the longer we run a studio that has put 30+ platforms into production, the more one pattern shows up everywhere: the systems that fail are the ones that depended on a person staying calm and making the right call in the moment. Markets are no different. This is an educational piece about thinking, borrowing the discipline that ships reliable code and pointing it at how people approach markets. No calls, no targets, no promises.
The shared failure mode
When an engineer says a system is "reliable," they almost never mean it's fast or clever. They mean it behaves the same way under load as it does on a quiet afternoon: the behavior is written down, the edge cases are handled before they happen, and nobody has to improvise at 2 a.m. The opposite, undocumented discretion under stress, is where most outages actually come from, and it maps onto trading psychology almost perfectly. Picture two scenarios. In the first, a service starts throwing errors during a traffic spike and an on-call engineer, tired and rushed, manually edits a config in production because they "know what the problem is." In the second, someone watching a market sees a fast move, abandons the plan they wrote that morning, and acts on a gut read because this time feels different. Different domains, identical structure: a stressed human overriding a documented process with in-the-moment judgment they can't fully explain and won't be able to reconstruct later. Discretion isn't the enemy by itself, experienced people make good intuitive calls constantly. The problem is undocumented discretion under stress, the combination. Stress narrows attention, compresses time horizons, and makes the most recent input feel like the most important one, a fine state for sprinting away from danger and a terrible one for evaluating probabilities. In engineering we don't trust ourselves there; we build guardrails so the system holds even when the operator is depleted. Most people never extend that same distrust to their own decision-making around markets.
Borrowing the engineering toolkit
If the failure mode transfers, the fixes should too. Engineering has spent decades building defenses against fallible humans under pressure, and four of them translate cleanly into a framework for thinking about markets. None of them tells you what to think; they constrain how and when you decide, which is the part stress corrupts. The throughline is that each one decides behavior in advance, while you're calm, and then executes it later, when you're not.
- Written rules (the spec). A rule you wrote on a quiet morning is a message from your clearest self to your most stressed self. "I act only on setups matching conditions A, B, and C, sized within range X" is a rule a stranger could grade you against. "I'll be careful" is a hope, not a rule.
- Logging (the journal). You can't debug a system you can't observe. A trading journal isn't a diary of feelings; it's a structured log of the decision, the conditions, the rule that applied, and whether you followed it, recorded separately from whether it worked. Process and outcome are different variables; conflating them is the most common analytical error people make about markets.
- Post-mortems (blameless review). Reconstruct the timeline and ask what about the system let it happen, not who to blame. Did I follow my rule? If yes and it failed, revise the rule on a calendar, not in the heat of the moment. If no, that's the finding, regardless of the result, a broken rule that happened to pay off is still broken.
- Circuit breakers (removing discretion at the edges). Resilient systems trip a breaker before a cascading failure, automatically, no human in the loop. The human equivalent is pre-committing to stop conditions that fire without asking the stressed operator for permission. Design them cold, honor them, and you've removed discretion exactly where it fails worst.
You don't rise to the level of your goals; you fall to the level of your systems. Markets just charge admission to learn it.
— A reframing of a well-worn engineering truth
Why your brain fights this
If written rules and logging are obviously better, why does almost nobody do them consistently? Because the same cognitive shortcuts that make us efficient also make us systematically wrong under uncertainty, and they feel like insight while they're happening. None of the usual suspects below is fixed by trying harder or being smarter; they're features of the hardware, and you don't out-discipline your own neurochemistry in real time. A short, honest list:
- Recency bias, the last few outcomes feel like the trend, so a calm rule written last week gets overruled by what happened five minutes ago.
- Loss aversion, the discomfort of a loss outweighs the satisfaction of an equivalent gain, which quietly distorts how long you hold onto a losing position versus a winning one.
- Outcome bias, judging a decision by its result rather than by whether the process was sound. A reckless decision that worked teaches exactly the wrong lesson.
- Narrative fallacy, the brain manufactures a clean cause-and-effect story for what is mostly noise, and a good story feels like understanding.
- Sunk-cost reasoning, justifying a current decision by past commitment rather than present conditions, the trading version of refactoring around a bad abstraction because you already wrote it.
The software side: build the boring part
Because we're a studio, the part we're actually qualified to talk about is tooling, and the good news is that the discipline above is mostly a data problem with clean software answers. You don't need a prediction engine; you need a reliable record. The most useful thing most people could build is also the most boring: a structured journal that makes it trivial to log a decision and impossible to retroactively edit the story, append-only, timestamped, process-fields-first. Note in the schema below there's no pnl field near the decision record, that's deliberate: you log the decision and its conditions at the time and reconcile outcome later, in a separate step, so the two never contaminate each other in memory. A table like this, backed by something durable (Supabase Postgres is what we'd reach for) plus a chart over the followedRule column, answers the only question worth asking, are you executing your process or improvising? The honest answer is usually humbling, which is exactly why people avoid building it. The upstream plumbing is covered in Data Pipelines for Markets.
// A decision log, not a P&L tracker. Process fields first.
type DecisionLog = {
id: string;
ts: string; // ISO timestamp, set on write
ruleId: string; // which written rule this maps to
conditionsMet: boolean; // did A, B, C actually hold?
sizeWithinPlan: boolean; // inside the range you set cold?
emotionalState: 'calm' | 'rushed' | 'fomo' | 'tilted';
note: string; // what you saw, in your own words
// outcome is reconciled LATER, in a separate write:
reviewedAt?: string;
followedRule?: boolean; // the only field that grades YOU
};
// Append-only. No edits to past rows. The history is the point.
function logDecision(entry: Omit<DecisionLog, 'id' | 'ts'>): DecisionLog {
return { id: crypto.randomUUID(), ts: new Date().toISOString(), ...entry };
}Process is the only thing you control
Here's the uncomfortable symmetry that ties it together. In software, you can't control whether a third-party API goes down, whether traffic spikes, or whether a dependency ships a bad update, only the quality of your own system: its rules, its observability, its ability to fail safely. In markets, an individual controls even less of the outcome and none of the price. The single thing fully inside anyone's control is the quality of their own process, the rules, the logging, the reviews, the pre-set limits. Everything else is weather. Which is why the systems lens is, in the end, a humility lens: it stops you asking the unanswerable question ("what will happen?") and redirects you to the answerable one ("did I execute my process?"). A clear-headed person with a written process and an honest log is not guaranteed any result, markets owe no one anything, but they've done the only part that was ever theirs to do. Reliability isn't the absence of bad outcomes; it's the presence of a system that behaves the same way whether or not you're scared. That's the whole job, and it's exactly the kind of boring, reliable software we build, CRMs, dashboards, data pipelines, where the discipline lives in the code and not in someone's willpower. More on the engineering in Market Structure for Builders, the dashboard side in Building a Markets Dashboard, or see what we ship on /products.
Want a tool that keeps the calm version of you in charge, a clean decision log, a real-time dashboard, the boring infrastructure that just works? That's what we build.
Talk to the studioQuestions, answered
- Is this article giving trading or investment advice?
- No. It is strictly educational. It covers decision processes, software tooling, and psychology, not what to buy, sell, or hold. Nothing here is a recommendation, signal, or forecast, and no outcome is promised. Markets carry real risk of loss; consult a licensed professional for advice.
- What does 'undocumented discretion under stress' mean?
- It's the shared failure mode between engineering and markets: a stressed person overriding a documented process with in-the-moment judgment they can't fully explain or reconstruct later. Stress narrows attention and over-weights recent inputs, which is exactly the wrong state for weighing probabilities. The fix is to move decisions earlier, decide cold, write it down, and execute the plan.
- What's the minimum tooling to apply this?
- An append-only, timestamped decision log that records the rule, whether conditions were met, your emotional state, and, in a separate later write, whether you followed your own rule. Keep outcome (P&L) out of the decision record so process and result don't contaminate each other in memory. A simple Postgres table plus a chart over the 'followed rule' field is enough to start.
The stack we actually use
The tools below run our own systems and the ones we build for clients. A few are affiliate links — they support The Signal at no cost to you.
Some links on this site are affiliate links. If you click through and sign up or buy, J Supreme Tech may earn a commission at no extra cost to you. We only recommend tools we actually use to build and run our own systems. Full disclosure.