“Can we just tag people in notes?”
How a small request slowly became an architectural decision. It began with a simple sentence.
“Can we tag people inside notes… something like Jira?”
Nothing urgent.
Nothing complex on the surface.
Just one of those requests that feels small enough to disappear quietly into a sprint.
But production systems have a habit of turning simple ideas into careful decisions.⚙️
The obvious solution that refused to behave:
The first instinct was straightforward:
use an existing mention library and move on.
Well-known options like react-mentions, react-tag-input, and @draft-js-plugins/mention already provide tagging behavior.
In isolation, they work.
In demos, they look convincing.
Inside an existing production environment, though, reality felt different.
Part of the challenge was the editor itself.
It was already deeply integrated and supported:
- Rich text formatting
- Code snippets
- Image embedding
Other behaviors the product already depended on. Replacing or heavily modifying that editor would have meant disturbing far more than just tagging.
So the space for change was intentionally restricted.
At the same time:
- Some libraries conflicted with internal shared packages
- Some didn’t integrate cleanly with the current editor setup
- Others introduced subtle instability after full integration
None of these problems looked dramatic alone.
Together, they created something far more concerning:
Lack of confidence in production behavior.
And in mature systems,
uncertainty is usually more dangerous than extra effort.⚠️
The slow, quiet back-and-forth:
What followed wasn’t a heroic rewrite or a bold technical gamble.
Just careful evaluation.
Testing.
Conversations.
More testing.
Every option seemed almost acceptable.
None felt completely trustworthy.
At some point, the real question changed from:
“Which library is fastest to integrate?”
to:
“Which approach can we rely on months from now?”
That shift made the decision surprisingly calm.
We stopped trying to force stability from the outside
and decided to build only what we truly needed ourselves.
No excitement.
Just clarity. 🌿
Building less… but fitting better :
The goal was never to recreate a full mention ecosystem.
Only to support the exact collaboration the product required, nothing more.
That meant:
- Detect @ naturally while typing
- Suggest the right users instantly
- Insert clean, readable tags into the note
- Notify only the people who were actually tagged
Because user data was already available earlier in the application flow,
the fastest and calmest solution was also the simplest:
Use existing state, filter locally, avoid unnecessary API calls.
The result felt immediate and quiet
the kind of responsiveness users rarely praise
because nothing interrupts them. ✨
The part that mattered more than the UI :
The notes system already worked in production.
Which created a non-negotiable rule:
Do not disturb what is already stable.
So instead of redesigning APIs or reshaping data models:
- Tagged users became optional context, not a breaking change
- Notes continued saving exactly as before
- Notifications triggered only when tags existed
No migrations.
No risky refactors.
No architectural drama.
Just respect for a system that was already doing its job.🧩
Notifications, without unnecessary cleverness :
Once someone was tagged, the responsibility stayed simple:
Save the note
Identify the tagged users
Notify only those users
Nothing more.
Because in real production environments,
reliability usually matters more than elegance.
And working software rarely needs an announcement. 🔔
A quiet thought about scale :
Local filtering works beautifully
*as long as the current scale allows it.
*
If the system grows, the path forward is already clear:
- Debounced server search
- Indexed lookup strategies
- Pagination where necessary
Designing for today’s reality
while staying aware of tomorrow’s complexity
tends to create calmer systems than premature over-engineering. 📈
What this small feature was really about :
This was never just a tagging feature.
It was about:
- Choosing stability over convenience
- Respecting existing architecture instead of fighting it
- Solving the full collaboration problem quietly
- Making something new feel like it always belonged
Because senior engineering rarely looks dramatic.
More often,
it looks like small, careful decisions
that keep everything working
while the product moves forward almost unnoticed. 🌙
And in the end :
People can now tag someone.
The right person gets notified.
Work continues without confusion.
No one sees the trade-offs.
No one thinks about the architecture behind it.
No one notices the restraint in the decisions.
Which is usually the quietest sign
that the system is doing exactly what it should. 🤍
Top comments (0)