How CepatEdge Was Born
I’m nineteen. I’m in semester four. Everything you see in this repo — the maintenance workflows, the edge stack, the docs tree — I built it solo. This page is the honest version of how that happened, not a pitch deck.
Where I actually started
I started coding seriously on January 14, 2024. I didn’t have a PC. My whole setup was an Android phone and Termux. That sounds romantic in one sentence and exhausting in real life: tiny screen, weird ergonomics, and the constant feeling that you’re always one mistake away from losing your flow. But it was what I had, so I used it.
I got my first proper laptop in May 2025. That sounds like a small upgrade. It wasn’t. It was the moment I could think in projects instead of in tiny experiments.
What CepatEdge is, in human terms
CepatEdge is a full maintenance management system — the kind of thing institutions use to keep work orders, roles, and operations from turning into chaos. I didn’t set out to impress anyone with buzzwords. I wanted something that could run for real: fast, permissioned, and cheap to operate on modern infra.
The stack matches what the architecture docs describe, because I needed it to be boring-in-a-good-way:
- Hono on Cloudflare Workers for the API
- Neon + Drizzle for Postgres
- Durable Objects for the caching model
- R2 where files belong in object storage
- JWT, RBAC, and real auth hardening — including 2FA (TOTP, backup codes, email OTP)
I shipped that core in under two months while I was in semester two. I’m not saying that to flex. I’m saying it because it explains the pace: I was learning and building at the same time, and I didn’t have a team to hide behind.
The frontend detour that mattered
At some point the UI direction stopped fitting. I migrated the frontend away from Next.js toward a Vite + React SPA on Cloudflare Pages. The goal was simple: clean dynamic routing without dragging around server framework baggage for a client-heavy app. It wasn’t “framework tourism.” It was me trying to remove friction from routes like maintenance detail pages, profiles, and admin surfaces — the stuff that needs to feel instant.
That migration helped. Then it exposed the next problem.
The wall that doesn’t show up in architecture diagrams
Internationalization.
Five languages. More than 1,200 keys. Hundreds of files touching copy. I wired i18next the way the frontend docs describe: en.json as source of truth, stable key hierarchy, navigation using labelKeys instead of English sentences baked into data, and API errors mapped through codes — not random server prose.
At small scale, messy i18n is annoying. At this scale, it becomes a project risk: missing keys, shape drift between locales, dynamic t(...) call sites you can’t prove in review, and CI that still doesn’t give you confidence.
I got genuinely stuck. Not “I need a coffee” stuck — more like I can’t ship safely stuck.
That frustration is what forced a pause. And it’s also why another repo exists.
The sibling project (and why it’s separate)
I didn’t solve that i18n wall by adding one more script inside this monorepo. I built i18nprune as its own toolkit — validate, sync, generate, fill, review, cleanup, CI-shaped workflows — because the problem deserved a real tool, not another temporary patch.
If you want the tool’s origin story, read it in the i18nprune repo: docs/journeyREADME.md. If you want the philosophy of this platform — why I care about institutions not getting trapped by vendors — read why-this-exists.md.
Why I’m telling you this
I’m still solo. I’m still learning in public. CepatEdge is my attempt to build something serious without pretending it fell out of a corporate factory.
If you’re reading this because you’re evaluating the system, contributing, or just curious: thanks for looking at the work for real. If you’re a dev drowning in locale files — I’ve been there — and I hope the split between this app and i18nprune saves you some of the pain I paid for in late nights and stubborn commits.
That’s the journey so far. More to build.