DEV Community: Georgi Hristov

Helping Others Is One of the Best Parts of Open Source

Georgi Hristov — Thu, 25 Jun 2026 05:48:05 +0000

“Sometimes a small contribution creates value for everyone involved.”

Recently, @SaurabhSin15850 made his first open source contribution by fixing a bug in DebugProbe.AspNetCore.

Seeing someone make their first contribution is always something I appreciate.

For him, it was an opportunity to contribute to an open source project and get his first PR merged.

For me, it was a bug fixed, time saved, and another improvement to the project.

That's one of the things I like most about open source.

A contribution doesn't have to be huge to make an impact.

Sometimes it's a small bug fix.

Sometimes it's documentation.

Sometimes it's simply taking the time to improve something that someone else is building.

Everyone benefits.

The contributor gains experience and confidence.

The maintainer gets help moving the project forward.

And the project itself becomes better because of it.

I think that's what makes open source communities so valuable.

People with different backgrounds and experience levels helping each other build something better.

Final Thought

Thank you, @SaurabhSin15850, for your contribution and for sharing your experience afterward.

Congratulations on your first merged PR!

If you'd like to support him, here's his post:

https://x.com/SaurabhSin15850/status/2070009743654215771?s=20

https://x.com/SaurabhSin15850

A Small Spoiler About What's Coming Next

Georgi Hristov — Tue, 23 Jun 2026 04:07:45 +0000

Over the last few months, I've been building DebugProbe around one core idea:

Making it easier to understand why an API behaves differently across environments.

That idea eventually became the feature most people associate with the project:

Request comparison across environments.

And no, that feature isn't going anywhere.

In fact, it will remain at the center of what comes next.

I'm currently working on DebugProbe Server.

The goal is to provide centralized request and exception monitoring across multiple applications and environments.

Instead of checking several applications separately, everything will be available in a single place.

The focus is simple:

request monitoring
exception monitoring
multiple applications
multiple environments
request comparison

As systems grow, debugging becomes more difficult.

More services.
More environments.
More things that can behave differently.

I think having a single place to investigate and compare behavior can make a big difference.

Final Thought

Every new feature should strengthen the original vision, not replace it.

For DebugProbe, that vision is still simple:

Understand. Compare. Debug.

Build once. Compare everywhere.

Would You Pay for a SaaS Review?

Georgi Hristov — Thu, 18 Jun 2026 20:12:33 +0000

I've been thinking about a simple service for SaaS founders.

The idea is straightforward: submit your SaaS project and receive an independent review covering multiple areas of the product.

What Could Be Reviewed?

Landing page and first impression
Value proposition clarity
User experience (UX)
User interface (UI)
Onboarding flow
Documentation
Pricing page
Performance
Trust and credibility signals
Developer experience (for technical products)

What Would You Receive?

A detailed written review with actionable feedback and suggestions for improvement.

The review would then be:

Published on the website
Shared across social media channels
Available for others to discover and learn from

Why?

As builders, we're often too close to our own products.

A fresh perspective can help uncover usability issues, confusing messaging, onboarding friction, or opportunities that are easy to miss when you're building every day.

At the same time, a public review can provide additional exposure for the project.

Looking for Feedback

I'm currently validating this idea.

Would you pay a small amount for a detailed SaaS review?

If yes, what would you expect to see included?

If not, what would stop you from using a service like this?

I'd love to hear your thoughts.

The First 50 Subscribers Are Harder Than I Expected

Georgi Hristov — Tue, 16 Jun 2026 07:42:12 +0000

A few days ago I wrote about setting goals for projects.

One of the goals I shared was simple:

50 email subscribers in 30 days.

At the time, the project had 7 subscribers.

Today the number is:

14 / 50

Still far from the goal.

But it also means the number doubled.

And honestly, this experience is teaching me something interesting.

Getting people to visit a website is difficult.

Getting people to try a project is even more difficult.

Getting people to voluntarily subscribe and ask to hear from you again is probably the hardest part.

That's why every new subscription feels meaningful.

The number itself is small.

Fourteen subscribers is not something that will impress anyone.

But behind that number are fourteen people who decided the project was interesting enough to follow.

And for a small open source project, I think that matters.

Building software is one challenge.

Building an audience around it is a completely different challenge.

It's also making me appreciate how difficult it is to grow a project consistently over time.

The growth is rarely dramatic.

Most of the time it happens one person at a time.

So to everyone who subscribed:

Thank you.

I genuinely appreciate the support.

And if you're building your own project, I'd be interested to know:

Do you track goals like this, or do you prefer to focus only on building?

Current Goal

14 / 50 subscribers

Final Thought

Small numbers can still represent meaningful progress.

Sometimes it's easy to focus on how far away a goal is.

But it's also important to remember how far you've already come.

Useful Links

