The client wanted real-time collaborative editing in their project management tool. Think Google Docs, but for project briefs. Multiple users editing the same document simultaneously, with cursors, conflict resolution, and live presence indicators.
We said no. Not because it's impossible — but because it was wrong for their MVP.
The request
The product was a project management tool for small creative agencies (5–15 people). Core features: task boards, time tracking, client portals, and document storage. The client had a clear vision and a €14K budget.
During the scoping phase, we mapped 4 weeks of development across these core features. Then the client asked: "What about real-time editing? My team currently uses Google Docs for briefs, but I want it built into the app."
Why we pushed back
The math didn't work
Real-time collaborative editing (CRDTs or operational transforms) is a 3–6 week feature, depending on the editor complexity. For our €14K budget, that was 25–40% of the entire project — for one feature that zero users had asked for yet.
The core features (task boards, time tracking, client portals) would serve all users from day one. Real-time editing would serve a subset, some of the time, for one specific workflow.
The existing solution was fine
The team was already using Google Docs. It's free, reliable, battle-tested for collaboration. Replacing it with a worse version inside the app would have been a downgrade on day one.
What the team actually needed wasn't real-time editing — it was a link between the document and the project. "This brief belongs to this project, and here's the link to the Google Doc."
The complexity was hidden
Real-time editing sounds like one feature. In practice, it's:
- Conflict resolution (two users edit the same paragraph)
- Presence indicators (who's online, where their cursor is)
- Version history (undo someone else's change)
- Permissions (can the client edit, or only view?)
- Offline handling (what happens when someone edits without connection?)
- Performance (large documents with many concurrent editors)
Each of these is a week of work. And each introduces edge cases that require ongoing maintenance — not just a build-and-forget feature.
What we built instead
A document section in each project with:
- File upload (drag and drop, up to 50MB)
- Google Docs/Notion/Figma link embedding
- Simple rich-text notes (not collaborative — single-author per note)
- @mentions that notify team members
Development time: 1 week (vs. 3–6 weeks for real-time editing).
What it solved: The team could link their existing Google Docs to projects, upload files, and leave notes — all within the project context. The "I can't find the brief for project X" problem was solved without rebuilding Google Docs.
Six months later
The client launched. 40 agency accounts signed up in the first 3 months. During a check-in call at month 6, I asked about the real-time editing feature.
Their response: "We never heard a single user ask for it. Everyone already uses Google Docs or Notion. What they wanted was better task-to-document linking — and we have that."
They added: "If we had spent 4 weeks on real-time editing, we wouldn't have had time for the client portal — which is the feature most agencies cited as the reason they signed up."
The decision framework
When a client asks for a complex feature in an MVP, I run through three questions:
1. Does the user currently solve this problem?
If yes — and they're solving it adequately with an existing tool — you don't need to replace that tool. You need to integrate with it. A Google Docs link inside your app is 100× cheaper than rebuilding Google Docs.
2. What's the opportunity cost?
Every week spent on feature X is a week not spent on feature Y. For an MVP with a fixed budget, this is zero-sum. The question isn't "is this feature valuable?" — it's "is this feature more valuable than what we'd build instead?"
3. Will this be the reason someone signs up?
Most features fall into two categories: must-haves (without it, the product doesn't work) and delighters (nice to have, improves experience). Real-time editing was neither — it was a replacement for something that already worked.
The client portal — the feature we built with the time we saved — was a must-have. Agencies needed to share deliverables with clients. Without it, the product was just "another internal project tool."
The uncomfortable truth
Saying no to a client's feature request feels risky. They're paying you. They have a vision. Pushing back seems confrontational.
But a developer who says yes to everything is a developer who ships late, over budget, or with half-finished features. I've seen the pattern in rescue projects — the original developer said yes to everything, delivered 60% of a bloated scope, and the founder had to start over.
The client thanked us because we did the math out loud: "Here's what this feature costs in weeks and euros. Here's what we'd cut to fit it. Here's what your users will actually need on day one. Your call — but our recommendation is no."
Transparency gives the client the information to make a good decision. Agreeing silently doesn't.
Building an MVP and not sure which features to include? Let's talk — I help scope MVPs so you ship the right thing in 12 weeks, not everything in 20.