One of the major advantages to selling a lot of projects with repetitive elements is that code reuse plays a major role in your business. The problem is that it takes extra time and care to make those components reusable, and in an agency environment, time is almost always the enemy.

Even if you’re not up against a deadline because of some missed detail or bad guess at a time estimate, you need to have the buffer to take care of all the random gotchas in any given project. To take advantage of reusability, you need a clear plan that details how and when it’s appropriate to take extra steps to make something reusable.

If you’re always under the gun, when and how do you find the time to invest in making future projects faster through code reuse? The answer of course, is to make the time. A slightly better answer would be to teach everyone to make the time.

Your team needs to know that if something will take an extra hour to make reusable, and it’s likely to be needed on a future project, then they don’t even need to ask: Invest the time. For more complex or time-consuming situations, there’s some pretty simple pseudo-code that could figure it out:

if ( time_to_make_reusable < estimated_time_saved * n_future_projects ) {

	just_fucking_do_it();

}

Some external input on n_future_projects might be necessary, but here’s the funny thing about reusable components: If you do your job and the folks selling the sites know what you’ve got in your tool box, those components will find their way into more projects than you’d think.

Ultimately you want to have so much reusable software, and documentation accompanying it, that you need to hire someone to maintain that code because all of your other engineers are busy kicking out projects on time and under budget.

This is definitely a long-term investment, of course. You won’t see the benefits overnight, but a year down the road you’ll be thankful you took the time.