Why We Chose Laravel 12 Over Node.js for Eventiq — and What the Recurring Event System Taught Us About Premature Architecture

OrFactor — Tue, 18 Aug 2026 14:00:00 +0000

We just shipped v2.0.0 of Eventiq — an event management and ticket booking platform built on Laravel 12 with two Flutter mobile apps. This post covers the stack decisions that actually mattered, the architecture problem nobody warned us about, and the recurring event system that forced us to rethink how we'd structured the entire backend.

No pitch. Just the technical decisions and what we learned from them.

The Stack and Why

Laravel 12 over Node.js

We debated this. Node.js would have given us a unified JavaScript environment across frontend and backend, which sounds appealing until you actually map out what Eventiq needs to do: multi-role authentication, complex subscription logic, QR token generation and validation, payment webhook handling, KYC flows, payout management, CMS tools, SEO management, and a role/permission system with granular control.

Laravel 12 gave us Eloquent for the complex relational queries this feature set demands, a mature queue system for payment webhook processing, built-in policy/gate system for the multi-role permission layer, and an ecosystem of packages for things like 2FA and social authentication that we didn't have to build from scratch.

The honest reason we didn't choose Node: the team's Laravel depth meant we'd spend our complexity budget on product problems, not framework problems. Stack familiarity is an underrated architectural input.

Required PHP extensions worth noting: bcmath, ctype, fileinfo, json, mbstring, openssl, pdo, tokenizer, xml. If you're packaging a Laravel app for self-hosted distribution — which Eventiq is — you learn quickly that your "standard" extension list is someone else's deployment blocker. We document this explicitly now.

Using Flutter 3.41.1, managed with FVM, for both mobile applications.

Eventiq ships two Flutter apps: a User App for attendees and a Volunteer App specifically for gate staff scanning QR tickets. FVM (Flutter Version Management) pins the Flutter version at the project level. This is non-negotiable for any team shipping multiple Flutter projects — version drift between developers is silent and painful.

The Volunteer App had a specific constraint: it needed to work at event venues where WiFi is overloaded by hundreds of attendees simultaneously. We built local ticket cache sync so the app can validate QR codes against a locally cached list when connectivity degrades. The scan still writes back to the server when connection resumes, but the volunteer isn't blocked at the gate.

The Multi-Role Architecture Problem

Four distinct roles share one backend: Admin, Organizer, User, and Volunteer. Each has completely different permissions, different data access patterns, and different business logic.
The naive implementation is a single controller layer with if ($user->role === 'organizer') conditionals scattered throughout. We didn't do this, but we came close in the early organizer approval flow before we caught it.
The approach that worked: role-scoped service layers. Each role gets its own service layer encapsulating its permissions and business logic. Controllers stay thin. When the Volunteer role was added mid-build — it wasn't in the original spec — we added a service layer rather than threading volunteer logic through existing controllers.
The changelog entry for v2.0.0 that reads "Fix: Resolved recurring guest synchronization foreign key issue during organizer event updates" exists precisely because of a moment when organizer logic and a new recurring event feature became tangled in a way that the service-layer separation was supposed to prevent. We missed it. The FK constraint caught it in testing rather than production, which is the best-case scenario for that class of mistake.

QR Ticket Signing — Why We Don't Store Plain Booking IDs

The QR code encodes a signed token, not a booking ID.

This matters because a plain booking ID in a QR code is an integer. Anyone who can read one valid QR code can increment that integer and attempt to generate adjacent valid tickets. Depending on how validation is implemented, this can be exploited.

Our tokens are signed with a server-side secret. The Volunteer App validates the signature before checking booking status. An unsigned or incorrectly signed token is rejected before it ever hits the database. The validation write is idempotent — scanning the same ticket twice returns "already used," not an error that stalls the volunteer's queue.

The Recurring Event System — Where We Got the Architecture Wrong the First Time

v2.0.0's biggest feature: full recurring event support with daily, weekly, and monthly schedules.

This sounds straightforward. It isn't.

The first design we considered stored recurring events as a single event record with a recurrence rule attached — similar to how calendar applications handle it. The problem: Eventiq events have ticketing, attendee lists, volunteer assignments, payout records, and refund histories attached to them. A single parent record with generated child occurrences meant that any operation on a "recurring event" had to decide: does this apply to this occurrence, all future occurrences, or the entire series?

That's the same question Google Calendar asks you when you edit a recurring meeting. It's deceptively complex when financial records and sold tickets are involved.

The approach we shipped: recurring events generate actual child event records on a schedule, with a sync workflow for updating future occurrences when the series definition changes. The v2.0.0 changelog line "recurring event updates now remove only future generated occurrences when recurring is disabled, keeping past/live occurrences intact" describes a real business logic decision — you can't retroactively remove an event that already happened and sold tickets.

Past occurrences are immutable once they go live. Future occurrences can be modified or removed. The data model has to enforce this, not just the application layer.

