Cannabivo: Building the International Infrastructure for Cannabis Social Clubs

The gap we saw in 2024

How a "better directory for Germany and Spain" turned into a production platform spanning ten countries, eighteen languages, and a quarter-million pages — and the bleeding-edge engineering holding it up.

A directory can be more than a list. Make it legal, multilingual, verified, private, and technically serious, and it stops being a list at all. It becomes infrastructure.

"Cannabis social clubs, coffeeshops & smoking lounges — one international directory & news hub." That is our one-line promise, and we kept it plain on purpose. Cannabivo is not a consumption campaign, not a marketplace for cannabis, and not one more thin listing site stitched together from copied addresses. It is an international information directory for legal Cannabis Social Clubs, Dutch coffeeshops, and smoking lounges — built so people can Search → Discover → Connect with information that is transparent, current, and available in their own language.

The aim runs deeper than a directory. Cannabivo is becoming infrastructure for the CSC community: private by design, international in scope, community-driven, and live in 18 languages. The platform already serves 225,792 pages, 211,397 geo-location pages, and 13,573 club listings across 10 countries. On top of that sit a deep cannabis wiki, education and prevention pages, a news system, automated club updates, a community forum, and an AI support agent wired to real tools. Underneath runs a fully in-house, framework-free architecture: modern web standards, persistent PHP workers, HTTP/3, the strictest static analysis we could configure, first-party analytics, and a single typed PHP → TypeScript → Dart contract shared by web and mobile.

This is the long version of that story: where Cannabivo came from, what it is today, and — in detail — how it is built.

Germany's legalization in early 2024 exposed something that had been easy to ignore: the online coverage of Cannabis Social Clubs was nowhere near ready for the reality arriving on schedule. To an experienced web developer, most of what existed looked half-finished — fragmented, incomplete, badly localized, technically dated, and too thin to actually help anyone.

The questions people had were not hard ones. Where are the legal clubs? Which details are current? What does a newcomer need to understand before contacting a club? What is factual, what is stale, and what was simply copied from somewhere else? Too often the answers were scattered across weak listings, machine-translated fragments, and pages that were clearly never built for the community they claimed to serve.

The first idea was modest: a better directory for Germany and Spain. But the closer we looked, the clearer the pattern got. The CSC community did not need another list of venues. It needed a multilingual, legally careful, technically reliable information layer — one that could scale country by country and still stay precise at the level of a city, a region, a single club, an article, an FAQ entry, a language.

Full in-house development began in late summer/autumn 2024. Cannabivo launched in February 2026, in all 18 languages from day one, and has been improved almost daily since. The sequencing is the point: multilingual support was never bolted on after launch. It was poured into the foundation — the database, the URLs, the routing, the SEO layer — from the first commit.

What started as a directory concept grew, accelerated by AI-assisted development, into an international platform covering Argentina, Colombia, Germany, Malta, the Netherlands, South Africa, Spain, Switzerland, Thailand, and Uruguay. Every country's coverage is still a work in progress, and we say so deliberately. But the production scale is already real, and the mid-term goal is not in doubt: cover every country where cannabis is legalized or at least decriminalized, including pilot-program countries such as Switzerland, which is already listed.

What Cannabivo is today

Cannabivo is live in production and actively maintained. The production snapshot verified on 2026-06-13 describes a platform that left prototype territory a long time ago.

None of these are vanity numbers. Each one traces back to a product decision.

A large directory needs geo pages because people search locally. It needs detail pages because every club deserves context, not a single line in a list. It needs multilingual URLs because international users should never be treated as an afterthought. It needs constant upkeep because listings decay the moment nobody tends them. It needs education pages because information quality is the whole point. And it needs a forum because the CSC community is not only a search problem — it is a conversation.

A verified international directory

The directory currently lists 13,573 clubs across 10 countries:

Thailand is the largest share of the database today, and that scale is a genuine strength. Spain, Germany, the Netherlands, Uruguay, Argentina, and the rest each arrive with a different legal context, different local expectations, and different discovery patterns. A serious international directory has to hold all of that complexity at once without collapsing into noise.

Cannabivo presents its listings as verified, and verification is a core promise of the platform — not a label we apply lightly. At this scale, keeping that promise is a matter of systems as much as editorial discipline. We continuously keep listings accurate and up to date: new openings, closures, moved addresses, changed details. The aim is not to freeze a directory in time but to keep it tracking the real world as the real world moves. A directory that goes stale the day it publishes is worse than no directory at all.

