Systems I've Built
I've built systems from scratch and inherited disasters. Here's what building taught me about architecture, failure modes, and trade-offs.
Billivio - Usage metering and entitlement system
Built a system to track and enforce usage limits for pay-per-use products. Users purchase credits through their payment processor (Stripe, PayPal, etc.), receive an invoice number, redeem it in the app, and the system meters their usage against what they paid for.
What this taught me: Entitlement systems are deceptively complex. The gap between "user paid" and "user can use" creates race conditions most developers don't anticipate. Invoice redemption needs idempotency. Usage tracking needs atomic operations. The payment processor succeeds, but the user's network fails before they get the invoice—now what? These edge cases define the system's reliability.
Visit billivio.com →
JustHTML.dev — No-npm developer community and methodology
Built a community platform and resource hub around a single premise: the browser's native platform — HTML, CSS, and JavaScript — is sufficient for most web applications. The site features a project showcase, technical guides, and a growing community of developers building without npm or frontend frameworks.
What this taught me: Dependency risk is an architectural decision that most developers never consciously make. The npm ecosystem accumulated over 3,000 confirmed malicious packages in 2024 alone. The September 2025 Shai-Hulud worm self-propagated through 500+ packages with 2.6 billion combined weekly downloads — autonomously, because the architecture allowed it. Every dependency your system takes on is a trust decision you are making on behalf of your users. Most systems make that decision carelessly, at volume, because the tooling makes it frictionless. Frictionless is not the same as safe.
The architectural response is not paranoia — it is deliberate minimalism. Build with what the platform provides. Add dependencies only when the platform genuinely cannot do the job. Treat your dependency tree as part of your attack surface, because it is.
Visit JustHTML.dev →
Daklens - CSV data cleaning tool
As a demo for Billivio, I built a web-based tool to clean and transform messy CSV files. Users upload broken exports, apply transforms (remove duplicates, fix formatting, standardize columns), and download clean data.
What this taught me: Data import is where most systems break. The gap between "what the system expects" and "what users actually upload" is vast. Character encoding issues, inconsistent delimiters, malformed rows—these aren't edge cases, they're the norm. Building a reliable CSV parser means assuming the data is wrong until proven otherwise.
Visit daklens.com →These aren't just portfolio pieces—they're proof I understand how systems break, scale, and drift from their original intent. Each one taught me something that informs how I analyze other people's systems.
Work with me