The Architecture Development Guidelines

Most projects start in a rush, without even a minimal conceptual organization just to deliver some MVP’s at the speed of light. At first it feels fine good improvisations, fast move and you tell yourself what the hell about structure, it will emerge over time with the team work.

But when the project grows, things start to break. Data literally explodes, folders multiply, repositories turn into garbage disposals and suddenly everyone start wasting time just trying to understand where things live and how they connect. That’s when the headaches begin: late nights, too much caffeine, and “urgent” cleanup work that should have been done from day one.

This is why, before writing the first code line, I’m writing an Architecture Development Guideline a document for mere mortal developers in the AI era.

Why it’s needed

Don’t blame me: I hate rules and rigid processes. I’m open-minded and I love freedom and creativity. But after some good decades spent on many projects and OSIRIS is not an exception I’ve learned that writing solid development guidelines early sets the foundation for everything that follows: the toolbox, producers, and extensions.

Instead of guessing, improvising, repeating the same mistakes and slowly building a Frankenstein project, it’s better to define a few guardrails from the beginning that give’s everyone the good direction to follow.

Think of it as painting lines on the road: not to limit freedom, creativity or speed, but to keep the ecosystem consistent, scalable and sane.

Learn more

For progress check the docs folder in the dev branch on: OSIRIS GitHub Repo