DEV Community: Niclas

Designing respectful notifications in a social platform.

Niclas — Tue, 03 Mar 2026 15:36:33 +0000

Most social platforms treat notifications as engagement drivers. The more you return, the better it is for the system. Notifications become a lever to pull people back in, often regardless of whether they have shown recent activity.

Questioning that assumption while building a small social platform. If a user has not interacted with the app in days or weeks, does it really make sense to keep sending notifications? At some point, reminders stop being helpful and start feeling like spam.

The idea I settled on was simple: notifications should respond to user activity, not just system events.

Instead of sending a notification for every qualifying action, the system allows only one notification per user activity window. If the user has already received a notification but has not returned to the platform, additional notifications are suppressed. In other words, inactivity acts as a natural brake.

Technically, this is implemented using Redis as a persistent cache layer. When a notification is sent, a suppression key is written with a configurable expiration time. As long as that key exists, further notifications of that type are not delivered. If the user returns and interacts with the platform, the key can be cleared or reset. If they remain inactive, the suppression window eventually expires on its own.

The expiration time is configurable per notification type. Some events are more time-sensitive than others, and the system allows different reset periods. In my current setup, the default window is seven days, but this can be adjusted without changing the core logic.

This approach does introduce tradeoffs. A user who cares but checks the platform infrequently might miss intermediate updates. However, the design assumption is that meaningful engagement should restart when the user actively returns. Notifications are not meant to accumulate in the background; they are meant to signal something new once the user has shown interest again.

The broader goal is to make notifications feel respectful. Instead of optimizing for frequency or return rate, the system optimizes for restraint. If someone is inactive, the platform should not keep tapping them on the shoulder.

Designing notifications this way shifts the focus slightly. It moves away from maximizing engagement and toward minimizing unnecessary interruption. It is a small change technically, but it significantly changes the tone of the product.

I am still refining the definition of “inactive” and exploring edge cases where suppression might hide something important. But the core principle remains the same: activity should trigger notifications, not the absence of it.

How important is Web Accessibility?

Niclas — Sun, 15 Feb 2026 01:06:13 +0000

Since I learned web programming I always thought just like security is somethings we should never skip I also think of web accessibility in the same regards for public sites but I also try to always implement it on internal tools as well.

I am using this great tool from WAVE Web Accessibility Evaluation Tools (https://wave.webaim.org/), does anyone else use it? I wonder if there are any alternatives that is better.

IndexNow: Struggle with implementation (C#)

Niclas — Thu, 12 Feb 2026 16:12:37 +0000

Some days ago I have been struggling with implementing IndexNow, I did almost exactly as mentioned here in this tutorial https://www.bing.com/indexnow/getstarted#implementation, but it did not work.

The payload was correct and the data and the endpoint was right but I got bad request, I had no clue what to fix.

The error:

{\"code\":\"InvalidRequestParameters\",\"message\":\"Given request parameters are null or invalid\"}

After finding https://stackoverflow.com/questions/72629964/given-request-parameters-are-null-or-invalid-when-using-curl-to-submit-urls-wi on stackoverflow I changed endpoint to "https://www.bing.com/IndexNow" I finally found the cause.

IndexNow submission failed with status LengthRequired.

The whole issue has been the http version all along which I never thought of as I have never had any reasons before to set that manually.

The solution to fix the issue:

            var request = new HttpRequestMessage(HttpMethod.Post, endpoint)
            {
                Version = HttpVersion.Version11,
                VersionPolicy = HttpVersionPolicy.RequestVersionExact,
                Content = new StringContent(
                    JsonSerializer.Serialize(payload, JsonSerializerOptions.Web),
                    Encoding.UTF8,
                    "application/json")
            };

I hope it help someone who may struggle with the same issue.
A small note, the correct endpoint is https://api.indexnow.org/indexnow.

Remember what you vibe?

Niclas — Tue, 03 Feb 2026 07:43:00 +0000

Hello,

I recently started vibe coding and yes the output is fast but I feel personally the long term memory for knowing your project is declining.

When I did commit and pullrequests I read the code and understand what it did and if it required any changes, but in long term I needed to go back again to remember the details.

Writing my code myself it was much easier to remember the details. So how did I solve it?

What I did, first make sure the agent follow the SOLID principle and KISS as much as possible, iterate over the code and extract all methods as much as possible (A lesson from Uncle Bob). Then I writes unit test myself, this make me remember the code much better when doing vibe coding.

I am curious on how you solved it. Any Ideas?

Reasonable security baseline for self-hosted services 2026?

Niclas — Sun, 01 Feb 2026 01:06:05 +0000

Running a hobby project on a self-hosted server and wanted a quick sanity check on whether this counts as a reasonable minimum security baseline in 2026.

High-level setup:

Linux host
Dockerized services
Only 80/443 exposed publicly
Reverse proxy terminating TLS (HTTPS enforced)
ASP.NET (.NET 10) with built-in Identity + OAuth
EF Core/ORM only (no raw SQL)
auto-encoding, no user HTML rendering
Basic security headers (CSP, HSTS, nosniff, referrer, permissions)
Host firewall enabled (default deny incoming)
Regular security updates (OS + container rebuilds, unattended upgrades)
Rate limiting policies

This isn’t meant to be enterprise-grade, just sensible for a hobby app.
Does this sound like a reasonable baseline?

Any common blind spots people usually miss at this stage (ops, maintenance, or process-wise)?

Vibe coding before writing code?

Niclas — Fri, 30 Jan 2026 11:32:55 +0000

Before I wrote much code on my current project, I wrote documents.

The idea started after some frustration with social media. I spent time comparing different platforms and noticed how similar they all felt in practice. Most of them optimize for quick reactions and passive engagement. I kept wondering what kind of interaction would actually feel satisfying to respond to, where the creator might genuinely care about the reply, and where responding felt better than just clicking a like.

I gave the idea space by discussing it back and forth with different AI models. Over time this turned into a large, unstructured dataset of thoughts, constraints, and possibilities. Instead of trying to code from that directly, I treated it as raw material that needed processing.

Before doing that processing, I focused on orientation. As a programmer, what felt important to me was defining a Table of Contents in a README, writing a CONTRIBUTING guide, and creating an Agent.md file as an explicit entry point for prompting and discussion. These weren’t meant to lock decisions, but to give the project a shared mental baseline, even if that baseline was only for myself.

I wrote down best practices, architectural boundaries, coding rules, and style decisions as early constraints. I then refined those documents iteratively, again using AI models, before moving deeper into implementation.

These were the first steps I took before I could really start building.
I’m curious how others approach this phase. Do you do something similar, or are there other practices you’ve found useful early on?