Gantt/timeline app users: has slowness ever actually made you switch apps?

[黄雍蓉]

 Following on from my last thread, which was useful enough that I'm going to push my luck.

 I pulled the negative reviews (1–3 star, with text) for eight Gantt and planning apps on the Marketplace — BigGantt, WBS Gantt-Chart, BigPicture, Structure, Capacity Planner, Easy Agile Roadmaps, Swanly, Gantt Cloud. 284 reviews with actual text in them.

 Sorted by what people complain about, the largest single cluster is speed — 40 of 284. Bigger than bugs, bigger than dependencies, bigger than support.

 The whole category sits at a weighted 4.11, which is the lowest of any functional category I measured across 6,059 Marketplace apps. BigGantt 3.46 over 273 reviews, WBS Gantt-Chart 3.48 over 160, Gantt Cloud 2.96 over 85.

 The review that made me look twice:

  "Waaaaay tooooo slooooow... I only have two projects with about 20 tasks each"

 Twenty tasks isn't a data volume problem. That's a server problem — and several of these complaints do point at the vendor's backend ("their servers were responding...").

 Disclosure: I'm building in this space, so here's the question I actually need answered rather than the one that flatters me:

 1. When your Gantt or timeline app feels slow, is it slow at a size where it obviously shouldn't be? Or is it slow because you're genuinely throwing thousands of items at it?

 2. The one that matters: have you ever actually switched apps because of speed? Or is it an annoyance you complain about in a review and then keep using the thing anyway?

 3. If you did switch — what did you switch for? Speed, or something else that happened to also be faster?


 3. If you did switch — what did you switch for? Speed, or something else that happened to also be faster?

 I ask because complaining and switching are very different behaviours, and 40 reviews mentioning speed tells me about the first one, not the second. If everyone just absorbs it, that changes what's worth building.

[Jovânio Junior]

From an admin/consulting perspective, I think speed becomes a real problem when the user starts questioning the tool itself rather than the data volume.

If a timeline with 20–50 items feels sluggish, that is much harder to justify than a plan with several thousand issues, multiple dependencies, cross-project rollups, capacity calculations, etc. At larger scale, some delay is expected. At small scale, users usually read it as poor product quality.

On switching, I don’t think performance alone always causes the move. More often it becomes the final push when combined with something else: difficult configuration, weak dependency handling, poor UX, lack of reporting, or support issues.

So I’d separate it like this:

Slow but otherwise valuable: people often tolerate it.
Slow + operational friction: much higher chance of switching.
Slow at very small scale: damages confidence very quickly.

If I were building in this space, I wouldn’t treat speed only as a technical differentiator. I’d treat it as part of usability. A planner that opens quickly, reacts instantly to drag-and-drop, and doesn’t make users wait for every interaction feels significantly better even if the feature set is slightly smaller.

I’d also be very interested in measuring not just “did they mention speed?” but “what was the last problem before they churned?” I suspect speed is often a multiplier rather than the sole reason.