Around the listings sits an interactive map with search, a dedicated club search, and a homepage engineered for freshness — recently added clubs, popular cities, per-country hubs, and a live feed of news and club updates.

Wiki, education, and prevention — without ad messaging

A plain listing site can tell you where something is. Cannabivo is built to tell you what it means.

The cannabis wiki holds 106 articles across 9 categories, with deep pieces on botany, history, law, and consumption-related knowledge. It is not a glossary padded out to look substantial; it was researched and written to stand on its own. The education and prevention pages sit beside it — factual, ad-free, and built to support understanding rather than push a product.

That line is not cosmetic. Cannabivo is an information directory. We make no medical claims, and we do not encourage consumption. We build access to structured, multilingual, legal information, and we hold that boundary on purpose, because the credibility of the entire platform rests on it. Both the wiki and the education and safe-use areas will keep growing — more articles, more images, more video.

News, automated updates, and community

The news section is new, and already busy. It pairs researched editorial articles with automated club-update news. At the current production snapshot, Cannabivo carries 15 published editorial articles and 275 automated club-update news entries.

The pairing is deliberate. Editorial articles supply the wider context — policy shifts, legal developments, cultural moments. Automated club-update news exists because a directory is never still: clubs open, details get corrected, addresses change. A living feed lets people see those changes instead of leaving a silent database to mutate underneath them.

There is also a community forum, and it is growing — 1,216 registered users and 170 forum threads so far. The forum is not a bolt-on. CSC culture is local, legal, practical, and social all at once. A directory helps people find information; a community helps them argue it out, compare notes, and learn from each other. Both belong under one roof.

The AI support chat has real tools

The Cannabivo support chat is not a decorative chatbot bolted onto the corner of the page. It is a Cannabivo-trained AI support agent, on the web and in the app, connected to real platform tools instead of left to improvise.

In practice, the agent can:

1. Find a specific Cannabivo page and hand over the real, canonical link — in the user's language, never a hallucinated URL. 2. Search clubs by name, city, region, or proximity, including whether a club is open right now. 3. Answer from the FAQ knowledge base. 4. Open a real support ticket when it cannot help — with a category, a title, and a description — so a human can pick it up.

The difference is the whole point: rather than guessing, the agent works inside defined platform boundaries and returns links and clubs that genuinely exist. It also sharpens on its own as the FAQ grows, because the FAQ system is dynamically maintained and self-improving — every gap we close becomes knowledge the agent can draw on next time. Behind the scenes the chat runs over a WebSocket relay with Redis pub/sub and streaming responses, and the model is configurable per deployment.

The philosophy is plain: AI should take friction out without turning into a black box. If the agent can answer reliably from Cannabivo's own data, it should. If it cannot, it should hand the question to a real support process — not invent an answer to fill the silence.

One platform, eighteen languages

Cannabivo launched in all 18 languages on day one. It was not the easy path. It was the right one.

The site currently runs 225,792 pages, and every one of them exists in all 18 languages. At the database level that is roughly 4 million page-translation rows — a base `pages` table plus 17 per-language tables, verified in perfect sync. The platform also holds 211,397 geo-location pages — cities and regions — each fully translated into all 18 languages.

This is not URL-prefix translation. We do not paste `/de/` in front of an English URL and call it localized. Every language gets its own localized URL slug for every page. For example:

• `/news/2`
• `/de/nachrichten/2`

That structure comes with full `hreflang` support and a genuine right-to-left layout for Arabic. Arabic here is not "English text rendered in Arabic words" — it gets an RTL layout that fits the language, wired through the page, the SEO head, and the UI alike.

The platform is English-first, but never English-only, in spirit or in structure. The full language surface covers English, German, French, Spanish, Italian, Polish, Arabic, Czech, Hindi, Hungarian, Japanese, Korean, Portuguese, Portuguese (Brazil), Russian, Turkish, and Chinese — with Arabic handled right-to-left.

Why does this matter so much? Because the CSC community is not confined to one language, one country, or one legal model. A user in Germany, a club owner in Spain, a reader comparing pilot-program approaches in Switzerland, a traveler checking the legal context in Uruguay — none of them should be forced into an English-only experience to get a straight answer.

Multilingual infrastructure also changes what a club can do. An owner can write a description once, polish it with the AI writing assistant if they like, save it, and translate it into all 18 languages with a single click. That is not just convenience. It is international discoverability that would otherwise be out of reach for a small local club.

Translation is not a feature parked at the edge of Cannabivo. It runs through the database, the URLs, the SEO layer, the UI, and the club-owner workflow.

