Welike — community directories, verified by people

What Welike is

Welike is a family of community-driven directories of trusted local businesses, built and operated by InnovaTech Group. Each city has its own directory: members and vendors are verified by a person before they appear, and which businesses rise is decided by public voting from the community rather than by advertising spend. Welike.CapeTown is the first to launch, with Welike.Durban and Welike.Joburg to follow.

The problem it addresses

Finding a reliable local trade or service in a South African city is still largely a WhatsApp group question. The directories that exist are either scraped aggregations nobody maintains, or pay-to-rank listings where position reflects budget rather than quality. Both fail the same test: a listing tells you a business exists, not whether it is any good or whether it still trades.

Welike takes the opposite approach on both counts. Verification is human. A person checks that a member or vendor is real and trading before the listing goes live, which is slower and more expensive than scraping and is the entire point. Ranking is communal. Standing comes from public voting by the people who actually used the business, not from a placement fee — so a small operator with genuine local regard outranks a larger one with a marketing budget.

From WeLike Hub to per-city directories

Welike succeeds the original WeLike Hub, and the change worth explaining is structural rather than cosmetic. The hub was one national destination trying to serve every city at once. Local discovery does not work that way: the relevant set of businesses, the trusted names and the vocabulary are all city-specific, and one national ranking dilutes all of it.

So the hub became per-city directories, each with its own hostname, its own community and its own content. That decision drove the architecture, and it is why this page is on an enterprise integration site rather than only on a consumer one.

What building it required

Running several city directories as separate consumer brands is a multi-tenancy problem before it is a content problem, and the engineering behind it is the same work our enterprise clients pay for.

Per-brand host resolution. Each directory answers on its own hostname, resolving to its own brand configuration — theme, content, SEO settings and structured data — from one deployment. Adding a city is a configuration record, not a new platform.

Isolation with shared operations. Cities share infrastructure, deployment pipeline and monitoring while keeping their data and their public identity separate. That is the same pattern an enterprise needs when one platform serves several business units or countries.

Verification workflow. Human verification only scales with tooling: a queue, an audit trail of who verified what and when, and the ability to revisit a listing when its status changes. This is ordinary enterprise workflow engineering pointed at a consumer product.

Vote integrity. Public voting attracts manipulation the moment it matters commercially. Rate limiting, duplicate detection and an auditable record of vote events are requirements, not refinements — and the event-driven patterns behind them are the ones we deploy for client integrations.

Discovery for engines and assistants. Each directory serves its own sitemap, robots directives, structured data and llms.txt, because a city directory that generative engines cannot read is invisible in exactly the queries it exists to answer.

What it proves for an enterprise buyer

The point of describing this on our own site is not to sell you a directory listing. It is that the multi-brand, multi-tenant architecture Welike runs on is the same architecture an enterprise needs when one platform serves several markets, brands or subsidiaries — and we run it in production, with our own uptime at stake, rather than proposing it from a whitepaper.