How we plan to build

You save something to look at later, then spend longer finding it than reading it. You leave a task halfway through and have to work out where you stopped. Small frustrations like these are where we want to begin at dysy works.

We want to build apps that help with a specific job and fit into the way people already spend their day. That means being careful about which problems we take on, and keeping the first version focused enough to do its job well.

Where we stand

We are still defining our first product. Its category, platform and release date are open. Our focus at this stage is to set a clear direction for development: what would make an app useful, how to test the idea, and what a first release should include.

The situations in this note are examples of needs we are interested in. We have not chosen one to announce as our first app.

Start with a specific task

Before committing to an idea, we want to describe the situation it would help with. Who is trying to do something? What do they use today? Where does the task become unnecessarily difficult? A category such as productivity is too broad to answer those questions on its own.

Take finding a saved item. The difficulty might be remembering where it went, recognizing it in a long list, or knowing whether it is still relevant. Each calls for a different response. We want to understand that distinction before deciding that another app is the answer.

Build enough to learn

Once we choose a problem, our next step will be a small prototype of the main task. We want to see whether someone can understand where to begin, complete the task and recognize the result. We plan to put that early version in front of people who encounter the problem, while there is still time to change the idea.

A first version should have a clear boundary. We would rather make one useful task dependable than launch several half-finished ones. Feedback should help us decide what to improve, what to leave out and, sometimes, whether to continue at all.

Plan for ordinary use

The first successful attempt is only part of the experience. Someone may close an app halfway through, lose a connection or return after a week. As we develop, we want to work through those situations alongside the main flow: what is saved, what needs attention and how to recover from a mistake.

We also want to question what an app asks for. An account, a permission or a notification should have a clear purpose. Choices about data, accessibility and ongoing maintenance belong in the development plan, rather than being left until the release is nearly ready.

Share the work as it develops

As the first product takes shape, we will use this space to explain the decisions behind it: the problem we chose, what changed after trying an early version, and what we are still working out. We will share examples when there is something concrete to discuss.

Confirmed features, screenshots, platforms and availability will be posted on the Now page. Here in the journal, we will keep a record of how the work gets there.