Skip to content
Docksoft

Philosophy

Five things we believe, and what shipped because of them.

Principles are cheap to write and easy to abandon under a deadline. These five have survived contact with three products that are live in public, and each one is attached to the evidence that earned it.

Principle 01

Kairos

καιρός

The right moment. Time as something qualitative and finite, rather than merely counted.

Attention is the real price

Every product spends the user's focus before it returns anything. Most software treats that as free.

Software is usually priced in money and measured in engagement, which gets the accounting exactly backwards. The scarce thing is not the subscription fee. It is the finite number of times a person can be interrupted, asked to decide something, or made to learn an interface before they give up on it.

We treat attention as the first cost on the balance sheet. A feature that saves the user thirty seconds a week and costs them a new concept to learn has not obviously paid for itself. A notification has to justify itself against the cost of every future notification being trusted a little less.

This is why we argue against features more often than we argue for them, and why the question we ask most in a review is not whether something works, but whether it was worth the user's time to find out.

In practice

Rune exists entirely to give attention back. It is a product whose core value is the absence of other software.

Principle 02

Pistis

πίστις

Trust, and the good faith that has to be earned before it is given.

Consent is architecture, not policy

Privacy written in a document is a promise. Privacy built into the system is a property.

A privacy policy describes intentions. Intentions change when a company needs a metric to move. The only privacy commitment that survives commercial pressure is one that would require an engineering project to break.

So we build the guarantee into the structure. If reminders can be stored on the device, they are stored on the device — not because a policy forbids the server, but because there is no server call to remove later. If data can be deleted, deletion is a button the user can press, not a request routed through support.

This costs something. Local-first designs are harder, and data you never collected cannot be analysed. We think that is the correct trade, and it is one of the few things we will not negotiate on.

In practice

Dermiva handles face scans. Its camera opens only when the user opens it, reminders live on the device, and any scan can be deleted outright.

Principle 03

Sophrosyne

σωφροσύνη

Temperance. Self-restraint practised as a virtue, not as a limitation.

Restraint is a feature

A small surface that works completely beats a large surface that works partly.

Feature count is the easiest thing to compete on and the least useful thing to own. Every addition has to be designed, built, tested, documented, supported, and kept working through every future change. Most of that cost is invisible at the moment of the decision and unavoidable afterwards.

We would rather cut scope than ship a half-answer. A product that does six things properly is more trustworthy than one that does twenty things approximately, and it is dramatically cheaper to keep alive.

The corollary is that saying no is part of the job, including to ourselves. A good release often removes something.

In practice

Rune's session templates exist because we found almost nobody configures a custom session. We invested in three defaults instead of a better configuration screen.

Principle 04

Aletheia

ἀλήθεια

Truth as disclosure — what is no longer hidden, and so can be checked.

Shipping is the only proof

Roadmaps are not evidence. Neither are prototypes, decks, or design files.

It is possible to work on software for years and never learn whether any of it was right. Nothing on the way to release tells the truth — a demo can be steered, a prototype can avoid its own hard parts, and internal enthusiasm is not signal.

We publish our own products, under our own name, in public stores. Reviews are public and permanent. Crashes are counted by someone other than us. Refunds happen without a conversation. There is no version of that feedback we can spin, and a studio that has not put itself in that position has not yet been tested.

We would rather be judged on three products that are live than on ten that are described.

In practice

Rune and Dermiva are on the App Store now. Both have been through App Review, pricing decisions, and the releases that come after launch.

Principle 05

Techne

τέχνη

Craft. Knowing how to make the thing, as distinct from knowing about it.

The last ten percent is the product

Empty states, error copy, first run, offline, accessibility. Everything before that is a prototype.

The happy path is the part of the work that is easy to feel good about and the part users spend the least time noticing. What they remember is the moment something went wrong — a blank screen with no explanation, an error that names a database table, a form that discards what they typed.

That final stretch is where a product either earns trust or quietly loses it, and it is the first thing cut when a deadline moves. We plan for it explicitly instead of hoping there is room at the end, because there is never room at the end.

It also happens to be the cheapest possible quality signal. Careful empty states cost days. The impression they create is difficult to buy any other way.

In practice

Rune's blocking screen is custom-designed and deliberately calm. It is the screen users see at their most frustrated, and a hostile one would cost the product its users.

One more thing

None of this is a claim that we are the only studio that thinks this way. Plenty do. The difference we would point at is that each of these principles cost us something specific — a feature we did not build, a metric we cannot measure, an escape hatch we refused to add — and those costs are visible in the products rather than described here.

Working together

If this sounds like how you want your software built.

Tell us what you are trying to make, what it has to do, and what is making it difficult. That is enough to start a useful conversation.

Contact the dock

One address, read by the people who would do the work. No intake form, no calendar link — just an email.

tphamdn@gmail.com
Other reasons to writeWe reply within two business days