people see the 62 articles, the secured SaaS, the fintech follower, the dubai engineer
nodding at my code — and they imagine some polished founder routine.
the truth? i run a technology holding company from a poco c55 that cost less than
your mechanical keyboard. no office. no team. no mba. just an operating system i
built to make one kid function like a company.
here's the exact daily OS. steal it.
the morning block (build before the world wakes)
first hour is never content. never social. it's BUILD.
- check koda's live counter (real users = real responsibility)
- scan for overnight bug reports (xulingfeng taught me: production never sleeps)
- ship one fix or one feature before breakfast
rule #1: create before you consume. if i open dev.to or discord before i ship
something, the day belongs to the internet. if i ship first, the day belongs to hynaweb.
📱 the constraint stack (why the $150 phone is a feature)
everything runs mobile-first because everything HAS to:
- code editor on phone → forces short, clean functions (no room for sprawl)
- cloudflare dashboard in chrome desktop-mode → deploys edge workers from bed
- supabase sql editor → schema changes between classes
- github mobile → commits, issues, the lexora repo sitting in cryosleep
the constraint isn't a limitation. it's a filter. if a task can't be done from a
poco c55, it's probably too complicated. complexity is the enemy of solo founders.
🧠 the attention budget (the real scarce resource)
i don't manage time. i manage ATTENTION. three buckets, every day:
- BUILD (40%) — koda, dojo feed, apic, shipping real things
- BROADCAST (30%) — one article, replies to ivan/richard/xulingfeng, the footprint
- COMPOUND (30%) — partnerships, the lnvs email, thinking about the lexora doctrine
most founders spend 90% on broadcast and wonder why nothing ships. i cap broadcast
at 30%. the work has to exist before the story about the work can exist.
🪦 the "not today" list (the discipline nobody sees)
the hardest part of the job isn't what i do. it's what i REFUSE to do:
- launch lexora early (it's a scale ai rival waiting for its own company, not a side-quest)
- chase every feature request (dojo feed doesn't need 40 features, it needs 4 that work)
- respond to every notification immediately (async is the solo founder's superpower)
- compare my day 36 to someone else's year 5 (the graveyard taught me: compounding beats sprinting)
a ceo's real job is saying no to good things so great things can breathe.
🔄 the evening review (the 5-minute compound check)
every night, five questions before the phone charges:
- did hynaweb gain something today it didn't have yesterday?
- did i ship, or just talk about shipping?
- who did i thank, reply to, or convert into a champion today?
- what's article #64's variation from the 12-rotation bible?
- is the lexora repo still sleeping safely on github? (always yes. good.)
if question #1 is "no" two days in a row, something's wrong. the holding company
must compound daily — even by one line of code, one reply, one indexed word.
🐯 the truth about running a company at 12
it's not about being a prodigy. it's about having no choice but to be systematic.
adults can afford to wing it — they have teams, budgets, second chances. i have
none of those. so everything needs a system: the 12-variation content bible, the
attention budget, the morning build block, the lexora doctrine, the evening review.
the systems aren't there because i'm disciplined. they're there because WITHOUT them,
one kid on a $150 phone collapses under the weight of a holding company in a week.
systems are how the small survive the big.
📌 steal the OS
you don't need to be 12. you don't need a poco c55. you need:
✅ a morning build block (create before you consume)
✅ an attention budget (cap broadcast at 30%)
✅ a "not today" list (protect the great from the good)
✅ an evening compound check (did the company gain something?)
the rest is just showing up every day and refusing to let the day belong to the internet.
the dojo is open. the vault is locked. the OS is yours.
— harun, 12
founder & ceo, hynaweb
hynaweb.vercel.app · koda-aicodementor.netlify.app
Top comments (6)
The attention budget is the strongest part of this OS — but the way you keep it honest could be even sharper. Right now 'did hynaweb gain something today' is a question you answer from memory at night, and memory is generous. Cheaper version: keep one append-only file where every shipped item gets a single line the moment it lands (what, one sentence of why, timestamp). Your evening review then reads yesterday's file instead of recalling the day — question #1 becomes a fact-check, not a mood check, and 'no' two days in a row becomes undeniable because the file's last entry has a date on it. Same trick for the broadcast cap: 30% is only enforceable if BROADCAST time is counted where it already happens (article drafts, replies), not estimated from feeling. One small addition to your phone-only constraint: pair the short functions with short commits, so every morning build block ends in something deployable — 'ship before breakfast' stays true even when breakfast gets interrupted.
@contentclips — this is the kind of comment that upgrades the whole system.
Adopting all three today:
Append-only ship log (SHIPLOG.md) — every shipped item gets one line
the moment it lands. Evening review #1 is now a fact-check against
yesterday's file, not a mood-check against my memory. Undeniable stalls.
Broadcast counted at the source — draft time + reply time logged where
it happens, so the 30% cap is enforced, not estimated.
Short commits = deployable mornings — every build block ends in
something shippable, so "ship before breakfast" survives breakfast
getting interrupted (it will. i'm 12.)
You just made the OS interrupt-proof and ego-proof. This is exactly
why I build in public — the comment section ships features I'd never
think of alone. Respect. ⏰
Glad it lands - the SHIPLOG idea compounds fast: within two weeks the log itself becomes your roadmap, because the shipped lines show what you actually finish versus what you just start. One addition that pairs well with undeniable stalls: when you stall, write the one blocker sentence into that log entry instead of deleting the task. Stalled items with a reason attached are usually fifteen minutes from unstalled - the reason is the unlock.
@contentclips — "the reason is the unlock" might be the most useful
sentence I've read all year. Adopting it immediately: the ship log
now has two entry types — SHIPS and STALLS. When something stalls,
I write the one blocker sentence instead of deleting the task.
You're right that this compounds fast — within two weeks the log
becomes the real roadmap (what I actually finish vs. what I just
start). And the graveyard hits different now: Lexora, Queueless,
DataForge might have survived if I'd named their blockers instead
of silently shelving them.
Four upgrades in one thread. You've quietly become HYNAWEB's
external COO. Respect. ⏰
One guardrail for STALLS: after the one blocker sentence, add the next 15-minute physical step you'd take with free time today. A blocker sentence stores the pain; a next-step line stores the work — you skip the whole 'why was this stuck?' reload when you come back. Second: date every STALLS entry. If the same blocker shows up three times, it's not a todo anymore — it's either a scope cut or a dependency you unblock deliberately. Three repeats is the task telling you its real cost.
So when are we getting the public repo?