Developer.

Excepticon: Exception Monitoring for .NET

Today I’m pleased to announce the launch of Excepticon, an exception monitoring SaaS for .NET applications and services. Excepticon is easy to configure and simple to use, and it’s geared specifically towards .NET developers.

Excepticon Landing Page

If you’re a .NET developer and you’re in the market for an exception monitoring service for your application or service, I invite you to try out either the free Developer plan or a 15-day trial on one of the paid plans. I’d love to get your feedback on how I could improve it to meet your needs.

The application is very much an MVP at this stage - it performs its core function and it does it well, but there’s more to come. I’ll be building it out, improving the UI/UX, and adding features in the coming months.

Here’s a peek at an exception in Excepticon:

Excepticon Exception Instance

So how did Excepticon come to be?

Inception

On more than one of my past side-projects over the last couple of years I’d had the thought, “When I launch this, I’m going to need an easy way to stay on top of any exceptions that my app is throwing. I should build an exception monitoring service.”

Typical developer, right?

It seemed like a fun little project that I could build in a relatively short amount of time to meet my needs. There’s some interesting aspects to it. I understood the domain. I knew what features I’d want. Maybe others would want to use it too.

Why not?

Why not.

Well, for one, there’s already other well-established, full-featured exception monitoring services out there.

Oh well.

Idea dismissed. Back to whatever I was working on before the thought entered my brain.

Time passes. Seasons change. Fast-forward several months…

The Decision to Build

Last fall, I listened to a podcast where the guest was a founder of a bootstrapped business that had launched into a market where there was existing competition. He and his cofounders were enjoying success despite incumbents in their niche because they were executing on their vision of the product, offering a different version of what was already out there, and making themselves a part of their product. He encouraged the listener to not view existing competition as a barrier to success.

I’d heard similar advice before from guests of the Indie Hackers podcast:

Your idea doesn’t have to be original. Existing competition validates that there’s a market for your product. The internet’s a big place.

The idea for what would become Excepticon resurfaced as I listened to the episode, but this time I was thinking about it in a new light.

“Maybe the market is big enough for a new service in this space. There are things about the current products that I would do differently, features that are missing. There are ways that I can differentiate myself from the competition.”

As I considered these things, I grew more excited about the project. This would be a fun thing to build. I’d build something that I’ll use, and I’d test the notion that it’s ok to build an app that solves an already solved problem.

Unlike the prior times I’d considered the idea, this time I committed to building it and got to work.

Exceptions List

Objectives

I have a few objectives for Excepticon, some of which I’ve already mentioned, and several of which I plan to elaborate on in future posts. Here they are, in no particular order:

1. Test the theory, “Your idea doesn’t have to be unique.”

Many folks wanting to build an app or start a business spend a lot of time trying to come up with a completely original idea, which is hard when you consider that many of the problems worth solving have already been solved.

However there’s quite a bit of anecdotal evidence suggesting that success can be found in executing on an idea for which there’s already a solution by building a better product, targeting a slightly different niche, or differentiating yourself somehow. Many companies that are thriving in, and in some cases even dominating, their respective industries today were not the first to market. This is true for most of the top names in tech today, including Google, Apple, and Facebook, as well as hundreds of lesser-known companies operating very successfully on a smaller scale.

Existing competition needn’t be feared. The fact that other companies exist and people are paying them money to solve the same pain point validates the idea as well as the market. There are billions of people on the internet; if your niche is large enough, you execute well, and you differentiate your product in some way, there’s usually room for another competitor.

Or, at least, so goes the prevailing wisdom.

One of my objectives for Excepticon is to test first-hand this notion that “your idea doesn’t have to be unique.”

2. Build the features that I want

There are several good exception monitoring services out there, but none of them tick all of the boxes of features that I’m looking for in a solution. Excepticon doesn’t either in its current MVP state, but it will. I’ll be prioritizing the features that matter to me as I plan out the post-MVP roadmap along with suggested features and changes that I receive from my users.

3. Build for the .NET developer, not the enterprise

Of the other exception monitoring services on the market, some of them target applications written in non-.NET languages and either don’t support .NET or .NET support is an afterthought, relying on the community to maintain a third-party Nuget package to integrate with their service.

Of the ones that do target .NET, many are part of a larger suite of enterprise tools that are marketed to C-level executives with buzzwords like “synergies,” “AI,” and “business intelligence.”

I’m building Excepticon for the .NET developer working independently or as part of a small team who needs a service to simply monitor their apps and services and to do it well.

4. Eat my own dog food

One of the best ways to understand how to improve your product is to be a user of your product. With Excepticon I’m eating my own dog food. Excepticon is using the same packages available to my end-users, and I’m monitoring for exceptions thrown by the Excepticon web app and API, which is already helping me to identify and fix pain points and things that can be improved.

Not only am I using Excepticon to monitor Excepticon, but I plan to use it on future projects as well.

5. Have fun

A side project should be something you enjoy working on. Anything that consumes as much free time as building a SaaS does should bring some personal fulfillment, especially in the early days when it’s not making any money. Further, if your heart’s not in it, you won’t stick to it and see it to completion.

I’m having fun building Excepticon. I’m excited about the features that are on the roadmap and the things that I will learn along the way.


I invite you to check out out Excepticon today!

– Jon

I’m a developer and solo SaaS founder who likes to build things and share what I learn with others. If you’re interested software development, launching things, or random early morning thoughts, consider following me on Twitter or subscribe to my newsletter.

Thanks for reading!