NAME
ENGINEER
DESCRIPTION
Has shipped enough native apps to know what breaks two years after a release. Writes the regression test before the fix. Has opinions about file structure and is correct about most of them. Closes the laptop on Friday.
// HARDOS SIA · native mobile utility studio · est. MMXXVI
~/hardos — bash — 80×24
$ whoami > HARDOS SIA — a small mobile utility studio. $ cat manifesto.md | head -1 > Ship narrow. Hold to. $ ./categories > vpn · cleaners · camera tools > safety · converters · scanners $ ./inbox > info@hardossia.com (open weekdays) $
We ship native iOS and Android utility apps in six fixed categories. The stack is short on purpose. The releases are deliberate. We answer email by the next working day.
// 01 / what we build
ls categories/
Six fixed categories. We work in these and only these. Stepping outside the list is, in our experience, the cleanest way for a small studio to ship a worse version of something that is already crowded.
Each entry below describes what the category looks like in our hands, written the way we would describe it on a first call.
01 / category
VPN.
A toggle, an indicator, a hidden network. We ship VPN apps that disappear from a user's mind ten seconds after first launch — which is, in our reading, what a VPN is for.
02 / category
Cleaners.
A cleaner has one job: tell the truth about what is taking up space, then let the user decide what to delete. We refuse to round up. We refuse to extrapolate. We refuse to invent the gigabyte that did not exist.
03 / category
Camera tools.
Tools that fit in the same row as the calculator. They open in under a second, do one thing per release, and never claim to be the editor — that is a different app, by a different team.
04 / category
Safety utilities.
Small layers of resilience for a phone. Tiles you set up once on a parent's device and never have to revisit. We are careful never to imply replacement of any actual emergency service.
05 / category
Converters.
A file goes in. A file comes out. The first one stays where it was. We do not delete the source to look efficient and we do not enrol the user in a recurring subscription to keep their own outputs.
06 / category
Scanners.
On-device document scanning, returned as clean PDFs. We are uninterested in becoming a cloud-stored archive. The user owns the file and the file leaves with them.
// 02 / stack
cat package.json
A short, deliberate kit. Anything outside it has to earn its place in writing — which most things do not. The list below is what we have shipped real production traffic on, repeatedly, for long enough to know how each piece fails.
package.jsonjson
{
"name": "hardossia",
"engines": {
"ios": ">= 16.0",
"android": ">= api 30"
},
"dependencies": {
"swift": "^6.0",
"swiftui": "*",
"kotlin": "^2.0",
"jetpack-compose": "*",
"revenuecat": "latest",
"adapty": "latest",
"firebase/auth": "*",
"sentry": "*",
"testflight": "via api",
"linear": "via api",
"figma": "*"
},
"rejects": [
"cross-platform UI runtimes",
"ad-mediation networks",
"user-level analytics",
"headless CMS for static copy"
]
}// 03 / manifesto
Four lines we ship by.
// n° 01
> Native, on purpose.
We ship native iOS and native Android because phones are not browsers. Cross-platform UI looks fine in a demo and worse in the field. Our maintenance cost is lower because of this, not higher.
// n° 02
> Subtraction is a feature.
Each release we ask which thing to remove. The answer is rarely 'nothing'. A narrow utility ages well; a broad one needs constant attention or it rots quietly under a settings menu.
// n° 03
> We do not measure what we cannot improve.
User-level analytics tempts us to ship a dashboard and not a fix. We measure the small handful of metrics we can act on and ignore the rest. Our internal dashboard is two lines long.
// n° 04
> Compatibility is care.
Apps in our categories live on a user's phone for years. We support old iOS versions for as long as a meaningful population of our installs sit on them, even when the SDKs have moved on without us.
// 04 / team
man team
Four people, by role. We do not list names or photos here — introductions happen by email after the first conversation, where they belong. What follows is a short man-page entry per role.
NAME
DESIGNER
DESCRIPTION
Spends as much time on the empty state as on the populated one. Refuses to ship a feature whose first-run is a paywall. Has opinions about haptics, default toggles, and the phrasing of confirmation dialogs.
NAME
QA
DESCRIPTION
Owns the matrix of devices, OS versions, and edge cases the team has agreed to support. Files reproducible bug reports. Knows the difference between 'it does not work' and 'I do not know how to make it work' and asks accordingly.
NAME
RELEASE
DESCRIPTION
Owns the calendar of submissions, review cycles, and the day a build actually goes live. Replies to email at human speed. Writes the changelog in the way a real user would want to read it.
$ ./inbox
Have a project that fits one of the six? Email us a paragraph.