A rate card is a table of roles and their cost per unit of time — senior engineer per day, designer per day, and so on. Agencies publish them to clients; internal teams use the same structure to convert planned effort into budget. Either way, its job is to turn a scope estimate into money.
What a usable rate card contains
- Role, not person. "Senior backend engineer", not a named individual, so the card survives staffing changes.
- Unit. Day rates are typical; hourly invites micro-accounting, monthly hides utilisation.
- Seniority bands that mean something specific — define them, or every role drifts upward over time.
- Currency and validity period. A card without an expiry gets quoted from two years later.
- What the rate includes — is QA separate, is project management billed, are revisions bounded.
Turning it into an estimate
Scope Role Days Rate Cost
--------------------------------------------------------
Discovery Senior engineer 5 $X 5X
Product designer 3 $Y 3Y
Build Senior engineer 20 $X 20X
Mid engineer 25 $Z 25Z
Hardening Senior engineer 6 $X 6X
QA 8 $Q 8Q
--------------------------------------------------------
Contingency at 20% applied to the total, not to each line.Applying contingency per line hides it and inflates the total; applying it once, visibly, keeps the conversation honest about what the buffer is for.
Blended rates are convenient and lose information
A single blended rate is easy to quote and makes the staffing mix invisible — so a plan that quietly becomes all-junior looks identical on paper to one that is correctly staffed. Quote by role for anything where the mix affects the outcome, which is most engineering work.
Where estimates built on rate cards go wrong
- Utilisation assumed at 100%. Nobody delivers five productive days a week. Cards that ignore this produce plans that slip immediately.
- Roles missing from the plan. QA, DevOps, project management and code review are work; leaving them off the card does not remove the cost, it moves it into the overrun.
- Contingency negotiated away. It is the most visible line and the easiest to cut, which is why it disappears first and why projects then run over.
- Rates fixed for the project's duration on a multi-year engagement, so the vendor absorbs inflation or the client absorbs a mid-project renegotiation.
Internal teams need one too
Teams without external billing still benefit from a fully-loaded cost per role — salary, benefits, overhead, tooling. Without it, build-versus-buy comparisons are structurally biased: the vendor quote is a real number and the internal alternative is "we already have the team", which prices engineering time at zero.
Frequently Asked Questions
Should rate cards be public?
It depends on positioning. Published rates speed up qualification and remove low-fit conversations; withholding them allows per-client pricing. Neither is wrong, but be consistent — inconsistency is what damages trust.
How often should rates be revised?
Annually at minimum, with an explicit validity date on the card so old versions cannot be quoted back at you.
Does a rate card work for fixed-price work?
It is how you arrive at the fixed price internally. The client sees a number; you still need the role breakdown to know whether that number is survivable.
References
- The Agentic Engineering Trends Report 2026 — SaaSRise
- How to Choose Between Small and Frontier Models — Towards Data Science
About Jishu Labs
Jishu Labs is a software development company founded in 2016. We build custom software, AI/ML systems, and full-stack web and mobile applications for clients, and we make eight AI tools for software teams.