We build software we intend to keep.
Fidrak is an independent software company. We design, build, and operate our own applications — end to end, and for the long term.
Most software is built to be handed off. A team designs it, another team ships it, a third team keeps it running until it is quietly retired.
We work the other way. Every application we release is one we expect to still be maintaining years from now. That expectation changes what we build, how we build it, and what we refuse to build at all.
What we work on
Habits.
Attention.
Travel.
Those three look unrelated until you notice what they have in common. Each is about recovery — of the body, of the mind, or by leaving.
The categories matter less than that common thread. We are interested in the hours that sit outside of work: how someone stops doing a thing they have done ten thousand times, how someone sits still, where someone goes to come back different.
Recovery is slow, private, and hard to measure. Software built around metrics tends to skip it — which is most of the reason these problems are still open.
These are unglamorous problems. They are also the ones people actually keep an app for.
How we work
Owned end to end
We do not take contract work and we do not white-label. Every product carries our name because every decision in it is ours — from the first sketch to the support inbox.
Built to be maintained
Shipping is the easy part. We hold our work to the standard of the person who will have to change it in three years, under pressure, with the original context long gone.
Deliberately small
We stay small on purpose. Small teams can hold an entire system in their heads, decide in an afternoon, and answer for the outcome. We would rather compound leverage than add headcount.
What we hold to
Restraint is a feature.
The easiest way to grow a consumer product is to take more of the user's attention and more of the user's data than the product actually needs. We treat both as costs, not resources. In our categories that is not a nicety — an app about recovery that farms your attention is a contradiction.
We collect what the product requires, and nothing more.
Not as a policy we publish, but as a constraint we design against before a single line is written.
We answer our own support mail.
The people who build the product read the complaints about it. There is no faster way to learn what is actually wrong.