The hardest part of a module is flexibility

DRY is one of the core principles of software engineering. Every self-respecting developer wants to package recurring functionality into a module: solve the problem once, reuse it everywhere.

But every project comes with its own particular requirements. That's why the hardest part of building a module isn't the functionality. The hardest part is flexibility: making the module work not just for its author, but for a thousand other projects — each wanting something slightly different.

An anti-example: Serverpod modules.

Serverpod ships ready-made modules for authentication and chat. Looks like a gift: plug one in and the project gets login and a messenger out of the box. Exactly what every "batteries included" framework promises.

Now the reality. The models of these modules live inside the module. The user is their UserInfo, the message is their model, the tables are their tables. For a demo it's all wonderful. But a real product always needs more: an extra field on the user, a custom verification flow, attachments in messages, custom channel permissions. And there's the wall: someone else's model can't be extended. Two options — bolt parallel tables on with joins, or fork the module. And a fork is forever: it has to be dragged through every framework update. Maintenance hell, no exaggeration.

This is not a complaint about Serverpod — it's an excellent foundation, and DartWay is built on top of it. It's the trap almost every "ready-made module" falls into: the more functionality is baked into someone else's models, the faster the tool turns from an accelerator into a brake. And the wall doesn't show up on installation day — it shows up a month later, when redoing things is already expensive.

DartWay is designed around the opposite principle: the framework must not own the application's models.

Authentication: the entire flow is ready — phone number, one-time code, sessions that survive restarts. But the user is the application's own UserProfile model, in the application's database, with whatever fields the domain needs: roles, avatar, anything. Adding a field = adding a field. Not a fork.

Hence the DartWay formula: tools should take away the routine without taking away flexibility. All the hard parts — authentication, permissions, realtime, CRUD — are solved once, properly. But every model stays the application's model, all the logic stays the application's logic, and at no point is there a door marked "beyond this, fork only."

In a few days DartWay lands on pub.dev — and this claim becomes something anyone can test on their own project.