Co-development puts your developers alongside ours in the build. Here's what we've learned about scoping for quality, coordination, and change.
Not every project is ours to build alone.
Recently, we’ve seen an increase in a more collaborative model that we call “co-development” — client developers working alongside our team, owning tickets, writing code, and participating in the development lifecycle as full contributors. It sounds straightforward. In practice, it's a little more involved than that.
One real upside: we learn a lot about how client teams actually work. Over the past year, I’ve learned “why” co-development works, which is exactly what I want to talk about today.
The variable we plan for: developer quality.
When we scope for co-development, we’re scoping both for our own team's capacity and the capability of external developers we've never worked with before.
For example, during both of my most recent co-development projects, the client developers were knowledgeable, self-sufficient problem-solvers. They owned their tickets and leaned on us for guidance, context, and occasional course correction. Because of this, our team had more capacity to take on assigned work, clients handled their own QA testing for work they developed, and one project even wrapped up ahead of schedule.
Of course, it doesn't always line up that cleanly. If a client brings on developers who need more guidance than anticipated, the math can shift — meaning more coaching time and more course correction. It's a variable we plan around, since we don't know exactly who we'll be working with until we're in it.
Coordination is a full-time side job.
Co-development increases coordination. More people means more touchpoints, and those touchpoints carry a cost, such as routine coaching calls, longer code reviews, and a dedicated developer Slack channel. That's another communication layer to monitor, another queue to field questions from, and another context-switch in an already full day.
This was a learning process, even for us. For both of the co-development projects I worked on last year, we caught up to our coordination needs about three-fourths of the way through the project. The time was well spent — the work needed it, and the projects turned out well because of it — but we hadn't fully scoped for those extra hours upfront. Now we know that overhead is more than a buffer; it is a structural cost of the model.
Every project is a little different.
Here's the last thing we learned: no two co-development projects look the same. The developers are different, the systems are different, and the coordination load shifts every time.
That’s the thread running through the first two lessons above — we couldn't fully predict developer quality, and we couldn't fully predict the coordination cost. So we've started treating every co-development project as something to learn from on purpose. A short review at the end — what we scoped well, where we got caught, what we'd price differently next time — turns one project's surprises into the next one's plan.
None of this is a reason to avoid co-development. Done well, it works for everyone: clients get a seat at the table in their own build, and we get a real partner in the work. The next project will look different too, so we're planning for that difference from the start.
Coaching and Co-Development
Some teams need a development partner who builds alongside them — not one who takes over. We work with .NET teams to build CMS capability in Optimizely and Umbraco through co-development, code review, and hands-on knowledge transfer at whatever pace makes sense.
Related articles.
We’ve been writing and creating things for — and about! — the web for over 20 years, including our thoughts about .Net development. Check out more articles similar to this one.