← chintan shingala / home case study 2 of 4
  CASE STUDY — PRE-TRADE

The brief asked for a data room. The answer turned out to be a product line.

Role
PM, leading the Pre-Trade squad
Timeframe
squad takeover → client demo, <2 weeks
Status
in client evaluation
Audience
a major private markets investor

The situation

We were invited into an RFP for a virtual data room — before we had a data room to show. I'd just taken over the Pre-Trade squad, and this landed as priority one. What follows is why we didn't build quite what was asked, told through three decisions.

note: visuals on this page are redrawn concept illustrations — the real client work stays confidential.

the domain, in a sentence: a data room is the secure space where a fund manager shares confidential documents with prospective investors during a raise. "pre-trade" is everything before an investor commits — marketing the fund, sharing documents, fielding questions, tracking interest.
fig. 01 — the new cycle
Diagram: two timelines. Then — a long line through pitch deck, RFP, procurement, build, deliver, taking months. Now — a short cobalt line from build to in-the-client's-hands, taking weeks.
decision 01

Reframing the brief

Sketching the data room honestly, we found we were recreating something established providers already do well — and data rooms are straightforward enough that parity was a losing game. What GPs were actually describing was an integrated workflow: fundraising is more than sharing documents. So we pivoted the prototype into a complete pre-trade experience — fund, marketing, data room, access, analytics — modular enough to sell standalone. The risk: walking into an RFP with something they didn't ask for. The bigger risk: a worse version of something they could already buy.

the alternative we rejected: build the VDR to spec, compete on parity, and hope execution quality carries it against incumbents purpose-built for the category.
decision 02

Drawing the scope line

Access control had to exist — GPs manage who sees what very carefully. But user-level permissions would have rippled through the entire data model and swallowed the two-week timeline. We drew the line at the level GPs manage day-to-day and deliberately deferred the rest. The prototype's job was to prove the reframe, not exhaust the spec — every scope call in those two weeks was that question in miniature.

the alternative we rejected: model permissions "properly" from day one — and demo a fraction of the product two weeks later.
decision 03

Handing over at production standard

This wasn't a projector demo — the prototype was going into the client's hands, and GPs managing billions expect bespoke service, not a staging link with shared credentials. We hosted it behind real Cloudflare authorisation and linked logins to auditing and engagement data. Which had an effect we fully intended: the analytics we were pitching as a feature were already running on their own usage from the first login.

the alternative we rejected: a standard staging link with shared access — faster to set up, and corrosive to everything the pitch was claiming about analytics, auditability and trust.

Where it landed

Demoed inside two weeks of taking over the squad. What landed most was the end-to-end thinking — the module covered everything they actually consider when marketing a fund, with the engagement analytics drawing particular interest for informing future raises. Warmly received; now in the client's hands for evaluation. I'll update this page when there's more to say.

We could afford to change our answer mid-RFP because being wrong had become an afternoon's work, not a quarter's.
from: how i think about building