DEV Community

Kamal Lattai
Kamal Lattai

Posted on

Modeling a Prop Firm Comparison Table: Notes on Structure

Prop trading firms sell evaluations: a trader pays, trades under a set of rules, and gets access to firm capital on success. Firms publish their terms in different ways: in prose, in FAQs, in pricing grids. Turning that into a table people can actually compare is mostly a data-modeling problem, and it has a few traps worth writing down.

Transpose the table

Spreadsheets put items in rows and attributes in columns. For a side-by-side comparison of a few items with many attributes, flip it: firms become columns, attributes become rows. The eye then scans horizontally across one attribute, which is the comparison people actually want. The catch is width, so cap the number of columns. Four columns usually fit on a laptop screen without horizontal scrolling; PropFirmKey's comparison view, for example, stops at four firms.

Group the rows

A flat list of attributes is hard to read. Group rows into sections that match how traders think: cost, profit split, payout terms, trading rules, reviews. Sections also give you a natural place for "show more" collapsing on mobile.

Don't flatten rules into numbers

The tempting schema is maxDrawdown: number. It's wrong, because the same number behaves differently depending on how it's measured. Model the mode explicitly and keep a free-text note for edge cases:

// Illustrative only, not a production schema
type DrawdownMode = "static" | "trailing" | "end_of_day";
type Tri = "allowed" | "restricted" | "unknown";

interface Limit {
  value: number;
  unit: "percent" | "currency";
  note?: string;
}

interface ProgramTerms {
  firm: string;
  market: "forex" | "futures";
  price: { amount: number; currency: string };
  profitSplit: { traderShare: number; note?: string };
  payout: { frequency: string; firstPayoutCondition?: string };
  rules: {
    dailyLoss?: Limit;
    maxDrawdown: Limit & { mode: DrawdownMode };
    newsTrading: Tri;
    weekendHolding: Tri;
  };
}
Enter fullscreen mode Exit fullscreen mode

Make "unknown" a first-class value

If a firm's terms don't say whether something is allowed, store "unknown", not false. Coercing missing data into a negative quietly turns a gap in the source into a claim about the firm. In the UI, render unknowns visibly so readers know to check.

Let the reader choose the column order

A side-by-side view has to put something first, and readers tend to assume the first column is the recommendation. A safer default is the order in which the user picked the firms. Sorting by a single attribute, such as price, should be an explicit action the reader takes, with the active sort clearly shown. That keeps the layout from implying an endorsement nobody intended.

Plan for narrow screens

On a phone, four columns don't fit. Two patterns work: pin the attribute labels and let the firm columns scroll sideways, or switch to one card per firm with the same section order so readers can still compare by swiping. Whichever you choose, keep the row order identical across firms, since consistency is what makes comparison possible.

Keep keys language-neutral

PropFirmKey runs in English and French. Field keys like weekendHolding stay the same, and only the labels get translated. Free-text notes are the hard part: they need translation too, so keep them short and factual.

Put the business model in the interface

Comparison tables are often funded by affiliate links. Ours is, and the site discloses it. Firms also can't pay to rank higher. If your table has a commercial relationship behind it, say so near the table, not three clicks away. Readers adjust their trust accordingly, which is the point.

Seeing it assembled

If you want to see these ideas in a working interface, there's a live version of this layout covering forex and futures prop firms. I'd be glad to hear how others model conditional rules like these; drop a comment if you've solved it differently.

Top comments (0)