VOL. VII

• GitHub Codeowners
• HausKeeper
• Webflow Recap
• Misc Dev Stuff

GitHub Codeowners

Like already discussed in a previous DevDungeon, there should be two "lead devs" / "main maintainers" for each project. GitHubs Codeowners feature comes pretty handy in this case. You can use a CODEOWNERS file to define individuals or teams that are responsible for code in a repository.

/.github/CODEOWNERS

# Default owners for everything in the repo
# Will be requested for review when someone opens a pull request
*            @edwin-shdw @david-bonhagen

# The fullhaus-developers team will be requested for review
# on changes inside /docs and /dev-dungeon directory
/docs        @FULLHAUS-GmbH/fullhaus-developers
/dev-dungeon @FULLHAUS-GmbH/fullhaus-developers

The file can be configured so it matches more specific needs:

This file for example would define @sebastian-iffland as overall codeowner, however when a PR is opened that only targets frontend files (.ts and .scss in this case) only a review from @BreathCodeFlow will be requested.

*      @sebastian-iffland

*.ts   @BreathCodeFlow
*.scss @BreathCodeFlow

This can then also be combined with branch protections and rulesets which can be adjusted to ensure that changed code must be reviewed by an owner of the changed files.

You can read the whole spec in the GitHub Docs.

HausKeeper

Hauskeeper is our own custom GitHub App/Bot which makes your live easier by automating repetitive repository setup tasks. Whether you're spinning up a new repo or ensuring consistency across projects, HausKeeper has your back.

Check out all features at the Docs!

Webflow Recap

Webflow is a no-code SaaS platform (with a built-in CMS) that enables you to build responsive websites through a browser-based visual editor. We recently completed two projects using Webflow and wanted to take a moment to summarize our experience so far.

So, what are the benefits of using Webflow?

• Visual Design + Code Power You can design visually while maintaining the flexibility of HTML, CSS, and some JS.
• CMS without Code The Webflow CMS is super intuitive. You can create collections (like blog posts, team members, projects) and dynamically bind them to designs — no backend code required.
• Hosting & SSL Included Hosting is fast and secure, with SSL, CDN, backups, and automatic scaling built-in.
• Client Editor Clients can easily update content through the editor without messing with design or layout.
• Figma-Like Design Workflow For designers familiar with Figma/Sketch, Webflow feels like a natural extension into live, interactive design.

But where does Webflow fall short?

While Webflow is a great option for smaller websites and no-code workflows, we ran into limitations when working on more complex, custom designs.

The first issue is flexibility. As soon as you need to implement more “exotic” layouts or tweak backend logic (even slightly) Webflow starts to feel restrictive. It’s a no-code platform, which means you're boxed into what the platform allows. For developers, this can be frustrating. For designers, the learning curve is steeper than intended, as the interface leans more toward developer thinking (box models, classes, breakpoints, etc.).

Then there’s pricing, which quickly escalates:

• Need more seats? → Pay for it
• Need CMS functionality? → Pay for it
• Need localization? → Pay for it

Despite paying for team seats, collaboration is limited. You can’t work concurrently on the same project like you would in Figma. Instead, one person "holds" the editing lock at a time, meaning you have to request full control from a teammate before making changes—slowing down collaborative development.

And because Webflow is a closed SaaS solution, you don’t get the benefits of version control. While you can roll back to previous backups, there’s no way to see what exactly changed between versions—making bug tracking or collaboration trickier.

Conclusion

Webflow might be fantastic tool for simple websites, landing pages, or projects where speed and visual control are the top priority. But for more complex, custom, or highly structured sites, it quickly hits its limits.

In our case, Webflow may still be a good option for lightweight landing pages or smaller sites. But for larger projects (especially those involving custom design systems, complex content structures, or multilingual support) it likely makes more sense to spin up an instance using our TYPO3 Composer Template. With TYPO3, we maintain full flexibility, scalability, and control, which better aligns with the demands of our typical projects.

Misc Dev Stuff

build(node):

We have a new scope in our conventionalcommit.json, pnpm was ditched and node freshly introduced and should be used from now on.

Voting

We as a team should decide if we prefer the inline or tag based style in Fluid templates. When we settled the matter, we should inform bynary to have achieve overall consistency. The result of our voting was: Eddy will check if we already did a voting and if not, will start a new one in our shared slack channel.

Snapshot versioning

Sebo shared some experiences with the versioning of ddev snapshots. These are the main takeaway points:

• good idea, but not working out because of privacy restrictions (e.g. customer data in snapshots on github)-
• we should create a system for our file server to store the recent database snapshots project wise here.

Dungeon Pick

TL;DR: MCP is an API to provide tools and context to a LLM.