DEV Community: Sanja Malovic

Before you let a coding agent read your production errors: 4 checks

Sanja Malovic — Mon, 12 Oct 2026 12:18:41 +0000

This article was written with AI assistance and reviewed by the author.

MCP servers make it easy to give a coding agent access to your error tracker. That's genuinely useful: "what's the top new issue since the last release?" beats copy-pasting stack traces. But an error tracker holds data from your users and text written by strangers. Four checks before you connect one:

1. Read-only tools

Triage needs list/inspect tools only. If the server also exposes resolve, delete or settings tools, restrict the allowlist in your client config.

2. A scoped, expiring token

One project, a limited lifetime, revocable. Keep it in an environment variable or secret manager, never in the committed config file.

3. Minimized output

The agent needs messages, stacks, counts and releases. It doesn't need user IDs, emails, cookies or full URLs with query strings. Check what the tools actually return.

4. Treat error text as untrusted

Error messages, stack frames and even release labels can contain prompt injection: anyone who can trigger an error can write text your agent will read. Keep approval enabled for shell and repository write tools, and treat fetched text as evidence, not instructions.

Also remember

Whatever the agent fetches goes to the model provider you configured. Check that against your own privacy commitments before pointing it at production.

Useful prompts once it's set up: "List unresolved production issues from the last 24 hours and inspect the newest one", "Which release introduced this error?" The agent proposes; you review the fix.

Why your Hermes stack traces still say `line 1` (and the "one release per JS bundle" rule)

Sanja Malovic — Mon, 12 Oct 2026 08:52:39 +0000

TypeError: undefined is not an object (evaluating 'e.items.length')
    at anonymous (index.android.bundle:1:284133)

You uploaded source maps, yet the stack still says line 1. On Hermes/Expo it's almost always one of three things.

1. The map isn't composed

Metro maps sources → bundle. Hermes maps bundle → bytecode offsets. A Hermes map alone takes you back into generated JS. Compose them Metro first, Hermes second:

node node_modules/react-native/scripts/compose-source-maps.js \
  index.android.bundle.packager.map index.android.bundle.hbc.map \
  -o index.android.bundle.map

Android Gradle Hermes builds usually do this for you (keep the final map from the release variant, not .packager.map/.hbc.map). On iOS, set SOURCEMAP_FILE before react-native-xcode.sh runs. In EAS, do that through a config plugin, because a post-build hook is too late. For EAS Update, use npx expo export --source-maps and keep the maps from that exact export.

2. The release identifies the app, not the bundle

release: "1.0.0" breaks the moment you ship an OTA update. The native version is the same, but the JS and the map are different. Use one release per JS bundle: native version plus an embedded build ID, or the platform Updates.updateId (not the update-group ID). Never reuse a release when the JS changes. Keep Android and iOS separate in your tracker, because the same release has a different bundle on each.

3. The bundle URL doesn't match

Embedded bundles are index.android.bundle and main.jsbundle. OTA bundles may have hashed internal paths. Read the actual sourceURL from a real release stack and upload the map under that name. Don't assume it's your export filename.

Checklist

[ ] Composed map (Metro → Hermes)
[ ] Release per JS bundle, separate per platform
[ ] Bundle URL checked against a real stack
[ ] Map uploaded from the exact build/export you shipped (e.g. from the eas-build-on-success npm hook)

Native crashes need native symbol files and are a different problem. Everything here is about JS errors.

This article was written with the help of AI and reviewed by the author.

Building Telemetry Tracker: An Open-Source Alternative to Sentry and PostHog

Sanja Malovic — Sat, 18 Jul 2026 17:44:35 +0000

For the past few months, I've been spending most of my free time building Telemetry Tracker.

It started with a simple question:

Every project I worked on ended up using multiple tools. One for errors. One for analytics. One for releases. One for alerts. Another one for monitoring.

After a while, I realized I was spending more time jumping between dashboards than actually understanding what was happening inside my applications.

So I started building Telemetry Tracker.

I wanted:

