Selected Work

The previous operation relied heavily on physical ticket sales, WhatsApp reservations, and manual passenger logs. This led to chronic overbooking during peak summer months, delayed boarding procedures, and revenue leakage from untracked cash transactions. There was no way to accurately predict daily load weights — critical for maritime safety — or securely collect international payments in advance.

A full-scale Next.js 14 architecture was implemented with a custom Stripe integration to handle international multicurrency payments. A headless CMS approach manages the schedule structure, while custom database constraints enforce vessel passenger limits and vehicle deck square-footage limits simultaneously.

The system launched successfully ahead of the summer season, processing thousands of digital tickets and significantly reducing boarding chaos at the terminal. Revenue recovery improved dramatically by capturing upfront electronic payments instead of relying on cash collections.

Institutional clients in Albania had no purpose-built digital management infrastructure. Operations were conducted through disconnected email chains, spreadsheets, and PDF documents — with no centralised client database, no structured contract versioning, no automated billing, and no grant reporting workflow. Data lived in multiple formats with no audit trail, no access control, and no scalability mechanism. Compliance requirements from EU funding frameworks compounded the problem: manual reporting was error-prone and chronically delayed.

An edge-native serverless architecture was chosen to eliminate infrastructure maintenance overhead while ensuring global performance. The decision to use Cloudflare Workers (rather than a traditional server) was driven by the requirement for sub-50ms response times without managing persistent compute. Supabase was selected for its PostgreSQL compatibility, built-in Row Level Security, and the ability to enforce per-organisation data isolation at the database layer — not at the application layer — which is the correct place for it. The separation of concerns across three Workers (api-gateway, invoices, proposals) ensures each service has a single responsibility and can be independently deployed, scaled, or replaced.

The platform replaced a fragmented manual workflow across email, spreadsheets, and disconnected PDF documents. Institutional clients now have a structured, audit-ready system for managing their full operational lifecycle — from initial contact through proposal, contract, milestone delivery, and invoicing. Internal operations that previously required multiple tools and manual reconciliation are now handled in a single platform with enforced state transitions and complete audit history. The system is deployed and in active institutional use.

Proposal management in Albanian agencies was entirely manual: Word documents sent by email, acceptance confirmed verbally or by reply email, invoice amounts calculated by hand, and VAT applied inconsistently. There was no version history, no approval audit trail, no automated conversion from approved proposal to invoice, and no fiscal compliance mechanism. The result was frequent billing errors, delayed payments, and no structured data for financial analysis.

Cloudflare Workers were chosen over a traditional server because the proposal and billing workflows are event-driven and burst-patterned — not continuously loaded. A persistent server would be wasteful and introduce cold-start risk. The state machine approach (draft → submitted → approved → invoiced → paid) is enforced at the database layer using PostgreSQL enum types, not application logic, making it impossible to create invalid state transitions through API calls. PDF generation runs server-side to ensure consistent output independent of client browser capabilities.

The proposal-to-invoice cycle that previously required multiple manual steps across email, spreadsheet, and accounting software is now a structured, auditable, single-platform workflow. Proposal approval is tracked with a complete actor log. Invoices are generated automatically on approval with correct VAT computation. The engine is deployed across two institutional client accounts and handles active billing operations.

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.

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.