If we were starting over: we'd have designed the recurring system before the ticketing system, not after. The shape of the ticketing data model constrained our options for recurring events more than we'd like.

The OpenAI Integration

— and the One Thing That Actually Mattered

Eventiq includes an AI content assistant powered by the OpenAI API. Organizers fill in basic event details and get a generated event description and blog content they can edit and publish.

The implementation is a standard OpenAI API call with a structured prompt — nothing custom-trained, nothing exotic. We considered a few approaches and chose the simplest one that worked.

What we learned: placement in the workflow matters more than the AI implementation itself. The same capability surfaced at the exact moment a user faces a blank text field gets used consistently. Buried in a settings page, it gets ignored. This is a product decision, not a technical one, and it took us longer to figure out than the actual API integration.

One thing to be transparent about for buyers: OpenAI API usage is billed separately by OpenAI. We document this explicitly in the item description because we've seen too many marketplace products bury this detail. If you're running Eventiq at scale with heavy AI usage, that cost is real and worth factoring in.

The Addon Architecture (New in v2.0.0)

The other significant v2.0.0 addition: an addon system that lets developers extend Eventiq with their own modules. Addons are packaged as zip files, validated against a purchase code and buyer email at upload time, and registered as service providers that can add routes and features to the core platform.

This was the hardest part of v2.0.0 to get right. Laravel's service provider system is designed for packages installed via Composer — adapting it for runtime-uploaded addon packages with their own routes and navigation integration required careful sequencing of the boot process. The changelog entry "Added active addon provider boot loading so installed addons can register routes and features correctly" describes about two days of debugging provider load order.

Where Eventiq Is Right Now

Eventiq is live on CodeCanyon at $49. It's a self-hosted platform — buyers get full source code and deploy on their own infrastructure. We're early — four sales and one review as of this post. We're sharing this because the technical decisions above are real and might be useful to someone building something similar, not to claim battle-tested scale.

If you're building a multi-role platform on Laravel and want to talk through any of the decisions above — particularly the recurring event data model or the addon service provider approach — drop it in the comments. We're genuinely interested in how others have solved the same problems.

→ Live Demo: [(https://eventiq.orfactor.com)]Live Demo
→ CodeCanyon: https://codecanyon.net/item/eventiq-event-management-with-ticket-booking-web-and-mobile-app/62156577
→ User APK: https://drive.google.com/file/d/173MyPSnz5_hqN_swcv7vR6qXSoieWK9d/view
→ Volunteer APK: https://drive.google.com/file/d/1U4OnmfMRJlC2qr7zEiFtHjqHu0MdOp1m/view

OrFactor: Software Engineered to Simplify Complexity

OrFactor — Thu, 06 Aug 2026 09:10:00 +0000

Most software agencies say they build "solutions." We build software that has to actually run — for logistics companies moving freight, event organizers checking in guests, and businesses that don't have room for a platform that breaks on launch day.

OrFactor has been doing this out of Dhaka since 2014, with team members now working across Bangladesh, the US, and Malaysia. We're not a 500-person consultancy, and we're not a two-person freelance shop either — we're a working engineering team of 10–49 people who take on the projects big firms consider too small and freelancers can't scale to handle.

What we actually do

We work across six areas, and most client projects touch more than one of them:

App & Platform Development — the core of what we do. Web and mobile applications built from scratch: SaaS platforms, e-commerce systems, fintech tools, healthcare apps. This is where most of our documented client work lives, including a logistics management platform for Bifle Logistics and an event management build for Ke-Fas Event.

Product Experience Design — UX/UI work that isn't bolted on after the fact. We design the interface alongside the system it runs on, which is part of why clients keep telling us the product actually feels usable, not just functional.

AI & Automation — LLM integration, predictive tooling, workflow automation. This is a newer, growing part of our practice — we're upfront that it doesn't have the multi-year track record our core development work does yet.

Managed Tech Services — ongoing DevOps, cloud operations, and system support for teams that need a technical partner after launch, not just at launch.

Tech Strategy & Advisory — architecture, cloud readiness, and security consulting for teams that need a second set of senior technical eyes before they commit to a direction.

Data Intelligence — data pipelines, dashboards, and analytics built into the platforms we ship, for teams that want their software to tell them something, not just run.

Beyond custom builds

We also maintain a small catalog of ready-made software products — things like EventIQ (event check-in and ticketing), Stoqio (inventory management), and Inflio (a template for influencer/creator platforms) — sold directly rather than built bespoke. For teams that don't need a fully custom build, these get you running in days instead of months. And if you outgrow the template, that's usually where a custom engagement with us starts.

Why this matters more than a client logo wall

Software agencies are easy to find and hard to trust — everyone claims quality, speed, and communication. What we'd rather you judge us on: a 5.0 rating across our completed engagements, and a habit of clients coming back for the next project. That's a smaller claim than "we're the best," but it's one you can actually verify.

If you're evaluating a technical partner for a build that has to work under real usage — not a demo, not a pitch deck — that's the kind of work we take on.

DEV Community: OrFactor