Every agency engagement starts with a period where nobody is building anything. They are reading your code, sitting in calls to understand the product, setting up their environment, and forming the mental model of your system that real work requires. This is necessary, and it is also billable. You are paying senior rates for people to learn what your product is. That is fine the first time. The problem is that you often pay for it more than once.
Here is the pattern that costs founders the most and shows up on no line item by name. The person who spent the first month learning your product gets rotated onto another client, a new person rotates in, and the meter starts over. The knowledge did not transfer cleanly, because it lived in one person's head, so you fund the ramp-up a second time, and sometimes a third. Nobody calls it that. It arrives disguised as normal hours.
Ramp-up is real work, and you should expect to pay for some of it
Let me be fair to the agencies first, because the answer is not to refuse to pay for onboarding. A senior engineer genuinely cannot be productive in an unfamiliar codebase on day one, and the first week or two of reading, questions, and setup is the cost of them being useful in week three. On a well-run engagement that initial ramp is a modest, one-time investment, and a good shop will even discount or absorb part of it because they know it pays back over a long relationship.
The number to hold in your head is roughly one to three weeks of reduced output at the start of a project for a competent senior joining a reasonably documented system. If a shop is quoting you a month or more of pure discovery before a single feature moves, either your system is genuinely gnarly or the discovery is padded, and you should ask which. Discovery that produces nothing you can read at the end of it is a place scope quietly inflates.
The re-learning tax nobody names
The expensive version is not the first ramp. It is the second and third, and it comes from staff rotation. Agencies staff for their own utilization, not for your continuity, so the person who learned your product is an asset they will redeploy the moment a higher-priority client needs them. When they go, their replacement pays the tuition again, on your invoice, and the total cost of learning your product quietly multiplies by the number of people who cycled through it.
This is the same underlying dynamic as the bait-and-switch, where the senior who pitched you is not the one who builds, which I covered in the senior team that pitched you isn't building your product. But the re-learning tax is subtler and shows up even with an honest agency, because rotation is baked into how they run their business. It is also worse when the team is offshore and asynchronous, where a handoff between two engineers you never meet can lose most of what the first one learned, a coordination problem I get into in managing an offshore dev team when you're not technical.
You can see the tax if you look. Watch for velocity that dips every time a new name appears in the standup. Watch for the same questions about your product getting asked again months apart. Watch for a rising share of hours logged to "onboarding," "familiarization," or "investigation" with no shipped output attached. Each of those is you paying to teach a lesson the agency already learned once on your money.
How to cap what onboarding costs you
You cannot eliminate ramp-up, but you can stop paying for it repeatedly, and most of the fix is about where knowledge lives. Make it live in your artifacts, not in the agency's heads. Insist that onboarding produces durable documentation you own, a written architecture overview, a runbook, and setup instructions, so the next person who rotates in reads instead of rediscovers. If the first engineer's learning is written down, the second one's ramp is a day, not a month.
Push for continuity in the contract, too. Name the people assigned to your account and ask for notice and a paid-by-them overlap when someone rotates off, so the outgoing engineer hands over to the incoming one rather than leaving a gap you fund. A shop that will not commit any continuity is telling you that rotation is your problem to pay for. And structure at least part of the engagement around shipped outcomes rather than pure hours, so time spent re-learning is the agency's cost to manage, not an open tab.
The instinct that matters is simple: treat the knowledge of your product as an asset you are buying, not a service you rent per person. When it is written down and owned by you, a staffing change is an inconvenience. When it lives only in the head of whoever the agency happened to assign, every staffing change is another invoice. If you suspect you are funding the same ramp for the third time and cannot prove it from the numbers, that is a worthwhile thing to untangle before you renew, and it is the kind of read a call before you renew is meant to give you.
FAQ
How much ramp-up time is reasonable to pay for?
For a competent senior joining a reasonably documented codebase, expect one to three weeks of reduced output at the start, once. A well-run shop treats that as an investment in a long relationship and sometimes absorbs part of it. Weeks of pure discovery with nothing readable to show for it is where you should start asking questions.
How do I know if I am paying to re-learn my own product?
Look for velocity dropping every time a new engineer appears, the same product questions being asked months apart, and a creeping share of hours logged to onboarding or investigation with no shipped work attached. Any of those means the cost of learning your system is being charged to you more than once.
Can I stop staff rotation entirely?
Usually not, because rotation is how agencies manage utilization. What you can do is make it cheap by forcing the knowledge into documentation you own, naming the people on your account, and requiring a paid handover overlap when someone leaves. That turns a rotation from a repeated tuition bill into a minor disruption.