CodeMarketLabsHow prop firms actually work behind the scenes, the two business lines, the B-book and A-book, and how I built Polyquid, a platform letting traders use one account across Hyperliquid perpetuals and Polymarket, solo in 33 days on Python, Django, FastAPI and Next.js, with latency under 100 microseconds.
2026-09-08
I talk a lot on this channel about trading, investing, and making money in the markets. What I have never told you is that trading and investing are not my only source of income. I also build financial software, and that double background is what got me into market finance in the first place, first as a trader, then as a portfolio manager. My last development project was Polyquid, a prop firm platform that lets you trade Hyperliquid perpetuals and Polymarket from a single account. Before I break down how I built it, I want to use this video to actually explain how a prop firm works behind the scenes, because once you understand that, you will look at every challenge you have paid for differently.
A prop firm challenge works like this: you get evaluated on your trading performance while respecting precise risk rules. If you pass, the firm gives you capital to trade with. If you make a profit on that capital, the profit is shared between you and the firm. Concretely, that means every prop firm runs two business lines. The first is the challenge itself, your evaluation, up until the firm decides your account is validated and funded or not. The second is trading, once you are funded.
Trading itself happens across two books. The B-book is a pool where your positions never actually touch the real market. All the positions of every trader on the firm get aggregated into that pool, and the residual risk left after aggregation is the risk the firm itself carries against its traders. The A-book is the opposite: positions go straight to the real market, meaning straight to Hyperliquid or Polymarket, in Polyquid's case, the moment a funded trader buys or sells.
The B-book is usually the part that sounds suspicious when I talk about this with other traders or investors. It should not be. Your orders go to the firm, and the firm aggregates the risk of every trader on the platform, which means traders are effectively trading against each other, exactly like on a normal market, except this particular market is administered by the firm itself. Whatever residual position is left over, the firm carries it. At the end of the day, a prop firm's actual job is risk management, and the risk to manage is enormous: thousands of traders, sometimes several funded accounts each, sometimes dozens of open positions per account, and often trading bots running on top of all of it.
Polyquid is a prop firm that lets you pass a single challenge and then trade Hyperliquid perpetuals and Polymarket prediction markets from that same funded account, at the same time. That single-account requirement is what made the engineering side of this project the real challenge, not the trading side. While most people who join a prop firm go through a trading challenge, the challenge Polyquid handed me when they brought me on to build their platform was an engineering one, and I took it on alone, in 33 days.
The first brick is the one everyone skips over when they talk about building a platform: the database and the foundation of the whole project. Account creation, login, logout, password changes, password reset, mailing, all of it. Nothing else works if this brick is wrong.
The second brick is the entire challenge lifecycle, from a challenge account to a funded account: setting up the challenge, setting up the risk limits, letting the trader trade live with real Hyperliquid and Polymarket data without latency, executing their positions under the best possible conditions for efficiency and latency, then continuously monitoring risk on their account, checking in real time that every rule is respected, and finally deciding whether the challenge is passed or failed, and converting that account into a funded one or not.
The third brick is the funded account and trading side, and this is where it gets genuinely complex, because at that point you have to aggregate every position across the whole platform, in real time, across every funded account, and pilot risk according to the limits given by the client. All of that has to run while staying permanently connected to Hyperliquid and Polymarket without any latency, because latency is exactly what lets other traders arbitrage your own platform.
For this, I used a stack in Python, Django and FastAPI, all running on AWS, with a Next.js frontend. It is the stack I know best, and on a project like this, familiarity is not a luxury, it is what lets you move fast without introducing the kind of bug that costs a prop firm thousands of euros in minutes.
The constraint was never just making the prop firm work, that part would have been too easy. The real constraint was making the entire architecture handle full production load from the very first version shipped, because a prop firm with a bug or with latency loses thousands of euros almost instantly. Calculating, managing and covering a prop firm's risk happens constantly, not every hour, every single instant.
That means building an architecture where every piece is isolated. Risk control is separate from data. Data is separate from account management. Account management is separate from order management. Every part of the infrastructure has to be isolated and autoscaled to keep up with real-time client demand. In practice that is not one API you build, it is five, six, sometimes dozens of separate APIs. The result is a scalable infrastructure with latency under 100 microseconds, letting people run their challenge and their funded account under the best possible conditions on both markets Polyquid offers.
Building all of this alone in 33 days was not easy the whole way through, and I will be honest about that. The reality of being a solo developer is that you have to get the architecture as right as possible from the very start, because you cannot afford to be wrong. Going back and rebuilding a section means throwing an entire project away. Today, with AI, and specifically with Claude Code, which I use personally, actually typing a line of code is something that happens less and less for me.
But the job itself has completely changed. My job today is not writing lines of code, it is building the architecture, driving the project, and knowing exactly how to break it down into small enough tasks that I can delegate them to AI agents. If you do not know how to do that, AI will not get you anywhere, no matter how good the model is. What all of this new technology actually gives you is the ability to build something like this not in a year, not in six months, but in 33 days. There were still hard days in there, and nights I did not sleep to finish a piece of code and get it into testing before my clients woke up French time the next morning.
The first thing to check when picking a prop firm is rule transparency and rule stability. The rules have to be written down from the start, in a proper document, and they have to be precise and match the asset class you are trading. A 0.50 percent drawdown limit on crypto, for example, is something you will never realistically hit, no matter how good you are, and you know that as well as I do. The rules also cannot be volatile, meaning they cannot change over time. If a firm signs you up for a challenge or a funded account under a given set of rules, it cannot come back the next day and point to fine print saying the rule could evolve depending on market conditions. Rules have to be fixed in advance, because you are paying for a challenge to access those specific rules, not to access rules that turn out to be flexible.
The second thing to check, and this one tells you immediately whether you are dealing with a real risk management business or just a machine built to take your money, is to actually go and pass a lot of orders and watch how the platform reacts. If a prop firm has latency on the challenge side, on a calm day with no volatility, while you are just testing it, imagine what happens the day every single client of that firm needs to exit the same position on the same asset at the same time. At that point, good luck getting out before you get liquidated. That is an immediate sign the infrastructure is not up to standard, and an infrastructure that is not up to standard means a firm that did not want to invest in itself. This is exactly what I built for Polyquid in 33 days, so it could offer a trading experience worthy of the best trading firms in the world. If you want to check out the platform, there is a link in the description, and if you are working on your own SaaS or financial platform, there is also a link for a free call to scope your project, its architecture and its timeline.
No. In the B-book, your orders are aggregated with every other trader's orders on the platform, which means traders are effectively trading against each other like on a normal market, just administered by the firm. The residual risk left after aggregation is carried by the firm itself, and managing that risk at scale is the firm's actual business.
Because it is the stack I know best, and on a project where the whole architecture has to handle production load from day one, familiarity with your tools matters more than chasing the newest framework.
By isolating every piece of the system, risk control, data, account management and order management, into separate, autoscaled services from the very start, since there is no room to redesign the architecture halfway through a solo build.
Two things. First, that the rules are written down, precise, matched to the asset class, and fixed in advance. Second, that the platform holds up when you actually place a lot of orders on it, not just when it is quiet.
No. What changes is the job itself, from writing lines of code to designing the architecture and breaking the project into small tasks you can delegate to AI agents. Without that skill, AI will not get a complex project like this anywhere.
How prop firms actually work behind the scenes, the two business lines, the B-book and A-book, and how I built Polyquid, a platform letting traders use one account across Hyperliquid perpetuals and Polymarket, solo in 33 days on Python, Django, FastAPI and Next.js, with latency under 100 microseconds.
The CFTC publishes 30 years of futures positioning data every Friday — buried in a legacy ZIP file with 300 columns and no API. We built one. A REST API that ingests, normalizes, and exposes COT data across 398 futures contracts with Z-scores, pressure metrics, COT Index, and divergence signals computed on the fly. Full architecture walkthrough: Django ORM, incremental sync pipeline, API key authentication, and a live Z-score snapshot across all mainstream contracts.