For clubs: the Club Manager is already shipped

Cannabivo is built for the community, and that community includes the people who actually run the clubs. The Club Manager is already shipped — a complete self-service editor inside the member account, where an owner manages their own listing without needing a shred of technical knowledge.

It is mobile-first, because most club owners do not manage their public presence from behind a desk. They need to fix a detail in a minute, from the phone already in their hand.

The Club Manager covers the practical details that make a listing genuinely useful:

• Description and tagline, with an AI writing assistant to draft and polish
• One-click translation into all 18 languages
• Logo, hero image, and a reorderable gallery, with image cropping
• Opening hours
• Location and a draggable map pin
• Contact details
• Around 11 social-channel fields
• Membership details
• A 22-item amenities picker

Each section saves on its own — no raw JSON, no SEO homework, no image-ratio arithmetic asked of the owner. Ownership is enforced server-side on every save, and the platform never trusts a client-supplied identifier, so one owner can never reach into another's club.

This is where Cannabivo's directory and its multilingual architecture meet the daily reality of running a club. A good listing should not require hiring a web agency. It should not demand that an owner understand SEO, image ratios, translation pipelines, or structured data. The editor exists to make good presentation the default, not the reward for technical skill.

Premium Club Microsites are in the backlog

The next level of this vision is Premium Club Microsites — currently in the backlog, and not yet built.

The idea is simple: every premium, claimed club should be able to claim a polished first-party homepage on its own Cannabivo subdomain.

{club}.cannabivo.com

The standard we want is "stunning by default": curated presets, full SEO in 18 languages, and a site wired to the same listing data rather than a separate system the club has to keep in sync by hand. Update the information once, and both the directory and the microsite reflect the same source of truth.

We are deliberate about tense here. The Club Manager is shipped. Premium Club Microsites are planned vision. Keeping that line sharp is itself part of the product, because credibility is.

Under the hood: why Cannabivo is genuinely bleeding-edge

A platform this large does not feel fast, stay multilingual, protect privacy, and power native apps by accident. Cannabivo is built from scratch, in house, on engineering decisions that are unusually strict for a public directory.

We use the phrase "bleeding-edge" with care. It does not mean chasing whatever library is fashionable this quarter. It means adopting modern standards where they solve a real product problem, then enforcing quality hard enough that the system can keep scaling without quietly rotting from the inside.

Built from scratch, without a web framework core

Cannabivo is a complete in-house build with no web framework core. There is no Laravel or Symfony application foundation underneath it; Symfony shows up only as a handful of discrete libraries, used where that genuinely earns its place.

That decision hands us full control over routing, rendering, caching, localization, contracts, security policy, and runtime behavior. It costs more up front. In return, the platform bends to the product instead of bending the product around a framework's defaults and lifecycle.

The architecture is one codebase, multiple products — a shared core with per-project layers, known internally as the Common/Projects model. This matters because Cannabivo is not one page template stamped out thousands of times. It is a directory, a wiki, an FAQ system, a news system, a support system, a club-owner editor, a community surface, an analytics platform, an automation engine, and a native-app backend at once. The shared core enforces the common rules everywhere; the per-project layers carry product-specific behavior without anyone copy-pasting the platform to get it.

A modern runtime: persistent PHP, HTTP/3, and compression built for speed

The backend runs on PHP 8.5.7 with FrankenPHP in worker mode, and that is a real architectural choice rather than a default. Classic PHP usually means a per-request lifecycle: boot the application, handle one request, tear it all down, do it again. Cannabivo keeps persistent workers warm over a Unix socket instead, so the application is not paying a cold-start tax on every single hit.

The database is MariaDB 12.3.2. The frontend toolchain is TypeScript 7 compiled with the Go-native compiler (`tsgo`) and bundled with Vite 8; Node and TypeScript also run server-side for parts of the system.

At the web-server and edge layer, Cannabivo uses nginx with HTTP/3 (QUIC), TLS 1.3 with 0-RTT, dynamic zstd compression, and pre-compressed brotli static assets, with Cloudflare fronting the public domains. Each piece is there to do a specific job:

• HTTP/3 over QUIC reduces transport friction on modern, lossy mobile networks.
• TLS 1.3 with 0-RTT trims handshake cost when conditions allow it safely.
• zstd gives efficient on-the-fly compression for dynamic responses.
• brotli (static) squeezes pre-built assets as small as they go.
• FrankenPHP worker mode keeps PHP from behaving like a cold script on every request.

