I’ve been there a lot having worked for a long time as sole developer on projects. I’ve not been in a position to need to deal with the issues in a while though, so not sure how well my suggestions would turn out in practise.

My expectation would be that the problem is less of a “what do we do”, but more in “how consistently do we do it”. Project management takes time and as developers we’re not that used to manage projects. We much rather deal with the work than trying to line up work in an orderly fashion. So imo the first step is acknowledging the fact that dealing with those things can’t happen “on the side”. It’s work that needs to happen like any other work and prevents you from doing development at the same time.

My suggestion would be starting with the smallest amount of process. Gather feedback (not act on it yet) and bring it together to a single meeting/timeslot (choose some fixed cadance and stick to it), where feedback is aggregated and sorted and at best prioritised with the client. Try to get a single person of the client to own prioritization. I like to compare this “upkeep work” to a library. Libraries only stay orderly by having a shared drop off point and then a few select people putting books back in order to a maintained system. Then everyone can continue to enjoy the orderly fashion of finding most books.

As for reading material: I really liked shape up. It’s probably too much process for your setup, but the ideas can be implemented with less process as well.

Somebody needs to be responsible for triaging / deduplicating / prioritizing this feedback, or else your effective team size is three people + everybody sending feedback.

In my experience this is the MOST DANGEROUS time in a rewrite; it’s very easy to skip the hard & unimpressive work of replacing the last bits of the old system in favor of shipping shiny new features.

But until you actually remove the old app, all you’ve accomplished is increasing the complexity of the system (by adding a second copy)!

Your team is small enough that I’d skip the lists and ask a single question: “what is the MOST IMPORTANT THING to deliver right away?”. Between replacing the last of the old system and whatever they pick, that should be more than sufficient to keep your small team busy.

Hello Linus,

I’ve been freelancing either solo or with a few people forming tiny ephemeral teams for a long time now and have been in this situation a few times.

When this has been solved for me (because being an human process problem, sometimes it does not get solved), it boiled down to these things :

• Frequent collaboration and workshops with the client, if possible, on-site : this solves the lack of implication on the client’s side by not letting time pass by. The busiest the client industry, the easier for them to let the project slip. The project must not slip.
• Designation at the client of a clear project coordinator who understands the goals, stakes and specifications, sifts through internal feedback, filters, and prioritizes it. This solves the “design by commitee” issue that can arise in some organizations.

Basically, the belief that the project is a team effort (the team being you and them) must be established and a shared culture. Asking for new features all the time is anti-team effort.

Some other companies were very good at giving me / my small team a very clear spec of what they needed, and we only needed a launch meeting, a “first delivery” meeting, a feedback phase and a final delivery meeting. But that’s the less frequent situation.

In the situation you are describing, the client forming a small, project-focused team that could make feedback loop quicker, with a single person tasked with being a source of truth, helps a lot.

Once, when a project was really slipping despite my very frequent e-mails and calls, I just took the cost of an unplanned trip and told them I’d go on-site for a week and we’d put everything back on track. Nobody asked me for that, but we were able to wrap it up.

Sometimes organizations are not able to take decisions in their own interest, even if the project itself is still of interest. Sometimes, a one-year-of-work project can happen in three months when interests and personalities align. Sometimes, unclear hierarchies and scopes can spread a one-month effort over three years of you trying to get people collaborating…

Props to you for being a small shop, it’s very interesting to read about other’s experiences.

Edit : thinking about it more, it’s all about getting to a shared truth on what the project really is. The method to get there can vary. I like workshops & short feedback cycles a lot but YMMV.