error tracking,
event analytics,
session monitoring,
release tracking,
alerting,
and organizations and projects management, all in one place.

So I started building it.

What is Telemetry Tracker?

Telemetry Tracker is an open-source observability platform for modern applications.

It currently supports:

Web applications
React Native applications
Backend services
Self-hosted deployments

Current features include:

Error tracking
Event analytics
Session monitoring
Release tracking
Alert rules
Organization & project management
Usage analytics
REST APIs
SDKs for multiple platforms

Why Open Source?

Open source wasn't an afterthought. It was one of the goals from day one.

I wanted developers to be able to:

self-host everything,
inspect the source code,
contribute new features,
and have an alternative that doesn't require stitching together multiple services.

What’s Next?

Telemetry Tracker is still in its early days. There is a lot left to build, but that's also what makes building it exciting.

Some of the upcoming features include:

Notifications
Release Health dashboards
Search capabilities
Performance monitoring
Compare periods
AI-powered release intelligence
Custom PII scrubbing rules
Export capabilities

Building in Public

Building an open-source project has been both exciting and frustrating. Some days are spent shipping features, while others are spent writing documentation, reviewing pull requests, or figuring out where to share the project with the community.

I didn't start this project because I wanted to build another startup.

I started it because I genuinely enjoy building developer tools.

Telemetry Tracker began as a side project that solved my own problems and slowly became something much bigger than I originally planned.

It's also the telemetry platform I use in my own projects, which means I get to experience both sides of building it: as its maintainer and as one of its users.

Seeing other people open pull requests, submit issues and use it in their own projects has probably been the most rewarding part of building it so far.

It's still early, but I'm excited to keep building.

If you're interested in open-source developer tools, observability or self-hosting projects, I'd love to hear your thoughts.

Whether it's feature ideas, feedback or contributions, every comment helps shape where Telemetry Tracker goes next.

GitHub:
https://github.com/Telemetry-Tracker/telemetry-tracker

Website:
https://telemetry-tracker.com

Building Telemetry Tracker

Sanja Malovic — Sun, 12 Jul 2026 01:20:32 +0000

A few months ago, I started building something I thought only I would use.

A few months ago, I started building Telemetry Tracker.

Honestly, it wasn't supposed to become a product.

I wanted a place where I could experiment with telemetry, SDKs, dashboards, and backend architecture. I was also getting tired of setting up different analytics and monitoring tools for every side project.

So I thought... why not build my own?

At first, it was just for me.

Then I started using it in more and more projects.

Eventually, I realized it had become something worth open-sourcing.

Why another telemetry platform?

I get this question quite a bit.

There are already great products like Sentry, PostHog, Datadog, and plenty of others.

I'm not trying to replace them.

Telemetry Tracker exists because I wanted something that fits the way I like building software.

Open source
Self-hostable
Easy to integrate
Built with TypeScript from top to bottom

Most importantly, I wanted something I'd actually enjoy maintaining.

What it does today

Today, Telemetry Tracker supports:

Error tracking
Product analytics
Custom events
Sessions
Source maps

There are official SDKs for:

React
Next.js
Vue
Nuxt
React Native
Node.js
NestJS

There's still a long roadmap ahead, but it's already running in several of my own projects every day.

The biggest surprise

I thought building the software would take most of my time.

It didn't.

Writing the code is actually the fun part.

The part I underestimated was everything around it.

Writing documentation.

Reviewing pull requests.

Keeping GitHub organized.

Writing release notes.

Building the website.

Answering questions.

I probably spend almost as much time outside my editor as I do inside it now.

Maintaining an open-source project is a completely different skill from building one.

I'm still learning that every day.

Open source has been the best part

One of my favorite moments was getting the first pull request from someone I'd never spoken to before.

Then another.

Someone translated the README into German.

Someone else improved the GitHub Action for source map uploads.

Those are small contributions, but they make the project feel alive.

That's something I never really experienced with private side projects.

What's next?

There's still plenty I want to build.

Performance Monitoring is the next big milestone.

