Why a Property Developer's Concierge App Became a Social Feed Instead of a Directory

Property developers building premium residential blocks tend to arrive at the same idea. Give residents an app. Make everything easy. Let them report maintenance issues, check fire procedures, find the recycling point, browse local recommendations, all from their phone. The concierge becomes a digital service desk, and the friction disappears. The logic is clean, and it is almost entirely wrong.

The product tried to solve two problems at once, and in doing so, solved neither particularly well.

We worked on exactly this kind of project with a property developer building high-end apartments. The brief was straightforward: a single app that handled building management and built a sense of community among residents. On paper, those two goals seemed complementary. A well-run building where people felt connected to their neighbours. What could be at odds about that?

What we found, through focus groups and some deliberately unconventional research choices, was that those goals were not complementary at all. They were pulling in opposite directions. And resolving that tension required us to rethink what the app was actually for, who it should serve, and what a concierge is really worth.

The Original Brief: One App to Do Everything

The client came to us with a clear picture of what they wanted. Residents in their development would download the app on move-in day and immediately have access to everything they needed: maintenance request forms, recycling and waste information, emergency procedures, local area guides, and a directory of building services. The concierge team would field fewer repetitive questions. Residents would feel looked after without having to knock on anyone's door or wait at a desk.

Alongside all of that, the client wanted community. They wanted residents to feel like neighbours rather than strangers sharing an address. The app, they reasoned, would create that too. A shared digital space where people could connect, see what was happening in the building, and get to know each other.

The instinct behind both goals was good. High-rise developments do generate a particular kind of loneliness. People can live on the same floor for two years without learning each other's names. And drowning the concierge team in repetitive queries about bin collection days is a waste of everyone's time. But packaging the solution to both problems inside a single product, without examining whether the two solutions were compatible, was where the brief started to unravel.

Why the Two Goals Were Pulling Against Each Other

A utility product and a community product operate on different psychological principles. A utility product succeeds when it removes the need for human interaction. You find the answer, you solve the problem, you close the app. Friction goes down, effort goes down, satisfaction goes up. The ideal utility app is one you barely notice using.

A community product succeeds when it generates human interaction. You post something, someone replies, you learn something about your neighbour, a connection forms. The ideal community product is one that draws you in and keeps you present, because the value is in the exchange itself.

The client's brief was asking the same app to do both. To remove the need for human contact in one breath and to foster human connection in the next. Those two aims were working against each other in a way that no amount of good interface design could fix. If the app answered every question a resident might want to ask the concierge, the concierge became unnecessary. And if the concierge became unnecessary, the app had removed one of the most natural points of human contact in the building. We needed to push back before we wrote a single line of design specification.

Recruiting the Wrong Users on Purpose

To understand what community actually feels like and where it comes from, we ran focus groups. The target audience for the development was high-net-worth individuals: busy professionals, people who valued privacy, residents who had chosen a managed building partly because they did not want to deal with the administrative weight of home ownership. They were the right people to talk to about utility. They were the wrong people to talk to about community.

So we brought in a second group: people living in social housing. They would never be customers for this development. That was the point.

What we were trying to design into the product was a quality these participants already had in abundance. A genuine sense of community, belonging, openness, and neighbourliness. In high-rise developments, that quality is typically absent. People do not know each other's names. They do not know who is a nurse and who is a musician and who has three dogs. The social housing participants did know those things about their neighbours, and that familiarity was exactly the thing we needed to understand.

The people who would never use the product showed us what the product needed to become.

Recruiting outside your target audience is a research decision that most product teams resist. The instinct is to focus on the people who will actually buy. But when what you are trying to build is a quality rather than a feature, you sometimes have to find the people who already possess that quality and learn from how they live.

What Social Housing Residents Revealed That High-Net-Worth Residents Could Not

The social housing focus groups produced a finding that shifted everything. What we found was that the participants were having meaningful, deeper conversations with each other rather than superficial ones. Not talking about the weather or commenting on the lifts being out. Talking about their children, their work, their worries, their interests. That depth was what had built the community feeling we were trying to recreate.

The high-net-worth participants, by contrast, had very little of this. They were polite. They were self-sufficient. They were not unkind to their neighbours. But they had not accumulated the kind of personal knowledge about each other that generates real belonging. They could not tell you whether the person two doors down had a cat or a daughter or a passion for cycling.

