Software studio · Bolton, United Kingdom
PaperNova Atelier is a small studio building productivity software for Android. We are interested in the unglamorous part of software — the app you open twice a day for eleven seconds and never think about otherwise.
Four positions that decide almost every argument we have internally.
Data you create belongs on the device you created it on. Syncing is a feature some people need, not a precondition for opening an app. Nothing we ship requires a server to function, which means nothing we ship can go down, get breached, or quietly change its terms.
We would rather build six features that work completely than twenty that work partly. Every setting we add is a decision we have handed to the user, and most users did not ask for the decision.
Every permission an app requests is something the user has to trust us with. We treat the manifest as a bill we have to justify, not a shopping list. If a feature needs access we cannot defend in one sentence, the feature does not ship.
No streak guilt, no artificial scarcity, no notifications engineered to pull you back. If our app is open, it should be because you have something to do in it. Time spent in the app is not a metric we optimise.
Our current release. A Kanban board for personal work, with a built-in glossary and quiz for people learning Agile properly rather than by osmosis.
Productivity · Android
Boards, columns, cards. Priority, due dates, tags, checklists. Plus the theory behind the method, in the same app.
Kept as a board, because it would be strange for us to run it any other way. Nothing here has a promised date — it moves right when it is ready.
Backlog3
Starting layouts for common workflows so a new board is not an empty screen.
A place for finished cards that keeps the board clean without deleting history.
Early notes on a focused writing tool. Nothing decided, nothing promised.
In progress2
More Kanban and Scrum terms, with the plain-English definition first and the jargon second.
Wider screens should show more than one column at a time. Currently in testing.
Shipped3
Sub-items on a card, so a task can be broken down without spawning five more cards.
Question set built on the glossary, for checking retention rather than recognition.
The default and, for most of our testers, the only one they ever switched to.
Five stages, roughly. In practice the middle three repeat until the thing stops being annoying to use.
Every project starts as a specific annoyance with an existing tool, written down in a sentence. If we cannot write the sentence, there is no project.
Screens are sketched before they are coded. It is faster to throw away a drawing than a Compose layout, and the drawings are where most of the bad ideas die.
The smallest version that does the core job end to end, installed on a real phone and used for a week. Most features get cut at this stage, which is the point of the stage.
A pass with no goal except removing things. Settings that nobody changed, screens that nobody opened, animations that were fun once.
Release, then read every piece of feedback that arrives. The roadmap above is mostly other people's irritations, collected patiently.
Deliberately boring choices. Boring technology has documentation, and documentation is what you need at eleven at night.
Kotlin, targeting current stable Android APIs.
Jetpack Compose, with Material components rather than a bespoke design system.
On-device only. No backend, no sync service, no user accounts to manage.
Google Play. One release channel, no side-loaded builds, no beta maze.
None requested at runtime in the current release. Reviewed as a line item before every submission.
No. Boards, cards, the glossary and the quiz all live on the device. You can put the phone in aeroplane mode and lose nothing.
In the app's private storage on your own phone, in the sandbox Android gives every application. We run no server that could receive it, so there is nothing for us to look at even in principle.
They are deleted along with the app, because the only copy was on your device. If you are changing phones, export before you uninstall.
Possibly, eventually, and only as something you switch on. It would not become a requirement for using the app, and it would come with its own clearly written explanation of what leaves your phone.
We support several versions back from current stable rather than only the newest. Dropping support for an older release is something we do reluctantly and only when a platform change forces it.
English at present. Additional languages are on the list, and the glossary content is the part that takes real effort — a bad translation of a technical term is worse than none.
Email us. Include your device model and Android version if it is a bug — it usually cuts a day off the diagnosis. We read everything and reply within five working days.
Anything purchased through Google Play is refunded by Google under its own policy, since Google is the merchant of record. Write to us anyway if something went wrong — we would rather know.
Bug reports, feature requests, questions about your data, or anything covered in the privacy policy. One inbox, read by the people who build the apps.
paper@elevatehouse.worldJournalists and reviewers are welcome to use the studio name, app names and store screenshots without asking. For logo files or a review build, email us and mention what you are writing.