Engineering Notes
Why the engineering decisions were made. The reasoning, the trade-offs, and the failures that taught us each lesson. We collected them over decades in different shapes and forms, starting with Post-It notes and the latest maintained in our own Markdown Notes Manager connected to Github repo.
The Reepolee Approach summarizes the principles. These notes preserve the arguments, tradeoffs, and implementation decisions behind them.
Read Our ApproachOur Bet: Bun Is Closing the Gap to Application Servers
Why we build on Bun's native API surface rather than assembling an application from packages, what the application server model actually provided, and an honest account of the risk in concentrating a business on one runtime.
The Generator Pattern, Not a Library
Why Reepolee uses a code generator instead of a library, and what that choice means for security, maintainability, and the surface of change in your own project.
No Deps, No Build
On building zero-dependency, no-build web applications with Bun for nonprofits, education, intranets, and small teams - and why appropriate complexity is a feature, not a compromise.
The Database Is Not a JavaScript Object
A case for writing SQL directly - not because ORMs are wrong, but because the developer who reaches for one without learning what it replaces has chosen a ceiling.
Use the Tools That Work for You
On choosing tools by what makes you productive, not by what the community has decided signals the right kind of developer.
Not Everything Needs an LLM
Why smart teams use LLMs to build generators, not to replace them - and how encoding domain knowledge once, deterministically, beats paying an API per token forever.
MVC Separated the Wrong Things
On code proximity, feature-per-folder, single-file templates, and why Tailwind classes tell you more about a component than a semantic class name ever will.
Default Is a Feature
On keeping tools at their defaults, the portability of skills over config, why TUIs are nostalgia dressed in Rust, and what native GUI tools are quietly getting right.
Deciding Is Not a Privilege, It Is Where the Pressure Goes
The case for one technically deep person carrying accountability for a team's delivery, release, and stakeholder relationships, framed as absorbing pressure rather than controlling ideas, including the failure modes of that arrangement.
Living on the Edge
On early adoption, one-off software, the kind of problems nobody else wants to tackle, and why code is the advantage that compounds.