The context
A community organisation runs on tools that are not its own: a chat group where messages get lost, a social page not everyone follows, a member list only one person knows how to maintain. The need is always the same — a single place that carries the organisation’s name — and the budget never stretches to a bespoke build.
App Community Suite is the answer we built: a single application base, branded into an app of its own for each organisation.
The challenge
The trap in this kind of product is well known: from the second customer on, the base forks. Each organisation asks for one adjustment, it gets made “just for them”, and six months later there are four different applications to fix four times over. The product dies before it has been sold.
Three constraints sit on top of that.
The organisation must be the visible publisher. An organisation putting an app in its members’ hands does not want its supplier’s name on the home screen. The app carries its name, its logo, its colours, and its own store listing.
A visitor has to be able to look without an account. An app whose content sits entirely behind an invitation cannot be promoted: it cannot be shared, it cannot be indexed, and it gets rejected in review for want of visible content.
The organisation decides what leaves the members’ circle. Not as a global setting but item by item — this event yes, this gallery no — by volunteers who have had no training.
What we did
- A Django back end carrying members, events, the gallery, messaging, votes, polls, finances, moderation and notifications, exposed as one REST API shared by every branded build.
- A strict separation between product code and per-customer branding. The product lives on a single branch; each organisation owns one configuration file and one image folder. A fix written once reaches every branded build by rebase, never by copy-paste.
- A single Flutter application for iOS and Android, whose visual identity is read from configuration rather than written into the screens.
- Server-rendered public pages, so the calendar, the news and the gallery are readable — and indexable — without an account, with a join flow that brings the visitor back to an invitation approved by an officer.
- A web admin tool with four role levels and a moderation queue, because a space where members publish needs a place where someone decides.
The outcome
The first organisation is live: its app is published under its own name and its members use it daily. Two further branded builds are prepared on the same base.
The lesson of this product fits in one sentence: the hard part is not writing the second application, it is the discipline that forbids writing it. Anything that looks like a customer-specific adjustment is first examined as a badly phrased generic need — and most of the time, that is exactly what it is.