If you'd like to follow the project:

Subscribe for updates: https://debugprobe.dev
Documentation: https://debugprobe.dev/docs
GitHub Repository: https://github.com/DebugProbe/DebugProbe.AspNetCore

Documentation Structure Matters More Than You Think

Georgi Hristov — Sat, 13 Jun 2026 06:20:54 +0000

“Good documentation is not only about what you write. It's also about how people find it.”

Recently I spent some time reorganizing the DebugProbe documentation.

The goal wasn't to add more content.

The goal was to make existing content easier to find and navigate.

As the project grew, the documentation naturally grew as well.

New features appeared.
New configuration options were added.
More examples became necessary.

Over time, I started asking myself a simple question:

If I were a new user, would I immediately know where to find what I need?

That question led me to completely rethink the documentation structure.

Instead of organizing information as features were added, I reorganized everything into five main sections:

Getting Started
User Guide
Technical Guide
Examples
Reference

The idea is simple.

A new user should be able to install the package and get started within minutes.

Someone trying to configure security should know exactly where to look.

And users searching for a specific option should not have to read through multiple unrelated pages first.

My goal:

Help users spend less time searching and more time building.

One thing I also realized is that documentation rarely exists in a single place.

For DebugProbe, I currently maintain:

the GitHub README
the NuGet package README
the project website documentation

Keeping all of those sources organized and consistent takes effort.

That's one of the reasons I wanted a cleaner documentation structure.

The easier information is to find, the easier it becomes to maintain over time.

I think many projects slowly accumulate documentation over months or years without ever stepping back and asking whether the structure still makes sense.

Sometimes the content is already there.

It just needs better organization.

Final Thought

Documentation is often viewed as something you write after building a feature.

But structure and navigation are just as important as the content itself.

If users cannot find the information they need, even great documentation becomes less useful.

How do you organize documentation for your projects?

Documentation:

https://debugprobe.dev/docs

Does Every Product Need One Killer Feature?

Georgi Hristov — Wed, 10 Jun 2026 04:14:13 +0000

“If you cannot explain why someone should choose your product in one sentence, you probably haven't found your killer feature yet.”

Lately I've been thinking about what makes some products stand out while others become just another option in a crowded market.

Many tools have:

good documentation
useful features
polished UI
active development

But so do their competitors.

So what makes someone choose one product over another?

I think every project needs a killer feature.

Something that immediately answers the question:

“Why should I use this instead?”

For DebugProbe, I think that feature is the ability to compare API behavior across environments.

When an API works locally but behaves differently in staging or production, finding the exact difference can take hours.

Being able to compare requests, responses, headers, status codes, and payloads side by side is the feature I want people to immediately associate with the project.

Not because it has the most features.

But because it solves one specific problem really well.

That's also influencing how I think about future development.

For example, one feature I plan to explore is certificate monitoring.

The idea is simple:

Knowing before an SSL certificate expires can save a lot of unexpected downtime and troubleshooting.

The challenge is making sure new features support the core vision instead of distracting from it.

Because every new feature adds:

complexity
maintenance
documentation
support

And not every feature makes a product better.

Sometimes it simply makes it bigger.

Final Thought

The challenge is making sure new features strengthen the product instead of diluting its identity.

What do you think is the killer feature of your project?

And does every successful product need one?

How Do You Set Goals for Your Projects?

Georgi Hristov — Tue, 09 Jun 2026 04:24:29 +0000

“A goal gives direction. Without one, it's difficult to know whether you're actually making progress.”

Lately I've been thinking a lot about goals.

Not only for open source projects, but for almost everything.

And one thing I'm still trying to understand is:

What is the right way to set goals?

Should goals be:

big and ambitious
small and achievable
short-term
long-term

Or does it simply depend on the person?

I don't think there is a universal answer.

Some people are motivated by large goals that take years to achieve.

Others prefer breaking everything into smaller milestones and focusing on one step at a time.

Personally, I like setting goals for almost everything.

They help me stay focused and give me something measurable to work toward.

One of my current goals is related to the email subscription feature that became available a few days ago for DebugProbe.

The goal is simple:

50 email subscribers in 30 days.

Right now the project is at:

7 subscribers / 50

It's not a huge number, but every subscription tells me that someone is interested enough to follow the project's progress.

And I genuinely appreciate that.

So thank you to everyone who has already subscribed.

If you're interested in following the project, you can subscribe for free at:

debugprobe.dev

Final Thought

I think goals are important.

Maybe not because of the number itself, but because they give us a way to measure progress and stay focused over time.

I'm curious how other developers approach this.

Do you prefer one big goal or many smaller goals?

The Architecture Behind the Future of an Open-Source Project

Georgi Hristov — Sun, 07 Jun 2026 10:06:17 +0000

DebugProbe Architecture Overview

