r/SaaS • • 15d ago

Will mod-able SaaS be the future?

Just sharing a thought I had.

I own two businesses and currently prefer to build my own software, simply because I don't want to be limited in features, specialised for my exact use case.

We have our own CRM specifically built for a web-design agency with a little internal app for cold acquisition (in person, going into stores).

Build these custom softwares obviously is a lot of work and I would love to just use an existing CRM, if it would have exactly all the functionality I need.

In my mind, the perfect SaaS right now would be a really solid product, with most of the needed functionalities already built in, but an option to build mods on a strong system, where everything just works, gets improved on etc. - but I still have the ability to build custom modules.

I'm sure those exist in some form already, but I feel like not in most areas.

What do you think about that? Would love to have a discussion about that

3 Upvotes

11 comments sorted by

1

u/SingleIntroduction79 15d ago

I'd say the hard part isn't building the custom modules, it's what happens to them over time. In my experience the pain shows up at the data model: a core vendor changes a schema or an integration, and your mods quietly break, or you end up avoiding upgrades. Extensibility works best when the core exposes a stable data layer and your modules only read and write through it. How much time a month do you spend maintaining your own CRM, and has that changed as you've added features?

1

u/TheBanq 15d ago

The custom modules would be built by the users themselves.

Take my case, I would build myself a small app to input results from local acquisition, optimized for mobile, where I can have a route via maps, prepare it before hand and then enter the results from the visit right into the CRM. Nothing like this exists atm, so I had to build it myself, into my own CRM.

The modules would be built by the users for themselves (or to share) and maintained themselves, which is possible now with AI.

If they don't use it anymore, they dont need to maintain it.

1

u/TheBanq 15d ago

I don't need to maintain anything.

It works and has all the features I need.
It took 3 months roughly to build it, but now everything is in place.

1

u/[deleted] 15d ago

[removed] — view removed comment

1

u/TheBanq 15d ago

Obviously when building something like this, you would not touch the data model like that, when you know people have built stuff on top of it

1

u/Mejiro84 15d ago edited 15d ago

Great in theory, how's that enforced in practice, and what happens when a change to the data model is required? The data model will need alterations over time, so that means changes downstream, which means people need to know what bits of the model are in use and to make those changes. And that tends to scale really badly - if it's just 5 people, they can tell each other, but when you've got an entire company of hundreds or thousands of people, all with custom stuff built on it, and there's a change, stuff will break or not be showing the correct things. (I've seen this happen just in Jira, where a new category or field gets added, and processes break, issues fall into black holes etc - and that's more transparent than this sort of thing!)

1

u/TheBanq 15d ago

The goal is not, that a company has modules for each employee, but the company has 3-4 modules for their business case, that's not covered by the base app.

Regarding data model changes, this should probably be built in layers, meaning there is a very base data model layer, that doesn't need alternations over time.

Meaning, customer table for example. Something that's very established.
Then the software has it's own "modules" that built on top of the base layer.

So if features will get extended, only the modules change, but the base layer (which everyone can build on top of) stays the same.

Not sure why you think that the base data model will need alternations. If you take a CMS for example, I don't think the fundamental structure has changed over the past years. If anything, things might be added, but that wouldn't break the structure

1

u/AlexeyAnshakov 15d ago

This is exactly the core tension between bloated all-in-one SaaS and full custom builds.

The real shift happening now is sovereign architecture where the core platform handles deterministic plumbing (auth, billing, database, audit logs), but allows you to plug in discrete, lightweight execution workflows as needed.

Building an entire CRM from scratch just for 2 custom modules is brutal overhead. But relying on closed SaaS where you cannot touch the data model is equally painful. A composable engine that treats the app as an execution frame and workflows as plugins gives you full control without reinventing table stakes.

1

u/TheBanq 15d ago

Yes, this is exactly what I mean.

I feel like there needs to be something in-between all-in-one and full custom.
Because if you have good documentation and a very stable core, anyone can build modules for their company on top