Design for the next developer
A project should explain itself through its folders, routes, database, and ordinary source files. The next maintainer should not need private context to discover how a request works.
Read the reasoningBusiness software accumulates history: exceptions, integrations, data, and decisions nobody remembers making. A framework should make that history easier to follow, not bury it beneath another platform.
Reepolee treats understandability, maintainability, and direct operation as constraints that shape every technical choice.
These are not universal rules for every system. They are the defaults we use for long-lived applications maintained by one developer or a small team.
A project should explain itself through its folders, routes, database, and ordinary source files. The next maintainer should not need private context to discover how a request works.
Read the reasoningConventions and generators should remove repetition without concealing the result. Generated code remains available for review, testing, and adaptation.
Read the reasoningUse SQL, constraints, relationships, and deliberate names as part of the application model, not as an implementation detail to hide behind imagined portability.
Read the reasoningAdd moving parts only when the application earns them. Simple deployment, visible failure modes, and fewer production packages are operational features.
Read the reasoningCode, data, and infrastructure are business responsibilities. The architecture should preserve the option to run on a modest VPS or on-premise.
Read the reasoningReepolee Framework and ReeWeb are MIT licensed because inspectability should not stop at documentation. The implementation, generators, defaults, and tradeoffs are open to examination and adaptation.
ReeWeb applies them to static sites and documentation. Reepolee Framework applies them to database-backed business applications. Engineering Notes preserve the longer arguments behind both.