The diagram illustrates the vision behind DebugProbe Server and how it enables centralized monitoring across multiple environments and applications.

Current State

Today, DebugProbe.AspNetCore runs directly inside ASP.NET Core applications and provides a lightweight dashboard for inspecting:

Requests
Responses
Exceptions
Headers
Query parameters
Request and response bodies
Performance information

This works well for individual applications, but as systems grow, teams often need a centralized view across multiple environments.

Introducing DebugProbe Server

DebugProbe Server acts as a central collection hub for all connected DebugProbe instances.

Instead of opening separate dashboards for Development, Staging, and Production, applications can send their captured data to a single DebugProbe Server instance.

The server becomes the central place where teams can:

Monitor all environments
Review requests and exceptions
Compare behavior between environments
Troubleshoot issues faster
Manage multiple applications from one dashboard

Architecture Flow

                    debugprobe.server
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
   Development         Staging           Production
        │                  │                  │
   Client app         Client app         Client app  
        +                  +                  +
   debugprobe         debugprobe         debugprobe
  .aspnetcore        .aspnetcore        .aspnetcore

Each environment runs DebugProbe.AspNetCore locally and forwards diagnostic data to DebugProbe Server.

The server aggregates and displays all collected information through a unified dashboard.

Scaling Beyond One Application

The same architecture can support multiple applications.

                    debugprobe.server
                           │
        ┌──────────────────┴──────────────────┐
        │                                     │
      App 1                                App 2
  Dev / Stage / Prod                  Dev / Stage / Prod

This allows organizations to manage diagnostics for an entire portfolio of applications from a single platform.

Current Status

DebugProbe.AspNetCore

🟢 Available now and ready for production use.

Current Version: v1.6.2

Useful Links:

Website: https://debugprobe.dev
LiveDemo: https://demo.debugprobe.dev/debug
Documentation: https://debugprobe.dev/docs
GitHub: https://github.com/DebugProbe/DebugProbe
NuGet: https://www.nuget.org/packages/DebugProbe.AspNetCore

DebugProbe.Server

🚧 Currently under active development.

The first alpha release will focus on:

Centralized request collection
Exception monitoring
Environment management
Cross-environment comparison
Multi-application support

If you're interested in early access, you can subscribe via email on the DebugProbe website and get notified when alpha testing becomes available.

Goal

The goal is simple:

Keep DebugProbe.AspNetCore lightweight, simple, and easy to integrate while providing an optional server platform for teams that need centralized observability, environment comparison, and advanced diagnostics.

Email Subscription Update for DebugProbe

Georgi Hristov — Fri, 05 Jun 2026 08:14:17 +0000

A few hours ago I wrote about whether open source projects should start collecting emails early.

While working on the project today, I finished the first version of the email subscription feature.

The email subscription is now live on the DebugProbe website.

The goal is simple:

no marketing emails
no spam
no unnecessary notifications

Only important updates about:

new releases
major features
significant project updates

I'm still experimenting and learning, but I think having a direct way to reach people who are interested in the project is valuable.

If you're interested in following DebugProbe, you can now subscribe here:

Subscribe with DebugProbe

And if you read the original post, I'd still love to hear your thoughts on when projects should start building an email list.

The discussion is definitely still open.

Should Open Source Projects Start Collecting Emails Early?

Georgi Hristov — Fri, 05 Jun 2026 04:29:56 +0000

“A GitHub star is great. An email subscriber is someone you can reach directly.”

Lately I've been thinking about email lists and whether open source projects should start building one much earlier.

GitHub stars, downloads, website traffic, and social media followers are all useful metrics, but none of them give you a direct way to reach people who are interested in your project.

That's where email becomes interesting.

If someone voluntarily gives you their email address, they are usually interested enough to hear about:

new releases
important updates
major features
roadmap changes

And that feels much more valuable than a random website visit.

One question I'm currently asking myself is:

At what stage should a project start collecting emails?

Should it happen:

immediately after launch
after finding product-market fit
after reaching a certain number of users

I'm not sure there is a single correct answer.

For my own project, DebugProbe, I plan to collect emails through the project website.

The idea is simple.

Users can subscribe and receive updates only when something important happens around the project.

No marketing emails.
No spam.
Only meaningful updates.

Interestingly, I accidentally discovered another way to collect emails.

I published the project on Gumroad as a free product.

The project itself costs nothing, but Gumroad gives me one useful thing:

Information that someone was interested enough to download it.

That creates another channel for understanding who is actually engaging with the project.

And it made me wonder whether relying on a single source for collecting emails is enough.

Maybe projects should have multiple entry points:

website subscriptions
free downloads
newsletters
community signups

while still keeping everything simple and respectful.

Because at the end of the day, email feels different.

Algorithms change.
Social media platforms change.