There is no single magic trick here. There is a stack of small latency decisions, and they compound.

The instant SPA: Navigation API, View Transitions, and progressive enhancement

The product question is blunt: who enjoys clicking a link and waiting?

Cannabivo behaves like a modern single-page app wherever that improves the experience, while staying server-rendered first. We use the modern Navigation API and the View Transitions API to make page changes feel native — coherent, animated, instant — rather than a full document teardown. Where the browser supports it, moving through Cannabivo feels like using an app.

But this is not a JavaScript-or-nothing architecture. Cannabivo is built on true progressive enhancement. Turn JavaScript off, or open it in a browser without the modern APIs, and the plain server-rendered links still work. That matters for accessibility, for resilience, for SEO, and for plain technical honesty. Rendering starts on the server; interaction only enhances what is already there.

For cached pages, Cannabivo goes further still: a prerendered static HTML cache in four theme variants (auto, dark, light, and a pure-black mode), served directly by nginx, bypassing PHP entirely. A cache hit never wakes the application layer — nginx returns the already-rendered HTML and stamps it as a static hit. The four variants exist because presentation is not one universal shape; prerendering each one keeps the page fast without flattening the design system into a single compromise. They are written once at render time and compressed out-of-band by a filesystem-watching daemon, so the request path never pays for it.

The frontend performance layer also includes:

• Critical CSS inlined and hash-pinned into the Content Security Policy
• AVIF images with explicit dimensions for zero layout shift
• Eager, high-priority loading for the above-the-fold hero; lazy, low-priority loading below it
• Hover and touch prefetch of likely next navigations
• Early Hints as part of the loading strategy

On the common path, Early Hints are Cloudflare-mediated — that is the honest way to describe how most visitors actually encounter them — and a true HTTP 103 is emitted on the dynamic cache-miss path. We do not claim every visitor receives a literal 103 on every network path. We do claim the system is designed around the modern hinting model, right down to a per-page LCP-image preload injected at the edge.

The point worth keeping: performance here is not outsourced to a bundle-size dashboard. It is built into rendering, caching, transport, images, CSS, prefetching, and progressive enhancement — every layer pulling in the same direction.

Multilingual URLs are infrastructure, not decoration

The multilingual layer earns a second mention from the engineering side, because it is one of the hardest things to get right at scale. Cannabivo's localization is not content translation alone. It is localized slugs, synchronized page rows, `hreflang`, and RTL layout, treated as a first-class dimension of the platform rather than a finishing touch.

At 225,792 pages × 18 languages, any weakness stops being cosmetic and turns structural. A missing translation row is not a small typo — it can break SEO, navigation, internal linking, or the user's trust in the whole site. That is why the base `pages` table and the 17 per-language tables are kept in perfect, verified sync, and why club pages, geo pages, wiki articles, FAQ entries, and news all live inside the same international structure instead of a bolt-on translation table off to the side.

Code quality: maximum PHPStan, ultra-strict TypeScript, and rules that enforce policy

Cannabivo runs PHPStan at Level 10 — the maximum — alongside 121 custom static-analysis rules. On the frontend, TypeScript runs in ultra-strict mode with 14 custom lint rules and nine error-level plugins.

This is not about aesthetic purity. It is about making whole classes of mistakes impossible to ship in the first place.

The custom rules are policy, encoded as code. A few real examples:

• `RequireRateLimitOnEveryRouteRule` — an API route without a declared rate limit fails the build. Security posture does not depend on someone remembering a checklist in review.
• `NoRawIdInResponseDtoRule` — external responses must use UUIDs, never raw integer database IDs, so internal identifiers never leak to clients.
• `NoInlineStylesRule` — inline styles are rejected at build time, keeping the strict Content Security Policy enforceable.
• DTO discipline — handlers must accept a typed request DTO and return a typed response DTO; bare arrays are rejected, which is what makes the cross-platform type pipeline below even possible.

The same philosophy runs the length of the codebase: generated contracts cannot be hand-edited, backend and frontend shapes cannot drift apart in silence, and security-sensitive assumptions are checked mechanically wherever a machine can check them. Static analysis is not glamorous work, but it is a large part of why a fast-moving platform can stay credible. We ship near-daily; strict analysis is what lets us move quickly without pretending that "move fast" has to mean "accept chaos."

One typed contract: 1,518 PHP DTOs → 1,518 TypeScript types → 1,518 Dart types

One of the strongest engineering decisions in Cannabivo is the typed API contract.

Backend data shapes are defined once as PHP DTOs and auto-generated into both TypeScript and Dart. The mapping is one-to-one:

1,518 PHP DTOs ↔ 1,518 TypeScript types ↔ 1,518 Dart types

The website and the native apps consume the same generated contract as the backend. When a backend shape changes, the TypeScript and Dart consumers cannot drift off into a parallel reality — the generated files are locked read-only so no human can hand-edit them, and any drift between the source DTOs and the generated types is a build-breaking error, not a runtime surprise discovered by a user.

This matters because Cannabivo is more than a website. Native apps are being built in parallel, and sharing API shapes between web and mobile sidesteps a classic failure mode: the backend evolves, the web team patches one interpretation of it, the mobile app keeps another, and bugs quietly pile up at the seams. We chose the stricter model on purpose — define the source of truth once, generate the platform contracts from it, and turn drift into a build-time problem instead of a user-facing one.

Privacy-first analytics: no Google Analytics, no third-party trackers

Cannabivo uses no Google Analytics and no third-party trackers. In their place we built a fully custom, first-party analytics system — including real-user Core Web Vitals — backed by its own ingestion pipeline and dozens of purpose-built tables for raw events, hourly and daily rollups, and bot-filtered human-only views. Visitor data does not leave Cannabivo for the tech giants.

This is a privacy decision and a product decision at the same time. We still need to know whether pages are genuinely fast in the field, not just on a test bench. We simply decided to measure that ourselves rather than feed our visitors' behavior into someone else's surveillance machinery. A directory for legal CSC information should take privacy seriously, and nobody should have to trade their browsing context for basic functionality.

Bank-grade security, measured and enforced

Cannabivo runs a bank-grade, multi-layer security architecture:

• Content Security Policy with no inline scripts or styles unless individually hash-whitelisted
• Trusted Types to neutralize whole categories of DOM-injection
• Multi-level rate limiting, per IP and per user — with the build-time rule that any route lacking a limit fails to compile
• HMAC request signing on sensitive internal endpoints
• CSRF protection on authenticated, state-changing requests
• HSTS preload
• AI-assisted security testing

The platform scores A+ on the Mozilla Observatory — 135 out of 100 points. That is a confirmed result, and a tier very few websites ever reach.

The CSP deserves a closer look. Plenty of sites advertise a CSP while still allowing broad inline execution underneath it. Cannabivo's posture is tighter: inline scripts and styles are not broadly allowed at all — each one has to be hash-whitelisted — and combined with Trusted Types, that makes whole categories of browser-side injection far harder to pull off. Rate limiting gets the same treatment: not optional middleware, but architecture the build refuses to ship without. The recurring idea is the same throughout — encode the security assumption into the system itself, so it cannot be quietly forgotten.

End-to-end encrypted direct messaging

Cannabivo includes end-to-end encrypted direct messaging with a zero-knowledge server design: the server stores only public keys and opaque ciphertext, never the content of a message.

The encryption is Signal-grade, multi-device, and built on libsodium. The verified primitive set includes:

• X25519 key exchange
• XChaCha20-Poly1305 authenticated encryption
• Ed25519 signatures
• BLAKE2b key derivation
• BIP-39 mnemonic key backup
• a Sender Key scheme for group conversations

The multi-device model is the interesting part. A message is encrypted once with a per-message content key; that key is then wrapped separately for each of the recipient's devices via ephemeral key exchange and fanned out — so the same message can reach a phone, a tablet, and the web without the server ever touching plaintext. The implementation is shared across platforms: on the web, all crypto, key storage, and socket work run off the main thread in a Web Worker with keys held in IndexedDB; in the native apps, the same primitives run through a sodium FFI binding with keys in secure device storage.

We are careful with the terminology. This is Signal-grade, libsodium-based, multi-device E2E encryption. We do not call it "the Signal Protocol," and we do not claim the Double Ratchet or per-message forward secrecy. The strength is still substantial: the server cannot read messages, and the cryptographic model is identical across every client. For a CSC community platform, private communication is not a decorative feature — if messaging exists at all, it has to be designed with a serious privacy boundary from the first line of code.

Native apps: Flutter, offline-first, high-refresh discipline

The native apps are built with Flutter — three apps sharing one common core — over an offline-first local database and the same generated typed contract as the website. State management and the local store are designed for a responsive, offline-capable experience, not a thin wrapper draped over a web view.

