1. Agree what it does
One page: the job the software does, who uses it, what it does not do. Most arguments later come from this page being vague now.
Finish the logic before the pixels
The computing part is a plain module with unit tests and no dependency on the interface. When a number looks wrong three months later, we already know where it is not.
Ask for less than you need
Every permission, every required field, every step before first use has to justify itself. We also strip the permissions that libraries declare on our behalf, so the manifest describes the app rather than its dependencies.
Offline is the default path
We build the version that works with the network off, then add the online part. Doing it the other way round produces an app that shows a spinner in a lift.
Data belongs to the person who made it
Local storage, working export, working import. If we cannot restore a backup we produced, we have not finished the feature.
Say what went wrong
An error message names the thing that failed and what to try. "Something went wrong" tells the user nothing and tells us nothing when they report it.
Measure the opening, not the demo
Cold start, time to first usable screen, and size of the download. Those three decide whether a utility gets used or uninstalled, and they are easy to let slip.
No pattern we would be annoyed by
No fake countdowns, no cancel buried four screens deep, no notification whose only job is reengagement, no review prompt in the middle of a task.
Write it down for the next person
A short README that says how to build it, what the modules do, and which decisions were deliberate. Usually the next person is one of us, a year later.
Delete more than you add
Features accumulate, and each one costs something at every release afterwards. A review where we remove two settings is a good review.
The shape of a project
Four steps, and we stop at the end of each one
Stopping matters. It is where you get to change your mind cheaply.
2. Build the engine
The rules, the calculations, the data model, with tests. You can run it before any screen exists.
3. Build the interface
Compose or Flutter on mobile, plain HTML and CSS on the web. We check it on a slow device, not only the fast one.
4. Release and watch
Signed build, store declarations filled in by hand, then a quiet period where we fix what real use turns up.
Tools of the trade
What we reach for
We keep the stack small on purpose. Two mobile paths and one web path cover almost everything we are asked for, and staying inside them means we are fast at the parts that repeat.
When a project genuinely needs something else, we say so before starting rather than bending a tool that does not fit.
Android, nativeKotlin · Compose · Room
Android, cross-platformFlutter · Riverpod · Drift
WebHTML · CSS · vanilla JS
StorageSQLite · DataStore · files
BuildGradle · signed AAB
TestingUnit tests on the engine
No framework on a page that does not need one.
Does this match how you want to work?
If it does, send us the one-page version of your idea and we will tell you honestly whether we are the right people for it.
Contact us