Edliss Notes

Feature Requests Are Design Feedback

Fri, 03 Jul 2026 00:00:00 +0000

One of the easiest traps in product development is thinking feature requests are about features.

Most of the time, they aren't.

When someone asks for a feature, they’re usually describing something that didn’t work the way they expected. The feature they’ve suggested is simply their best guess at how to fix it.

That’s what makes them so valuable.

Not because they tell you what to build, but because they reveal where people are struggling.

The more interesting question isn’t, “Should we build this?”

It's, “What happened that made someone ask for it?”

Sometimes the answer is exactly the feature they requested.

Sometimes it’s a confusing interface. Missing information. An unclear workflow. Or a default that doesn’t match how people actually use the product.

The feature request tells you where to look.

Understanding the problem tells you what to build.

The Cost of Trying to Be Helpful

Thu, 02 Jul 2026 00:00:00 +0000

Software has become very eager to help.

Open an app and you're greeted with a product tour. Dismiss that and there's a prompt to enable notifications. A few minutes later you're asked to rate the app. Somewhere in the corner is a chat bubble waiting to answer questions you haven't asked. Before you leave, there's a reminder to subscribe to a newsletter.

Each interruption is easy to justify on its own.

Together, they make software feel exhausting.

Most of these features exist with good intentions. Product tours reduce confusion. Notifications bring people back. AI suggestions promise to save time. Feedback prompts help developers improve the product.

The problem isn't any single one of them.

It's that every feature assumes your attention is available.

Attention is one of the few things software can't ask for without taking it away from what you're trying to do.

One reason this happens is that it's easy for the people building a product to overestimate their product's importance in someone else's day.

After spending months or years building an app, every feature feels significant. Every announcement seems worth showing. Every improvement deserves attention.

For the person using it, though, your app is often just one small stop in a much busier day. They aren't thinking about your roadmap, your latest release, or your engagement metrics. They simply want to accomplish a task and move on.

Designing with that in mind leads to different decisions. You become more selective about when you interrupt, because you stop assuming your product deserves attention simply because it exists.

Helpful software understands this. It waits. It stays out of the way until there's a genuine reason to interrupt.

A spell checker highlights mistakes after you've written something. Navigation reroutes when traffic changes. A backup runs quietly in the background. These are helpful because they solve problems without demanding attention first.

Whenever I'm building something, I try to ask one simple question:

If we removed this interruption entirely, how many people would actually miss it?

Often, the answer is very few.

The best software isn't the software that offers the most help.

It's the software that knows when not to.

Simple Is Hard

Thu, 11 Jun 2026 00:00:00 +0000

I’ve always believed simple software is hard.

Not because simple apps are small, but because simple software forces decisions. You have to decide what belongs, what does not, what should be hidden, and what should never exist in the first place.

Adding features is often easier than refusing them. A feature can feel like progress. It gives you something visible to point at. But every feature also adds weight: another button, another state, another decision for the user, another thing to maintain.

The software I like most is simple, usable, useful, and beautiful. Not decorative. Not empty. Not artificially minimal. Just clear about what it is trying to do.

That is the kind of software I want Edliss to make.

Kurkum, for example, is not trying to become a complete cooking platform. It is a recipe app. It should help you save recipes, organise them, and cook from them. The closer it stays to that, the better it becomes.

Simple does not mean unfinished. It means disciplined.

Not Every App Needs an Account

Thu, 11 Jun 2026 00:00:00 +0000

A lot of apps ask you to create an account before you can do anything meaningful.

Sometimes that makes sense. If you are building a collaborative platform, a multi-user service, or something that genuinely depends on shared infrastructure, accounts are part of the product.

But many apps ask for accounts simply because that became the default way software is built.

I’ve never liked that assumption.

Accounts also changed the incentives of many apps. Once an app has its own account system, it often starts collecting data that is useful to the business but not essential to the product. For some software, that may be justified. For many small personal utilities, I think it adds complexity without giving much back to the user.

Most utility apps are personal tools. They help you organize something, remember something, learn something, or create something. In many cases, the app does not actually need its own user system, identity layer, profile management, or backend-driven account architecture.

Apple platforms already provide a user identity through the device and iCloud account. For the kinds of apps I build, that is often enough.

Kurkum, for example, syncs recipes across a user’s devices through iCloud. There is no separate Kurkum account because I never felt there should be one. The app is personal. Your recipes belong to you. The system already knows who you are on your own devices.

Avoiding accounts also changes the feel of software in ways I care about. The app becomes faster to enter, simpler to understand, and easier to trust. There are fewer passwords, fewer settings, fewer user-management flows, and fewer moments where the software asks you to “join” something before it becomes useful.

There are tradeoffs, of course. Building this way means accepting certain platform boundaries. It also means intentionally not building some types of features. But constraints are often healthy for software. They force clarity.

I increasingly believe many apps would improve if they asked less from the user.

Not every piece of software needs to become a service.

Software Should Not Feel Like Administration

Thu, 11 Jun 2026 00:00:00 +0000

A lot of software makes simple tasks feel like administration.

You want to save a recipe, but first you have to fill out a form. You want to write a note, but first you have to choose a template. You want to organize something small, but suddenly the app gives you tags, categories, statuses, permissions, reminders, sharing options, and settings.

There is a point where software stops helping and starts assigning work.

I think about this a lot when building apps. The job of the interface is not to expose everything the system can do. The job is to make the next useful action feel obvious.

In Kurkum, that means recipe editing should feel closer to writing than data entry. Ingredients and steps should be easy to add. The structure should help, but not get in the way. A recipe app should not feel like managing a database.

This is also why I prefer focused apps. When an app tries to handle every possible workflow, it often becomes slower, heavier, and less pleasant for the ordinary case.

Good software should reduce effort.

It should not make you feel like you are doing paperwork.