This was not a character failing. It was a design problem. Nothing in their living environment was creating the conditions for those conversations to happen. And the app, as originally specified, would have made it worse. Every interaction it handled digitally was an interaction that could no longer produce a moment of human connection.

When recruiting research participants, ask what quality the product needs to embody rather than just who the product will serve. The people who already live that quality often have more to teach you than the people who will eventually buy.

The Mechanism Behind Community: Accumulated Personal Knowledge

The social housing sessions pointed to something specific about how community actually forms. A sense of belonging does not arrive suddenly. It builds through accumulation. You learn a neighbour's name. Then you learn they work nights. Then you learn they have a daughter who visits on Sundays. Each piece of information adds to a picture, and the picture builds into familiarity, and familiarity builds into the feeling that you belong somewhere and that someone there knows who you are.

Simon's observation from those sessions was direct: the sense of community comes from the familiarity that people have with each other, and the sense of belonging emerges naturally once you start surfacing those data points. You do not manufacture community by giving people a forum. You create the conditions for the conversations that produce personal knowledge, and the community follows.

This shaped the whole redesign. The question stopped being "how do we give residents more features" and became "how do we create more moments where people learn something real about each other." Automate the transactional. Protect the personal. Make the app handle maintenance requests so that the concierge has time to ask a resident how the move went, and to tell them something about themselves in return.

When the goal is community, design for the conversations that produce personal knowledge between people, rather than the features that let them avoid each other more efficiently.

Pushing Back on the Brief: Protecting the Human Role of the Concierge

Part of the original brief was explicit: give everyone in the app access to everything so they would not need to speak to the concierge. The logic was efficiency. The concierge would be freed from repetitive questions. Residents would be empowered to self-serve.

We pushed back. Not because self-service is bad, but because this brief was based on a misreading of what a concierge in a premium residential development actually provides. The concierge is, above all, a human presence in the building. They are a reason for residents to pass through the lobby and exchange a few words. They know the residents' names, and they remember the details. That accumulation of personal knowledge, held and shared by the concierge, is part of what makes a building feel like a home rather than a hotel.

Digitising the concierge out of existence would have removed all of that. The residents would have had faster access to the recycling schedule and far less reason to feel connected to anyone. We argued instead for a clearer division: the app handles the mundane and transactional, while the concierge is protected as a relationship worth having. The brief changed.

Giving the Concierge a Personality Inside the App

Once we had established that the concierge was a human relationship worth cultivating rather than a service function worth automating, the next question was how the app could actively support that relationship rather than bypass it.

The answer was to give each concierge a profile within the app that went beyond their name and shift times. The profile listed personal conversation topics, things like football, or motorsport, or a particular TV series, with an explicit invitation to residents to bring those subjects up when they saw the concierge in person. The intent was to model and encourage the kind of human, personal exchanges that build familiarity.

This was a small design decision with a larger psychological function. By surfacing the concierge's interests inside the app, we were signalling to residents that this person was worth talking to, and giving them a ready-made starting point for a conversation they might otherwise have avoided. It also gave the concierge a reason to be curious about residents in return. The app was not replacing the social layer. It was priming it.

• Each concierge profile listed two or three genuine personal interests
• An explicit prompt invited residents to mention those topics in person
• The framing positioned the concierge as a person to know, not a service to use
• Residents could also share their own interests, creating a mutual starting point

From Directory to Social Feed: What the Product Became

The original product was, in essence, a building directory with a maintenance logger attached. You opened it to find information or to report a problem. It was passive, reference-based, and entirely task-oriented. You would not open it for any other reason.

The redesigned product put a social feed at the heart of the experience. Residents could post content, ask neighbours for help with something, share recommendations, and follow updates from the concierge team and from local charities and organisations that had a connection to the building. Building management features were still there, but they sat as a secondary layer rather than the core experience.

The shift was from a utility product to something closer to a social network, with the social layer doing the work of building community and the utility layer handling the transactional tasks that had originally been the whole point. What mattered about this restructure was what it signalled to residents on first use. Opening the app and seeing a social feed told them something different about the product's purpose than opening it and seeing a directory. It told them the building was a social environment, and that their neighbours were worth paying attention to.

Onboarding Into an Emotional Minefield: Rethinking Information Timing

