I'm deep in the evaluation phase for Braintrust for our dev and data science teams. The platform looks powerful, but as usual, the pricing page and case studies are heavy on features and light on the one number that really helps you model the cost.
Everyone talks about the 0% marketplace fee (which is a great differentiator), but for internal budgeting, I need to translate that into a predictable metric.
So, for those already using it: **what's the single most useful metric for forecasting your monthly Braintrust spend?**
Is it:
* **Hourly rate of your most common talent tier?** This seems obvious, but is the spread between "Entry" and "Expert" too wide to be useful?
* **Average project duration** from your internal history?
* **The platform fee on top of the hourly rate?** (They say 10% + payment processing, but are there clear line items for this on the invoice?)
* Or something else entirely, like a blended average hourly cost you've back-calculated from total invoices?
I'm trying to build a simple model in the spreadsheet. Knowing which variable has the least variance would be a huge help. Real-world examples of how this metric behaves would be perfect.
Great question. I've been running our Braintrust spend through our accounting software for about eight months, and I can tell you the single most predictable metric for us has been the **blended average hourly cost**.
The hourly rate spread is real, even within a single tier. You might budget for a "Mid-Level" developer at $85/hour, but in practice we've seen those contracts settle anywhere from $75 to $95 based on the specific skill mix needed. The platform fee (it's a clean 10% plus Stripe processing, shown as separate line items) is constant, so it doesn't introduce variance.
What worked for our model was taking our last three months of total invoiced spend and dividing it by the total logged hours. That gave us a blended rate that absorbed all the tier and rate variation. We now forecast using that number multiplied by our estimated monthly hours, and it's been within 5% of actuals. Start with your best guess for hours, then use a blended rate you refine after your first few projects.
api first
Blended average hourly cost makes a lot of sense, thank you! It seems like the variance within tiers is the key thing I wasn't considering.
A follow-up, if you don't mind: how did you settle on three months of history as the right amount? I'm worried that with only a couple of small initial projects, our blended rate might swing wildly for a while. Did you use a placeholder rate until you had enough data?
Three months is a reasonable rule of thumb for smoothing out project variance. If you're just starting, don't use a placeholder rate. It's better to model based on your actual hiring plan.
Example: If you know you need 150 hours next month, split it. Budget 100 hours at your expected standard rate and 50 hours at a 20% premium for a niche skill. Track the actuals against that explicit assumption. That gives you a hypothesis to test as your data accumulates.
Using a single blended number too early just hides the sourcing decisions you're making.
Data over opinions
I largely agree with the strategy of modeling from your hiring plan instead of using an early, volatile average. That approach forces a necessary conversation about skills mix and scarcity.
My caveat would be on the 20% premium assumption. In practice for hard-to-find skills like specialized MLOps or legacy systems, we've frequently seen premiums of 40-50% over the platform's 'standard' rate for a given tier. Your initial model should factor in this potential skew, maybe by running a pessimistic scenario alongside your expected one.
Starting with an explicit hypothesis, as you suggest, is the correct move. Just ensure your hypothesis about rate variance is informed by actual marketplace searches for those niche roles, not just an internal multiplier.
Mike