But an email list remains a direct connection between a project and its audience.

Final Thought

I'm still very early in this journey, so I'd love to hear from developers who have already gone through it.

Do you think collecting emails is important for open source projects?

And if so, when is the right time to start?

At the moment, the only way to join the DebugProbe email list is through the free Gumroad page.

Support Beyond Code — I Didn't Expect This Kind of Support

Georgi Hristov — Tue, 02 Jun 2026 04:48:20 +0000

It took me some time to write this post, but now it says exactly what I wanted to say.

When people talk about open source contributions, we usually think about code.

You organize your repository, improve the documentation, create issues, and over time you hope someone will contribute.

But this wasn't what I expected.

One person helped my project without writing a single line of code.

We met here on DEV, and later continued our discussions on Discord.

He shared useful resources, gave organizational advice, introduced me to Conventional Commits, and helped me think more seriously about the long-term direction of the project.

The most surprising part is that this happened at a very early stage.

When your project is new, you're still trying to validate the idea itself and understand whether you're building something people actually find useful.

Then he spent hours reviewing the project and wrote a roadmap that aligned almost perfectly with what I wanted the project to become.

What's funny is that we hadn't even discussed many of the future ideas yet.

That roadmap is still one of the most valuable contributions the project has received so far.

Because of that, I decided to invite him as a member of the DebugProbe GitHub organization.

@gimi5555, thank you for allowing me to mention you here.

Thank you for the time, the advice, the honest feedback, and for becoming part of the DebugProbe journey so early.

Even with a 7-hour time difference and living on different continents, we connected through the same thing:

Building software.

And that's one of the things I like most about open source.

Thank you, man 🙏

The roadmap is 🔥

Roadmap

Discord: georgidhristov

Final Words

Open source contributions are not only about code.

Sometimes advice, feedback, organization, documentation, and simply helping someone stay on the right path can have an even bigger impact.

And those contributions deserve recognition too.

DebugProbe.AspNetCore — From a Debugging Experiment to an API Comparison Tool

Georgi Hristov — Sat, 30 May 2026 22:16:42 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

DebugProbe.AspNetCore is an ASP.NET Core debugging and API comparison tool designed to help developers understand exactly how their applications behave across different environments.

It captures incoming requests, outgoing HTTP calls, headers, bodies, timings, exceptions, and middleware execution details through a lightweight web interface.

What makes the project different is its focus on API comparison.

Instead of manually inspecting logs from multiple environments, developers can compare requests side-by-side and quickly identify differences in responses, headers, payloads, status codes, and behavior.

The goal is simple:

Reduce the time required to answer one of the most common debugging questions:

"Why does this work in one environment but not in another?"

The project started as a personal tool because I was tired of manually comparing logs, requests, and responses when debugging production issues. Over time it evolved into a reusable open-source solution for ASP.NET Core developers.

Demo

Live Demo

https://demo.debugprobe.dev/debug

Demo API

https://demo.debugprobe.dev/swagger

Screenshots

Review Captured HTTP Traffic

Inspect Complete Request & Response Details

Compare API Behavior Across Environments

The Comeback Story

DebugProbe.AspNetCore started as a simple debugging experiment.

My original goal was straightforward: create a lightweight way to inspect requests and responses inside ASP.NET Core applications without relying on external tools.

The first versions worked, but over time I realized something important.

The debugging information itself was useful, but the most valuable part was comparing behavior.

Many production issues are not caused by obvious exceptions. They happen because an API behaves slightly differently between local development, staging, and production.

Different headers
Different payloads
Different status codes
Different downstream service responses

Developers often spend hours comparing logs manually to find these differences.

That realization changed the direction of the project.

Instead of building another request inspector, I started focusing on comparison workflows.

Over time the project evolved with:

Request and response inspection
API comparison capabilities
Outbound HttpClient tracing
Improved filtering and navigation
Better UI and usability
Documentation and examples
Live demo environment
Organized GitHub workflows
Continuous improvements based on community feedback

What began as a small debugging utility gradually became a more complete developer tool focused on understanding application behavior.

Today, DebugProbe.AspNetCore is a stable open-source project at version 1.6.0, with documentation, a live demo, regular releases, and a growing roadmap.

My Experience with GitHub Copilot

I primarily built DebugProbe.AspNetCore myself, while GitHub helped me organize the project through issues, pull requests, releases, discussions, and overall project management.

One lesson I learned while working on this project is that building the software is only part of the job.

Maintaining documentation, organizing issues, planning future work, tracking releases, and communicating project direction are all important parts of turning a repository into a real open-source project.

GitHub became the place where the project evolved from a collection of features into something more structured and maintainable.

This challenge gave me a chance to step back and look at how far the project has come.

The project is still evolving, but today it solves real problems for real ASP.NET Core developers.

And this is only the beginning.