Software Development Firms: Cube vs Mosaic for Project Margin

A fixed-bid engagement is really a bet: you estimated hours at a blended rate, and every week the actual mix of senior versus junior engineer time either protects that margin or erodes it. The forecast needs to update as the project runs, not just at kickoff and at delivery.

Cube lets you build a project-level margin model that pulls actual hours from your time-tracking system and compares them against the original estimate, sprint by sprint, with the formulas visible to anyone who wants to see exactly how a margin number was derived. Mosaic can ingest the same hours data, but its strength is aggregating across many engagements into portfolio-level views rather than giving you a bid-versus-actual variance on one project the way a project manager would want mid-build.

If most of your revenue is a handful of large, individually negotiated builds, the project-level detail matters more than the portfolio view, and that tips toward Cube.

Under ASC 350-40, certain internal-use software development costs are capitalized rather than expensed as incurred (FASB has been updating this guidance, so confirm current treatment with your CPA), which means the engineering hours behind a capitalized feature don't hit the P&L the same month they're worked. If your firm builds its own product alongside client work, your model needs to separate billable client hours, capitalized internal development, and ordinary overhead, three categories that a generic project accounting view often blends together.

This is a case where you should confirm the specific treatment with your accountant or auditor, since the exact capitalization threshold and amortization period depend on your facts and circumstances. Whichever tool you use, build the capitalization split as its own line so a swing in it doesn't get mistaken for a change in client project margin.

Unlike a product company hiring engineers against a roadmap, a services firm hires against sold and forecast work, which means a headcount plan has to flex with pipeline conversion, not just an annual budget. Bring on two senior engineers ahead of a deal that slips a quarter and you're carrying bench cost with nothing to bill against it.

Wage growth for engineering talent has been running close to broader labor market trends: overall wage growth for civilian workers sits at 3.4% year over year¹, which is a reasonable floor to assume for your merit-increase budget even before you account for market pressure on specific skill sets. Cube lets you tie a hiring trigger directly to a pipeline-weighted revenue threshold inside your own formulas. Mosaic's headcount planner is built more around steady departmental growth, so you'd be adapting it to trigger off a probability-weighted pipeline value rather than a fixed date, which is possible but not what it was designed for first.

Both platforms will happily show you Rule of 40 and department spend as a percent of revenue, since those calculations were built for subscription software companies. The median Rule of 40 score among private SaaS companies sits around 25, with the top quartile closer to 43². A services firm can compute the same math, growth rate plus profit margin, but the benchmark itself comes from a different business model, so treat it as a rough sanity check rather than a target to hit.

The same caution applies to department spend as a percentage of revenue: SaaS companies typically post R&D spend around 22% of ARR, a figure that doesn't translate cleanly to a firm where "R&D" might mean unbillable time spent on a proprietary internal tool³. Use these numbers to spot a department that's wildly out of line with a comparable business, not as a precise benchmark to hit.

• If most revenue is retainers or maintenance contracts with predictable renewal, Mosaic's recurring-revenue engine will feel like a natural fit.
• If most revenue is fixed-bid or time-and-materials project work, Cube's spreadsheet-native project economics will likely save you fighting a subscription template.
• If you're a genuine mix, expect to spend setup time in either tool making it handle the minority revenue type well, and weigh which type is growing faster in your pipeline.

Whichever you pick, keep client project margin and internal product development as separate reporting lines from day one, since blending them is the single most common way this kind of model becomes untrustworthy within two quarters.