After that, I want to add alerts, session replay, and continue improving the developer experience.

I'm sure a lot will change along the way.

That's part of the fun.

If you'd like to check it out, I'd genuinely love to hear what you think.

Whether it's feedback, criticism, or feature ideas—I'm all ears.

⭐ GitHub: https://github.com/Telemetry-Tracker/telemetry-tracker

🌐 Website: https://telemetry-tracker.com

Thanks for reading! 👋

I Built an AI-Powered Art Digest That Writes and Illustrates Itself

Sanja Malovic — Tue, 06 May 2025 11:26:36 +0000

I Built an AI-Powered Art Digest That Writes and Illustrates Itself

What happens when you combine real-time news, generative AI, and modern art?

You get Unjica — a living, breathing editorial that curates and reimagines contemporary art stories using OpenAI and custom code.

💡 Why I Built It

As a developer and art enthusiast, I wanted to create something that:

Keeps up with the fast-moving world of art and exhibitions,
Feels editorial (not robotic),
Looks beautiful, like a curated magazine,
And updates itself — daily.

🛠️ How It Works

Next.js + App Router: for structure and speed
Prisma + PostgreSQL: to store and filter news
OpenAI (GPT-4o & DALL·E 3): to generate articles and header images
R2 Storage: to persist DALL·E outputs
Scheduled CRON jobs on Vercel: for daily automation
Markdown content: clean, simple, structured

✨ What Makes It Interesting

Articles sound like real human writers — critical, witty, even poetic.
Visuals are generated with painterly prompts (no generic AI mush).
It's self-sustaining — I just keep refining it.

Here's a recent post to give you a taste.

🧪 Challenges

Tuning prompts to avoid generic AI tone
Balancing automation with taste
Making SEO work with dynamic Open Graph images

🚀 What’s Next?

Integrating artist interviews
Letting users vote on which stories should be featured
Adding human + AI collaboration tools

Would love your thoughts — or any feedback on how to make it more useful for creators or art lovers.

Thanks for reading 🙏

🚀 Live Chat Support Starter Kit — Open Source!

Sanja Malovic — Mon, 28 Apr 2025 08:38:28 +0000

🚀 Live Chat Support Starter Kit — Open Source!

Hey everyone! 👋

I’m excited to share something I’ve been building:

a full live chat support starter kit — built with Next.js App Router, Socket.IO, Zustand, and TailwindCSS!

✨ What It Does

🔴 Real-time messaging between visitor and admin
👩‍💻 Separate admin and visitor UIs
💾 Persistence with sessionStorage/localStorage
🔚 Admin can end conversations, visitor can resume later
⚡ Deploy-ready: Vercel (frontend) + Railway (backend)

✅ Lightweight, fast, customizable — and open-source!

📸 Demo

🛠️ Tech Stack

Frontend: Next.js (App Router), Zustand, TailwindCSS
Backend: Express.js + Socket.IO
Persistence: LocalStorage + SessionStorage
Deployment: Vercel + Railway

📁 Project Repo

🔗 GitHub – unjica/live-chat-support-demo

🎯 Why I Built It

I wanted to create a clean starter kit for developers that shows:

Real-time Socket.IO communication
Simple yet structured backend architecture
Lightweight state management with Zustand
Developer-first deployability (no database needed to start)

🔥 Future Plans

Database persistence (MongoDB or PostgreSQL)
Authentication for Admin panel (NextAuth.js)
Multi-agent support (for multiple admins)
Typing indicators with avatars

🧠 How AI Helped

I used AI tools like Cursor and ChatGPT to:

Structure the modular backend faster
Improve Socket.IO error handling
Draft early versions of the README and documentation

🙌 Feedback Welcome

If you:

Have ideas 💡
Want to contribute 🔥
Find it useful 🌟

Feel free to open an issue, PR, or leave a comment!

Would love to hear your thoughts.

Thanks for reading! 🚀

📋 Tags


plaintext
#opensource #nextjs #socketio #webdev