Performance discipline is strict, and enforced by custom lint rules: high-refresh, 120fps behavior is the target, with lints that ban the patterns known to cause jank — uncapped image decodes, expensive blur effects, non-builder list rendering — so the rules catch a regression before a human would notice it. That matters because mobile performance is not just average load time. It is touch response, animation stability, list smoothness, and whether the app feels dependable on the device a person actually carries around all day.

The app vision is practical: the best club near you, soon at the touch of a button, always in your pocket. The Android app comes first, with iOS to follow.

Automation: content, translation, updates, media, and sitemaps

Cannabivo includes an autonomous content engine that is operator-enablable. That word is doing real work: this is not a claim that a bot publishes unchecked, around the clock. It is a system an operator can switch on, and switch off.

When enabled, the engine can research cannabis news from multiple sources, deduplicate against its own story memory so the same event is not covered twice, generate a structured article, translate it into all 17 other languages before publishing — atomically, so a half-translated article never goes live — and syndicate it across 16 social and broadcast channels: Telegram, X, Bluesky, Mastodon, LinkedIn, Reddit, Discord, Matrix, Facebook, Instagram, Threads, WhatsApp, Web Push, the newsletter, generic webhooks, and a browser-automation channel. The publicly named rollout starts with Telegram, Instagram, and X, with more to follow.

The automation layer also runs the unglamorous machinery that keeps a large multilingual directory alive:

• Automated club-update news
• Image and video optimization workers (responsive AVIF/WebP/JPEG ladders; adaptive video)
• Nightly multilingual sitemap regeneration
• A fleet of scheduled workers driven by systemd timers, not fragile cron jobs

This is how a platform with hundreds of thousands of pages stays current. Content needs structure. Translations need sequencing. Sitemaps have to reflect a multilingual reality, not an English one. Club updates have to surface without an editor signing off on every small change. Automation does not replace judgment here — it clears away the repetitive friction so the people can stay on the parts that actually need them.

Where we stand now

Cannabivo's web platform is in production and actively maintained. The current phase runs on two tracks at once.

The first is stabilization, fine-tuning, and verification: refreshing existing club content, correcting details, and steadily tightening the platform. A directory with 13,573 club listings and 211,397 geo pages that we continuously keep accurate and up to date cannot be treated as "finished." Information changes, local details change, and the platform has to keep pace.

The second is native mobile development in parallel — the same Flutter core, offline-first, the same typed contract, the same performance discipline. The goal is simple and ambitious at the same time: the best club near you, soon at the touch of a button, always in your pocket.

Alongside both, we are rolling out automated club information across social-media channels and the Cannabivo newsletter. The homepage already shows the platform's living nature — recently added clubs, popular cities, country hubs, and the news and club-update feeds.

All 10 countries remain a work in progress. That is not a weakness to apologize for; it is honest scope management. International coverage is not a badge you pin to a static database. It is an operating commitment, and it has to be renewed every single day.

What comes next

Cannabivo's roadmap is staged, and we keep a hard line between what has shipped, what is planned, and what is still under discussion.

Android first, then iOS

The Android app is planned for the Play Store within 1–2 months, with the iOS app following in the App Store within 2–3 months. Both belong to the same technical strategy: Flutter apps sharing one core, an offline-first local database, high-refresh performance discipline, and the same generated typed contract as the website. Because they share that contract, the apps inherit the backend's correctness instead of re-implementing it — and re-implementing it is exactly where most cross-platform bugs are born.

Club and member management

Over the 3–12 month horizon and beyond, Cannabivo aims to offer club and member management for every club — extending the shipped Club Manager from public-listing editing into deeper operational tooling. The intent is to meet the administrative realities clubs already face, without forcing each club to reinvent its own software from nothing.

Marketplace vision

A marketplace also sits on the 3–12 month horizon, aimed at equipment, growing space, and the related needs around CSC operations. To be precise about what this is and is not: it is not a cannabis sales claim, and not a consumption call-to-action. It is a platform direction focused on the infrastructure and supplies the ecosystem depends on to operate.

Cannabivo-ID is under active evaluation

The Cannabivo-ID is in discussion: a digital identity that could let members check into clubs quickly through the app — less bureaucracy for clubs, a smoother arrival for members. We consider it both technically and legally feasible, and it is under active evaluation. It is not shipped, and we will keep that distinction clear.

Monetization is still open

Monetization remains an open question. The possibilities on the table include limiting free club views, premium memberships, advertising, cooperations with vape or CSC-equipment shops, and clubs using Cannabivo to manage their members. We are not presenting a final model yet. Whatever we settle on has to stay true to the platform's role: an international information directory that is transparent, legal, multilingual, and genuinely useful to the CSC community.