A trading desk that owes you no story
Why we built inite.fund the way we did. The five constraints we keep coming back to.
The reason most retail trading software is bad is that the people who build it are selling stories: the AI that beats the market, the secret indicator, the proprietary edge. The reason most institutional trading software is bad is that it’s been ground down by a decade of feature requests and now does everything badly.
inite.fund sits in the middle. Not retail, not institutional. Not selling a story. We’ve spent 18 months building, breaking, and rebuilding it; here are the five constraints we keep coming back to.
1. The methodology has to be defensible without us in the room
If a method needs us to explain why it worked in retrospect, it’s not a method — it’s a narrative. We’ve ripped out plenty of features that backtested beautifully but couldn’t be explained in two sentences.
Test: ask Claude to read the code in the repo. If the strategy can’t be summarized to someone who’s never seen it, it’s not a strategy.
We learned this the painful way with a Q-learning exit policy on the trading sleeves. It learned. It worked in backtest. We couldn’t explain to ourselves why it picked specific exit timings. We deleted it and went back to fixed rules. Fixed rules ship faster, debug faster, fail more predictably.
2. The audit trail comes before the feature
Every state change writes a row. Mode changes append to mode_history.
Capital flows have an audit_ref that makes them idempotent. Every MCP
tool call hits audit_log before it returns. Every trade has its own
project state machine, replayable from disk.
This isn’t paranoia. It’s that financial software fails strangely. When something is wrong at 03:14 on a Sunday morning, the question is never “what should the code do” — it’s “what did the code actually do”. If you don’t have logs, you reconstruct from theories. Theories lose to logs.
The audit trail also unlocks MCP. Claude calls set_mode, the audit
log says “via mcp:user#7”, you read it back later and know exactly who
and how. Same trail whether you click a button or type a sentence.
3. Per-user is the unit of blast radius
The old version of inite.fund had one global “trading user” — keys in shared settings, accessible to everyone with admin. We rebuilt that this quarter.
Now every strategy is owned by exactly one user. Long sleeves, trading accounts, vault entries, tokens — all per-user. If a user is compromised, you revoke their token and rotate their venue keys. Their strategies enter degraded mode. Other users don’t notice.
This costs more code than the global model. It pays for itself the first time you have to onboard a third operator without rotating everyone else’s keys.
4. Real-time is a feature; freshness is a budget
Real-time data is expensive. Hitting the venue every tick is expensive. SSR-rendering a marketing page on every request is expensive. So we set a freshness budget per surface and design to it.
- The cockpit dashboard SSE-streams from a 5–15s tick. Free.
- The marketing site SSR-renders with 30s edge cache. Effectively free.
- OG cards (link previews on Twitter / Discord) are rendered on demand from product API, cached 5 minutes by the embedding platform anyway.
- The MCP tools fetch fresh state on every call. The fact that there are only ~20 calls/day per user means freshness is essentially free.
There’s no global “real-time” claim — there’s a per-surface freshness budget. “AUM updated 10 seconds ago” on /strategies means exactly that; the dashboard ticks faster, the OG image ticks slower.
5. Build the thing two operators want
The hardest design decision in this kind of software is who is it for. A retail user wants chat-bots and emojis. A hedge fund wants compliance hooks and FIX. We picked the middle: someone who would be running a small allocation by hand if the software didn’t exist, who can read code, and who cares more about not losing money than about getting rich fast.
That picks the rest of the design:
- Invite-only access. No self-serve sign-up. Onboarding is a conversation.
- Encrypted vault for venue keys, plaintext shown once. Same model Stripe uses for restricted-keys; same instinct.
- MCP first, dashboard second. The dashboard exists for monitoring
- emergency action. Most edits go through Claude.
- Plain markdown skills, not a closed plugin system. You read them. You fork them. You ban us from updating them if you want.
What we won’t ever do
- Promise returns. Any number we publish is a track record, not a forecast.
- Black-box your money. The whole stack is auditable; the code is internal but the methodology is in this blog.
- Sell on FOMO. Invite-only, capped onboarding rate, no public sign- up. If you’re not sure, wait. The desk will still be here next month.
- Trade your money without your keys. Every strategy reads from your vault. We don’t custody.
What we will ever do
Build software that respects the operator. Run a methodology that doesn’t need a story to defend it. Open enough of the architecture to prove we’re not selling magic. Hire one user at a time and walk through onboarding ourselves until the kinks are gone.
The rest is execution.
— inite team
- 2026-05-11A ledger you can't quietly rewrite
Every capital flow, every approval, every mode change lands in an audit log with a hash chain. Why this matters in trading software, and how to verify integrity in under a minute.
- 2026-05-09When the engine stops
The algorithm runs itself. But in three cases it asks the operator, and in one more it simply lies down. A walk-through of how the HIL queue, strategy modes, and the kill switch fit together — and where the line between them is.
- 2026-05-06Drawdown as a throttle, not a brake
Why the long sleeve cuts risk at −8% — well before the −15% target band — and why the cut is partial rather than total. The math, the philosophy, and the edge cases that broke our first three designs.