Do you build your own community features — or rely solely on standard platform tools?

Thomas - I've worked on several large communities and was always frustrated that simple tasks required installing a plugin or raising a support ticket only to get vague answers from support staff.

Backin 2015, I was running an engineers community - and we wanted to conduct a quiz. All we wanted was something super simple: just a question, 4 options and 1 correct answer with 'fastest finger first'. Our vendor said they don't support it and didn't suggest any alternative. We had to hire a freelancer to build it for us. But every time we encountered a bug, we had to run after the freelancer and that was definitely not a good experience.

Community managers aren't exposed to the tech side and many can't code. I am a developer who's spent over 1.5 decades building communities and know how painful it is to rely on external development agency.

...TBH, it's one of the reasons I built Jatra. It start as a software that I wanted for myself.

PS: Most of the community platforms are built by people who have never built a community beyond Slack or Discord. They were never exposed to the frustrations of a community manager - and it reflects in their software.

I work inside a pretty large org and we do have a team that builds custom features. Our community setup is a bit messy and grown over time, so nothing is straight.

If you rely only on the platform tools, you get speed in the first months. But you hit ceilings sooner than you think. The platform ends up shaping how members behave. Not you. The moment you try to push a workflow the platform never had in mind, everything starts to feel awkward. Members feel it too.

We use a layered approach now.

First is the platform. We let it handle all the generic stuff. Posts, replies, basic moderation. No point touching any of that because every platform is already optimized for the basics.

Second is where we build our add ons. Things we actually need. For example, our onboarding flow is fully custom and changes based on member pricing tier. We have our own internal dashboard because the built in analytics never told us anything useful. Right now we are also testing some AI tools for our mods because they were drowning in flags.

The third layer is the one I wish someone warned us about. Do not touch the skeleton of the platform. We customised the core years ago and we are still paying the price. Only two engineers understand what was changed. Standard plugins break. Integrations break. Even tiny upgrades become a whole project. It also creates constant fights between our community team and management because nobody wants to own the mess.

So my honest advice is this. Build custom stuff only when it changes real business outcomes. Everything else is just tech debt waiting to show up.

Hope that helps a bit.

@moni - could you share an example of a feature that you built and the business outcome associated with it?

Kaustubh Thanks for sharing that — it actually hits quite close to home.

I’m not technical myself, and the IT firm I’m working with has been great so far. They’re flexible and helpful — the only real limitation is my budget. But I definitely recognise the situations you describe. We also looked for existing solutions in the beginning, but nothing really fit because the concept I’m building has several layers that most platforms don’t combine.

I’m building a broad family platform with equal focus on the past, the present, and the future:

Past: a completely new take on genealogy that solves several of the big problems in that industry

Present: tools for organising everyday family life (kind of like Cozi, but integrated into everything else)

Future: ways for families and individuals to preserve their own stories for the next generations

And in the middle of all that sits the family community — where every family gets their own community, not just one big shared one. That alone made it difficult to use any existing community solution “as is”.

And because I’m not technical, it also means that every feature needs to be built for me — and if something doesn’t hit the mark or a bug shows up, I can’t jump in and fix it myself. So having a place to get sparring or hear how others solve things is incredibly valuable.

A lot of people have recommended finding a tech co-founder or at least someone who codes — and that’s probably the direction I’ll take once the first version of the platform is done.

Really appreciate your perspective — it’s rare to hear from someone who has actually built communities and understands the technology behind them.

Thanks a lot for sharing this, Monica — it really does help.

I’m not a technical person myself, and reading your breakdown actually clarified several things I’ve been worrying about without knowing the right words for it. Especially the part about “the platform shaping how members behave, not you” — that hits exactly the problem I kept running into when looking for existing solutions.

The concept I’m building has a community layer, but it’s only one part of a much bigger platform with features around genealogy, family organisation and long-term legacy preservation. Because every family gets their own private community space, most off-the-shelf tools didn’t quite fit, so we ended up needing to build rather than adapt.

Your point about not touching the skeleton is something I’m going to take to heart. As a non-tech founder, the idea of creating invisible tech debt I can’t even see terrifies me a little. The IT firm I’m working with has been great so far, but long-term maintainability is definitely one of my blind spots — so hearing your experience is incredibly valuable.

And the layered approach you described makes a lot of sense. It gives me a framework I can actually use to think about how much we customise now, and where to stop.

Really appreciate you taking the time to explain it this clearly