Most building management apps do the same thing at onboarding: give the user everything at once. The full directory appears, all the procedures, all the guides, all the contacts, all of it, right there on day one. From an information architecture perspective, this is logical. The user might need any of this, so make all of it available.

From an emotional design perspective, it is a poor decision. Moving home is one of the most emotionally loaded events in ordinary life. The range of circumstances that put someone in a new flat on a given day is wide. One person has just bought their first property and is giddy with it. Another is moving in alone after a separation. Another has relocated for a job they are not sure about yet. These people are not in the same emotional state, and none of them are in a state that is receptive to a large volume of new information.

What we implemented instead was a system that drip-fed information over time, matched to when a resident would actually need it. Recycling information a couple of days after move-in. Local area recommendations over the first weekend. Emergency procedures early, because those carry genuine urgency, but the rest paced out to reduce the sense of overwhelm rather than add to it.

Treat the timing of information as an emotional design decision. A resident who has just moved does not need the full directory on day one. They need the right thing at the right moment, and those two things are rarely the same.

The Dynamic Notification System and Why Fixed Delays Were Not Enough

When we started designing the notification schedule, the obvious approach was a fixed timeline. Send recycling information two days after move-in. Send local recommendations on day five. Send the building events calendar at the end of the first week. Tidy, predictable, and not good enough.

The problem with fixed delays is that they ignore actual behaviour. Someone who arrives at the property in the morning is likely to start unpacking that day. Someone who arrives in the evening will probably leave it until the next day. A single person moving into a one-bedroom flat will finish unpacking faster than a couple moving into a three-bedroom apartment with children. These differences matter for when information is useful and when it is just noise.

So we built a dynamic system. Notification timing was based on the time of day the resident arrived and the number of occupants in the flat. These two variables gave us a reasonable model of when the resident would move through different settling-in stages, and the system sent information to match those stages rather than a fixed calendar. The result felt more considered and more personal, because it was responding to the resident's actual situation rather than treating every move-in as identical.

What This Means for Any Product Trying to Build Community

The concierge app project is a story about what happens when a product brief conflates two things that look similar and behave very differently. A utility and a community are both valuable. They are not built the same way, and trying to build both simultaneously in a single product, without examining the tension between them, usually produces something that does neither job well.

The grassroots football app we worked on separately illustrated the same failure mode from a different angle. That client kept insisting individual features needed to be more intuitive and kept comparing them to best-in-class single-purpose competitors. The real problem was that the product was trying to do too many things at once, which is why those features existed across several separate apps in the first place. Despite our best efforts to create something cohesive and emotionally grounded, the result was overly complex and not fit for its audience or core purpose. The lesson from both projects is the same.

Products that successfully build community tend to share a few characteristics. They are designed around the conversations that produce personal knowledge, rather than the features that let people avoid those conversations. They treat the human contacts in the product as assets to protect rather than costs to reduce. And they sequence information and interaction to match the emotional state of the user rather than the logical completeness of a content map.

Community is built through accumulated familiarity, not through shared access to a directory.

That last point applies well beyond residential apps. Any product in the wellness, hospitality, or fitness space that wants to generate belonging among its users faces the same design problem. The question to ask is not "what information do users need" but "what conversations do users need to have, and how does this product create the conditions for them."

Conclusion

The concierge app started as a directory and became a social feed. That shift was not a cosmetic change. It was the result of focus groups that included people who would never be customers, a decision to push back on a brief that was asking the product to do contradictory things, and a series of design choices that treated human interaction as something to cultivate rather than to replace.

The social housing residents who sat in our focus groups did not give us feature ideas. They gave us something more useful: a clear picture of what community actually feels like and where it comes from. Familiarity built through accumulated personal knowledge. Conversations that go beyond the surface. A concierge who knows your name and who is worth knowing in return.

The app that came out of that process handled bin collection days and maintenance requests, and it did those things well. But the experience it was actually selling was something harder to specify: the feeling that you live somewhere, rather than just at somewhere. That distinction is the whole job. Getting there required ignoring the brief long enough to understand what the brief was actually asking for, and then redesigning almost everything.

If you are building a product that needs to create community rather than just serve users, the questions we worked through on this project are worth sitting with before the first wireframe goes up. Let's talk about your product strategy.

Frequently Asked Questions