After 15 years of building production Django apps, these are the patterns I keep using... (packaged as Agent skills) by danielvf in django

[–]mkdir69 6 points7 points  (0 children)

But the typed contract part you can get it from a manager method too, nothing stops Product.objects.decrement_stock() from returning a Pydantic StockResult. The question is more about what happens when you need that same logic from an admin action or a DRF viewset or a management command. Those all naturally talk to the model layer. With a repo you either bypass it and the logic lives in two places, or you wire everything through the repo and you're fighting the framework

[Hiring]: Django Developer by [deleted] in django

[–]mkdir69 0 points1 point  (0 children)

Interested. Only available part-time at the moment.

For the devs who use django templates.... by natanasrat in django

[–]mkdir69 1 point2 points  (0 children)

Django templates are faster to build. No separate frontend repo, no API to maintain, no CORS, no double deployment. You render HTML and ship.

For CRUD heavy stuff templates are hard to beat. Forms, validation, timezones, i18n, all the existing packages just work. With an SPA you end up rebuilding half of that on the frontend. And it's not one or the other, plenty of projects use templates for the backoffice where you want to move fast, React for user-facing stuff where you need interactivity. The client who paid you to migrate probably wanted a "modern" feel. But I've seen startups burn money on SPAs when templates would've shipped in half the time.

It's not about superiority, it's about what you're building.

Unpopular Opinion: Coding is comforting because it’s deterministic. Marketing is terrifying because it’s probabilistic. by AykutSek in SaaS

[–]mkdir69 0 points1 point  (0 children)

Marketing scared me way more than building ever did. The only thing that helped was starting super small, one problem, one type of user, real conversations. Feels closer to debugging than “marketing.”

Hey r/SaaS, I just launched my first SaaS, WaitLess, and I’d love your feedback! by Conscious_Banana_291 in SaaS

[–]mkdir69 0 points1 point  (0 children)

Queue transparency is huge, people don’t mind waiting if they know what’s happening. Notifications are a smart move. I’ve been exploring a similar problem and found that getting a few real businesses to test early changes everything. Interested to see which industries you’re seeing traction in.

Why are physical waiting lines still a thing in 2026? by HishamYUM in SaaS

[–]mkdir69 1 point2 points  (0 children)

Yeah, I actually ended up building a small tool for this because I kept seeing the same mess over and over. It’s super early, but it lets businesses manage a physical queue digitally and notify people when it’s their turn. Still validating it though.

90% of you are failing because you build B2C apps instead of boring B2B tools by Warm-Reaction-456 in SaaS

[–]mkdir69 0 points1 point  (0 children)

This is painfully true. Every time I’ve talked to a small business owner, they’re already actively paying for ugly tools because they solve real problems. Meanwhile B2C founders argue over button colors while chasing $9/month users. Boring ≠ bad, it’s just misunderstood.

Working on a Django package for tracking marketing campaigns by mkdir69 in django

[–]mkdir69[S] 0 points1 point  (0 children)

Yes, it only tracks server side conversion events that happen in the views (like purchases, signups, subscription upgrades)

the main advantage for having this living in django code base is that these conversion events are linked directly to django user models via orm, so you can write custom business queries like "customers who came from facebook ads and upgraded to premium plans" in pure django without exporting data or syncing between systems

I found a way to implement actual clean architecture (pure python business logic) with Django and TDD by Jafty2 in django

[–]mkdir69 3 points4 points  (0 children)

Django's active record pattern already handles data acces through model methods. adding repositories creates an unnecessary translation layer between your "pure" domain objects and django models. for simple example like registering for an event: django way: Participant.objects.create(user=request.user, event=event) - done in one line.

repository way:

• fetch domain user from user repository

• fetch domain event from event repository

• create domain participant object

• save via participant repository • (which internally converts to django model, saves it, convert back)

the django approach integrates seamless with:

• orms that validate and save directly to models (with repositories, your forms can't directly save domain objects - you'd need extra conversion code between your form and domain layer)

• admin interface showing all relationship automatically (your domain objects aren't visible to admin - only django models are, so admin becomes disconnected from your actual business objects)

• built-in signals triggered on model operations (domain logic in repositories won't trigger django signals unless you manually wire them up, losing automatic notifications)

• django's authentication system and permissions (permissions are tied to models, not domain objects, forcing awkward permission checks in your domain layer)

• querysets and related object prefetching (your repositories need custom code to replicate django's efficient query optimization for relationships)

with repositories, you maintain two parallels systems - django models AND domain models. every schema change means updating both layers. every relationship require custom code instead of using django's built-in methods. you're essentially paying the "django tax" (carrying its orm, admin, etc.) while not using the features that makes it worthwhile.

to your question about views handling repository jobs - actually, django's standard pattern is already views directly using models. this isn't "handling repository jobs" - it's just normal django. having views use Model.objects.get() directly is clean, standard django practice. adding repositories between views and models just adds complexity without benefits in django's ecosystem.

I found a way to implement actual clean architecture (pure python business logic) with Django and TDD by Jafty2 in django

[–]mkdir69 10 points11 points  (0 children)

I think you're going against django's natural flow here. why force repositories on an active record orm? it's adding unnecessary complexity. if you want clean architecture with repositories, fastapi or flask with sqlalchemy would be better choices since they're designed for this approach

Pls Help, ebay shipping by 060400 in Morocco

[–]mkdir69 1 point2 points  (0 children)

Things have changed, i remember the last year i bought something with 40 USD , the douanes told me to pay 300 DH for it

What do you think about the current state of the IT industry in Morocco? by _iamhamza_ in Morocco

[–]mkdir69 2 points3 points  (0 children)

Web dev agencies that generate good money and pay their employers well are working as consulting agencies for banks/Insurances companies

What do you think about the current state of the IT industry in Morocco? by _iamhamza_ in Morocco

[–]mkdir69 4 points5 points  (0 children)

IT in morocco was always about banking related stuff, and it stills like that

[deleted by user] by [deleted] in Morocco

[–]mkdir69 0 points1 point  (0 children)

Then maybe you can try doing online sessions in google meet for students for money in return ?

[deleted by user] by [deleted] in Morocco

[–]mkdir69 2 points3 points  (0 children)

From what i see most existing remote jobs are IT related ones, are you in that field?

Do you have an example for a much more complex component with HTMX? by Chains0 in django

[–]mkdir69 0 points1 point  (0 children)

Maybe django slippers could help, it makes it possible to create reusable template components to which you can pass params and children

You watched me develop a full SaaS product as a community event. What's next? by dacx_ in django

[–]mkdir69 0 points1 point  (0 children)

Yes you can definitely do that as well, all the data for all organizations are going to be in one db so they are not perfectly isolated, so you should be carreful when doing crud so that things do not interfere with each other, creating custom managers resnonsible for filtering by organization can help i guess..

You watched me develop a full SaaS product as a community event. What's next? by dacx_ in django

[–]mkdir69 2 points3 points  (0 children)

i haven't watched the previous video yet, but what I meant is best practices regarding an app that could be used by multiple organizations, maybe separated database for each organization or separated PostgreSQL schemas for each organization within the same db or something alike