Overview
Mondal worked as a senior web developer at Webskitters Technology Solutions Private Limited from December 2012 to November 2013, after an earlier role at Artis Technology. He co-founded MyAppZone srl, the company behind Neareo, in December 2015 and took the role of chief technology officer. Over the following decade he built and operated the platform end to end: architecture, implementation, deployment and production support.
Sujoy Mondal is a co-founder of the company behind Neareo, a Brussels-based platform for cultural and tourism institutions, and served as its chief technology officer from December 2015. He is based in Kolkata, India. Neareo sells smart QR codes, AI-generated audio guides, analytics dashboards, a no-code content management system and payment integration in 12 languages, and is published under the My App Zone brand as well. The architecture represents every app as a block tree, a directed graph of typed nodes connected by explicit transitions and conditional logic, executed by a browser runtime that keeps working offline. He chose a PHP and CodeIgniter monolith for the application layer, with JavaScript, TypeScript and AngularJS on the front end, and later split out a Node.js microservice for AI orchestration. Systems he built include a no-code rule engine with more than 25 condition types, a four-stage pipeline that reconstructs visitor journeys from raw event data, and an entry router that dispatches visitors from QR codes, NFC tags and short URLs, live on sponsor sites in Spain, France and Belgium. He counts more than 30 production applications on the platform.
Career history
In the news
- My course completion certificate for "Introduction to Web AR development"
- A service worker doesn't belong to the page that registered it. Its lifecycle is independent — and that single property changes what it can do and what you have to stop it from doing. Most treatments frame service workers as a caching configuration. In a runtime system they're something else: a second execution context, event-driven, no DOM access, woken by the browser when something needs handling and terminated when idle. It isn't persistent. It's independent. Those are different claims and only the second one is true. What it
- Every trade-off you make at design time is a guess. The real trade-off shows up the first time production disagrees with you. At design time, trade-offs are theoretical. This approach is faster but less flexible. This one scales better but adds complexity. Those comparisons are informed, reasonable, and incomplete — because the cost of a decision doesn't fully reveal itself until the system runs under actual visitor load, actual device diversity, and actual usage patterns nobody fully anticipated. Frontend aggregation looked like
- Page-level analytics tells you how many people visited. Block-level trends tell you which specific button peaked on a Tuesday — and why that matters to a sponsor. Aggregate numbers are useful but rarely actionable. A sponsor learning that an exhibit had 3,000 visitors this month knows something. A sponsor seeing that one specific button on that exhibit spiked during a school-visit weekend and then dropped back to baseline learns something they can actually act on. The signal isn't in the total. It's in the shape of the total over
- Backend engineers get asked about distributed systems. Frontend engineers get asked about CSS. The gap between that question and what frontend runtime engineering actually involves is significant. The framing of frontend as a presentation layer made sense when frontend meant static pages and form submissions. It stopped making sense when the browser became an execution environment — and for a large class of production systems, that shift happened years ago. Consider what actually runs in the browser in a production
- We started using IndexedDB like a cache. Production taught us it was infrastructure. The initial move from localStorage was straightforward. IndexedDB offered structured storage, async operations, and no meaningful size ceiling — everything a growing offline runtime needed. Media assets, runtime checkpoints, analytics buffers, visitor progression state. It all persisted cleanly. The assumption was that scaling would be linear. It wasn't. The first signs appeared as the platform grew. Hydration on return visits slowed
- After ten years on the same platform, you stop thinking about what to build next. You start thinking about what you'll have to live with. That shift happens gradually. Early in a project, decisions feel reversible. You pick an approach, it works, you move on. The cost of a wrong turn feels low because you haven't yet experienced the version of that decision that shows up two years later as a constraint you can't easily undo. Long-term ownership changes that calculus permanently. The block tree that started as a simple parent-child
- A stateless AI request is just a prompt. A stateful AI session is a runtime that remembers where the workflow is going. Stateless works for isolated interactions — ask a question, get an answer, done. It breaks the moment you need multi-step workflows, provider fallbacks, or continuity across a conversation that spans several turns and might switch models mid-way. Every retry becomes a cold start. Every provider switch loses context. The visitor experience degrades in ways that are hard to debug because the failure isn't in any
Related profiles
This page shows public professional information only, each fact cited. Is this you? send a correction, or ask for removal within 24 hours, no questions asked.