All tests run on an 8-year-old MacBook Air (Intel). Over the past three years, I’ve built and released 10 specialized macOS apps for Android developers—not by working harder, but by building a system that makes shipping the next app easier than the last.
Many developers struggle to finish a single side project. I’ve shipped 10 production apps while working solo on aging hardware. The secret isn’t discipline or caffeine—it’s architecture. Each app I build makes the next one faster, because 80% of the plumbing is already solved.
TL;DR
- “Micro-App” architecture keeps each codebase small, focused, and independently deployable.
- A shared internal crate (
hiyoko-helper) provides licensing, auto-start, and path management—write once, use in all 10 apps. - Shared CSS tokens and React components eliminate UX decision-making for new apps.
- On a dual-core Intel MacBook Air, small codebases mean fast compile times—under 2 minutes per app.
The Micro-App Philosophy
The temptation is to build one “Ultimate Android Suite” that does everything. I tried that approach early on and abandoned it. A monolithic app means a single bug can block the entire release. On my 8GB machine, a large codebase means 15+ minute compile times.
Instead, each Hiyoko app solves exactly one problem:
HiyokoMTP → File transfer (MTP protocol)
HiyokoShot → Screenshot capture + transfer
HiyokoLogcat → Real-time log viewer + AI diagnostics
HiyokoPDFVault → PDF tools + encryption
HiyokoBar → System HUD in menu bar
HiyokoClip → Clipboard manager
HiyokoSync → Differential file sync
HiyokoAutoSync → Zero-touch wireless sync
HiyokoKit → All-in-one bundle
HiyokoLogcat → Free OSS log viewer
If a bug appears in HiyokoMTP’s file transfer logic, I can fix and ship a patch in 30 minutes without touching (or risking) the PDF encryption code. Small blast radius, fast iteration.
The 80% Reuse Strategy
Every app needs the same foundational behaviors: license checking, auto-start registration, macOS path resolution, update checking. Building this from scratch 10 times would be insanity.
The hiyoko-helper crate handles all of it:
// Every app's main.rs starts with the same 3 lines:
use hiyoko_helper::init_app;
fn main() {
let ctx = init_app("hiyoko-mtp", env!("CARGO_PKG_VERSION"))
.expect("Failed to initialize app");
tauri::Builder::default()
.manage(ctx)
.invoke_handler(tauri::generate_handler![/* app-specific commands */])
.run(tauri::generate_context!())
.expect("error running app");
}
When I build a new app, the first thing I do is add hiyoko-helper = { path = "../hiyoko-helper" } to Cargo.toml. Licensing, auto-start, and path management work immediately. I can focus 100% on the app’s unique logic.
Eliminating UX Decisions
Decision fatigue is a real productivity killer. For a solo developer, every decision you don’t have to make is time saved.
I eliminated UX decisions by standardizing everything visual:
/* Import once, design is done */
@import '../shared/hiyoko-tokens.css';
/* Each app only sets its accent color */
:root {
--accent: #4a9eff; /* HiyokoMTP = blue */
}
/* Everything else — backgrounds, typography, spacing,
glassmorphism, popovers — is inherited from tokens */
// New app scaffold — takes ~10 minutes
import { Toolbar } from '../shared/components/Toolbar';
import { SettingsModal } from '../shared/components/SettingsModal';
import { Toast } from '../shared/components/Toast';
function App() {
return (
<div className="hiyoko-app">
<Toolbar title="HiyokoNewApp" />
{/* App-specific content goes here */}
<Toast />
div>
);
}
The result: building a new app’s UI scaffold takes about 10 minutes. The design already looks like it belongs in the Hiyoko Suite because it is the Hiyoko Suite—same tokens, same components, different accent color.
The Compound Effect
Each app I ship makes the next one faster:
- App #1 (HiyokoMTP): 3 months. Built everything from scratch.
- App #3 (HiyokoShot): 3 weeks. Shared crate and components existed.
- App #7 (HiyokoClip): 10 days. The pattern was fully established.
- App #10 (HiyokoKit): 2 weeks. Mostly integration of existing engines.
This compound effect is the real productivity system. It’s not about working harder—it’s about making each unit of work count toward every future project.
Productivity for a solo developer isn’t about typing faster. It’s about making fewer decisions and reusing more solutions. Build the system first, then the apps practically build themselves.
How do you handle the overhead of multiple projects? Do you invest in shared infrastructure, or do you prefer each project to be fully independent?
If this was helpful, check out HiyokoKit — all-in-one Android dev toolkit (MTP file manager, Logcat+AI, ADB Tools, Monitor).
Built with Rust + Tauri v2. Tested on an 8-year-old MacBook Air.
