Lulebora Dual-Engine Web Ecosystem
End-to-end design and engineering of two independent web platforms — lulebora.al (commercial studio) and qendra.lulebora.al (NGO) — with a shared schema.org knowledge graph and edge deployment.
This system establishes the foundational digital infrastructure for the Lulebora organisation — a commercial creative technology studio and its non-profit cultural arm. The two platforms share a brand system and a semantic knowledge graph but operate as completely independent, separately deployed applications. The design challenge was to maintain coherence between a commercial and a cultural identity without collapsing them into a single platform — a structural decision that reflects the actual legal and operational separation of the two entities.
A dual-entity organisation — with a commercial agency and an NGO operating under the same brand — required two distinct web presences that are semantically connected but operationally independent. A single platform would conflate the commercial and cultural identities, creating confusion for institutional audiences and weakening the authority signals of each entity for search engines. Building two unrelated sites would miss the semantic benefit of the shared organisational identity.
Two separate Next.js 15 applications in independent directories — no shared code, no monorepo coupling — were chosen because the deployment, content, and audience requirements of each platform are fundamentally different. The semantic connection is implemented through schema.org JSON-LD: an Organization entity on lulebora.al declares a subOrganization pointing to an NGO entity on qendra.lulebora.al, which in turn declares a parentOrganization back to lulebora.al. This creates a Google Knowledge Graph-visible hierarchy without coupling the codebases.
System Layers
- Two independent Next.js 15 applications with shared brand identity
- Bilingual routing (EN/SQ) via cookie-based locale — no URL prefix required
- Schema.org Organization → NGO → ProfessionalService JSON-LD hierarchy
- Supabase events system with bilingual content and Row Level Security
- Dynamic /events/[slug] routes with ISR and full Event JSON-LD
- /chess institutional pillar page with SportsOrganization schema
- Structured /work case studies with PAESO format and expandable detail sections
- 45-entry sitemap with canonical + EN/SQ alternates
- Security headers on both domains (X-Frame-Options, CSP-ready)
- robots.txt with /admin restriction on NGO domain
- MobileMenu with full-screen overlay, aria-dialog, body scroll lock
- CSS Modules throughout — zero runtime overhead, no Tailwind dependency
The knowledge graph is the schema design. The Organization (@id: lulebora.al/#organization) declares hasOfferCatalog with six ProfessionalService entries and a subOrganization pointing to the NGO (@id: qendra.lulebora.al/#organization). The NGO declares parentOrganization back to the studio. The chess program is a SportsOrganization nested under the NGO. All @id values use the canonical domain URL pattern to ensure Google can resolve and merge the entities in the Knowledge Graph.
The two platforms share a square aesthetic — zero border-radius, system-level typography, structured grid layouts — but use distinct brand colours to signal their different natures. lulebora.al uses brand-pink for commercial authority; qendra.lulebora.al uses warm amber to signal cultural warmth. Navigation structures are different by design: the studio's header is minimal and operational; the NGO's navigation is community-oriented. This prevents users from feeling they are on the same site.
Security headers are configured identically on both domains via next.config.ts: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin. Both robots.txt files are present. The NGO platform adds Disallow: /admin for future admin panel protection. All external cross-domain links use rel="noopener noreferrer". The Supabase anon key is the only public credential — it has no write access by default and is protected by RLS policies.
Both platforms use Incremental Static Regeneration (ISR) at the page level. Static pages (homepage, service pages, about) are served directly from Cloudflare's edge cache with no runtime compute. Dynamic pages (/events/[slug]) are pre-generated at build time from the Supabase events table and revalidated every 3600 seconds. CSS Modules produce zero-runtime style injection — all styles are extracted at build time. No JavaScript frameworks for interactivity beyond Next.js React — the MobileMenu is the only client component on the marketing sites.
Two production platforms live on Cloudflare Pages, globally distributed. The schema.org knowledge graph is implemented and crawlable. The bilingual i18n system operates without a library dependency or URL fragmentation. The events system is live with Supabase data feeding both the listing and detail routes. The case study architecture provides a reusable template for documenting future work. Both platforms share the same operational foundation while maintaining distinct visual and semantic identities.
The next layer is a shared analytics infrastructure — a Cloudflare Analytics Engine integration feeding a private dashboard visible across both platforms. Vector search via pgvector on the Supabase instance would enable semantic discovery across case studies, events, and project content. The /work case study architecture is designed to eventually be CMS-driven — a Supabase table mirroring the current static type definition would unlock non-developer content management.
Build similar infrastructure for your organisation.