Driftya started with a feeling, Much of the online interaction had started to feel strangely weightless. A person could spend time making something, writing something, or sharing a part of themselves, and the response would often be the same few words. “Nice.” “Looks great.” “Amazing.” Small replies, quick reactions, and visible likes were everywhere, but very little of it felt meaningful. The interaction happened, but it did not seem to carry much weight.

Background

I kept thinking about that. I have worked as a software developer for many years, and over time I had built up a lot of patterns, abstractions, and project structures that I trusted. I already had a foundation in .NET and C#, with SOLID principles and Onion Architecture shaping how I like to build systems. Because of that, I knew I did not have to start from nothing.

Around the same time, I also wanted to get faster and more practical with LLM-assisted development. Instead of treating it like magic, I wanted to use it as a tool inside a structure I already believed in. I began building clear guidelines for agents so the output would align better with how I design software. That turned out to work well. It helped me get up to speed faster without giving up review quality or architecture discipline.

But speed alone was never enough. I still needed to understand the code deeply. One of the easiest ways to do that was through unit tests. Writing and reviewing tests helped me see how the pieces behaved, where boundaries were clear, and where something felt off. In many ways, that became part of the real starting point.

So I began with the basic, around the idea that a message could feel more meaningful for the replier.

Audience-driven platforms

Many platforms are built around audiences. The goal is visibility. Posts travel outward, gathering reactions, numbers, and signals that determine how far they spread. Over time, this changes how people write. Posts that trigger reactions travel further, so people naturally start writing things that provoke those reactions. The system does not say it directly, but it quietly encourages it.

Driftya explores a different direction. Instead of focusing on the audience, the system focuses on the individual exchange. A note is not written for a timeline or a crowd. It drifts to another person. That interaction ends there.

Because of that, there are no visible likes, follower counts, or public metrics. Those systems are very good at amplifying attention, but they also quietly turn communication into a score. When numbers become the signal people watch, writing slowly starts to adapt to what performs well.

The reply problem

One thing that also stood out to me was how popularity affects replies. When a post becomes very visible, hundreds or thousands of people might respond. In that situation the weight of each reply becomes smaller. It can easily disappear in a long thread, buried under other comments. Even if someone takes the time to respond thoughtfully, it can still feel like it barely matters.

Driftya approaches this differently. A note does not collect an endless stream of replies. It arrives to another person, and when they answer, the exchange closes. Because the interaction is contained between two people, the reply carries more weight. It is not competing with hundreds of other responses.

Privacy before growth

Driftya tries to step away from that. Another principle that shaped the design was privacy before growth. Many social platforms optimize first for expansion and engagement. Features are often designed to maximize activity, even if that activity pushes people toward more reactive or competitive behavior.

Here, the goal was different. Growth matters, but it should not come at the cost of the experience itself. If a feature improves reach but harms the feeling of writing or receiving a note, it is probably not the right feature.

In practice, that means choosing slower, simpler systems that protect the interaction between two people instead of trying to amplify it to thousands.

Architecture and SEO

Once the idea felt clear, the next question was how to build it without turning the site into heavy single-page application without SEO. Modern frameworks often push developers toward fully client-rendered applications or large meta-frameworks like Next.js. Those tools are powerful, but they also come with a lot of complexity and opinionated build systems.

For Driftya I chose a different direction.

The site itself is primarily server-rendered so that pages remain fast, simple, and visible to search engines. SEO was important from the beginning because a small project depends heavily on organic discovery. If search engines cannot understand your pages, it becomes much harder for new users to find the project.

At the same time, I still wanted the flexibility of React for interactive parts of the interface. The compromise was to use React islands. Instead of building the entire site as a large single-page application, only specific parts of the page become interactive React components. The rest of the page is delivered as normal HTML from the server.

This approach keeps several advantages:

• Pages remain search engine friendly because the core content is rendered on the server.

• JavaScript stays small and focused, since only certain components hydrate on the client.

• The architecture remains simple and compatible with the existing .NET application structure.

In other words, Driftya uses React where it adds value, but avoids turning the entire site into a heavy client application.

For a small project, that balance felt like the right trade-off. That is how Driftya began.