ProphetX operates a nationwide sports prediction markets exchange, a two-sided marketplace where buyers and sellers determine contract prices, and trades are executed as CFTC-regulated derivatives contracts. Like a financial exchange, the business runs on data being fast, correct, and always available.

The analytics function at ProphetX is a catch-all. At a high level, it could be seen as the BI function, but in practice it is anything that touches a number. As Adam Musial, VP of Analytics, puts it, if it involves a number at ProphetX, it goes through him. The engineering and product teams own the exchange platform and its production databases; the analytics side receives a replica of those production tables synced into Snowflake every few minutes, and everything downstream of that is built on Bruin.

Challenges Faced Before Bruin

When Adam took over, the mandate was to build the analytics function from scratch. What existed was a single Redshift database that accumulated raw table clones from production. Tables were dumped in without indexing or proper keys: the setup existed only to sync production data into one place, not to serve analytics queries.

Two problems compounded quickly. First, the raw tables were unusable for day-to-day work, so Adam needed to precompute and organize the data into curated analytics tables that a BI tool and ad-hoc SQL could point at, without users having to reconstruct complex joins every time. The first attempts at this used Redshift stored procedures, which worked to a point but became cumbersome to manage: when one step failed, the whole procedure and the hourly pipeline failed with it.

Second, Redshift was not optimized for concurrent reads and writes. Pipelines crashed constantly because a processing job writing to a table would collide with a BI user reading from it through Sigma. On top of that, any new data source the analytics team wanted, whether Zendesk, Customer.io, or other external data, had to be scoped and built by the engineering team, which was focused on the exchange platform. A single new source could take a month to land.

Decision Points for Choosing Bruin

Adam split the problem in two. He moved analytics completely off Redshift and onto Snowflake. He then brought Bruin in as a proper ingestion and orchestration layer, a single tool that allowed him to plug in new data sources himself, and to build his curated datasets on top of all of them.

He evaluated dbt first, having read that it was the gold standard, but it did not fit the way ProphetX's data actually behaves.

The ability to run pure SQL in Bruin, including UPDATE and Snowflake MERGE statements, was the deciding factor. It meant Adam could drop in the stored procedures he had already written and have them work out of the box, rather than re-engineering everything to fit a specific format.

“I could very easily copy and paste everything I already had, and migrate it to Bruin. I didn't have to re-engineer anything the way I probably would have had to with dbt.“

The second factor was self-serve ingestion. With Bruin and ingestr, the sources that used to require a month-long request to the engineering team, Adam could now build himself in an afternoon.

The Redshift to Snowflake Migration

Bruin was not the reason ProphetX migrated off Redshift, but it was how the migration was executed. Adam already had a solid set of pipelines running as stored procedures; he did not want to reinvent them, only transplant them to Snowflake.

“Bruin wasn't why we migrated, but it's absolutely how we did it. I broke each stored procedure into individual Bruin asset files and chained them into pipelines. At no point during the migration did I have a single non-Bruin pipeline running.“

Working at a moderate pace while still keeping Redshift running, the pipeline rebuild and BI tool repoint took about a month. Because all orchestration lives in Bruin and all the code lives in one GitHub repo, Adam gets full lineage and documentation as a byproduct, a context layer he later reused to build far more on top.

Impact of Bruin

Since the migration, the speed of shipping new data has changed dramatically. Adam has roughly tripled the number of pipelines and processing assets, driven purely by how fast he can add something new.

“I had an engineer try to export raw Customer.io data to Redshift. It took him about a month and a half to get anything off the ground as he navigated competing priorities. The exact same thing on Snowflake through Bruin, with modern LLM tools, took a day.“

That speed shows up across the business. When an executive suggests pulling in a new external data source, Adam can go from idea to a daily-ingesting production table in about two hours. The result is that even as ProphetX's operations and headcount kept growing over the last year and a half, Adam has kept his team lean, taking on work and analytical projects that would otherwise be prohibitive, or spread across the whole data and engineering team.

Building on top of Bruin

With every Bruin asset file declaring table and column descriptions, types, and checks, Adam was able to use those YAML files as the golden semantic layer, without the need to declare and maintain a separate Snowflake-native copy. He added domain tags, metrics, and key table relationships, turning each table's asset file into the authoritative context source. Automated CI checks in GitHub prevent drift and enforce quality standards, while separate overnight processes scrape the company's public Slack channels and other documentation sources into a retrievable knowledge base layer.

Adam extended Bruin's lineage past the warehouse. Using Sigma's API, he connected Bruin's DAG through to the BI layer to build a global DAG of over a thousand nodes, giving him the complete blast radius of any upstream change all the way down to a specific report or export. Metric definitions and detailed column descriptions live in the Bruin glossary as the golden copy, and are automatically propagated down to Snowflake table comments, and up to Sigma as defined metrics inside data models and dashboards.

What the data powers

Nearly every data-dependent decision at ProphetX runs through this stack:

• Marketing: deal evaluation, customer acquisition, and attribution across sources like Customer.io, AppsFlyer, and Firebase, including payout calculations for 200+ referral partners.
• Risk and fraud: withdrawal approval checks for flagged activity, served to the risk control team for faster approval decisions.
• Customer support: a Zendesk widget that pulls a full customer profile (activity, deposits, play history) into one place on every ticket.
• Simulations: modeling how a change to the sign-up offer would have played out against historical customers.
• Leadership: daily and weekly company KPIs.

Why ProphetX Rarely Asks for Help

Everything lives in one documented Bruin repo: ingestion, transformation, orchestration, quality checks, and definitions. So when something needs attention, there's a single place to look for context, expectations, and a history of past investigations. That is what lets a small team operate independently: issues get triaged in minutes instead of handed off between the owners of different systems.

When something does break, having the entire processing stack in one repo makes diagnosis fast.

“If something crashes, I have a root cause analysis done in 15 minutes and can act on it right away. A single investigation can go all the way to the root, rather than stopping at a table someone else owns that we know nothing about.“

Conclusion

ProphetX has not only immediately capitalized on Bruin's headline benefits, but also used it as the foundation for building a modern analytics data stack, holding both company data and institutional knowledge in a single semantic layer that enables self-serve analytics.

“Bruin has been instrumental in supporting our organization's growth from its early startup days to where we are today. We're really just scratching the surface with what the platform can deliver, and I look forward to rolling out Bruin's latest functionality to my users.“