ArtWizard
Cultural events platform built from scratch as the sole developer
ArtWizard started as a mobile app built by its founder to solve his own problem: the cultural events he cared about in Lviv — small exhibitions, gigs, niche gatherings — never made it onto the usual listing sites. Following them meant sitting in dozens of Facebook groups, Telegram channels and Instagram accounts and hoping not to miss anything. The app pulled those scattered organisers into one place, and later expanded to Kharkiv.
By the time I joined there was an app and a backend behind it, but no web presence at all. I was hired to build that: a Next.js site covering the landing page for the app, browsable events, location pages and the supporting pages around them. Four of us — the founder on mobile, a tech lead assigning the work, a designer producing the layouts, and me on the web side.
Everything the product knew lived inside an app you had to install first. For a service whose whole premise is discovery, that's backwards: someone searching for what's on this weekend won't download an app to find out. The events needed to exist as pages — reachable, linkable, and visible to search engines.
Next.js on the app router, server-rendered, styled with Tailwind and deployed on Vercel. Redux for client state. The data came from the existing NestJS API and MongoDB that already served the mobile app — the web client was a new consumer of a backend that was already in production.
Remember the city, keep it in the URL
Once Kharkiv was added, every visit started with a question the user shouldn't have to answer twice — somebody browsing events in Lviv is almost certainly in Lviv. A first visit lands on the neutral root; after that the choice is remembered and the root redirects to that city's path. Keeping the city in the URL rather than only in state meant a city page stayed shareable and indexable, which mattered for a product whose whole point is being found.
Consume the existing API rather than reshape it
The backend was already in production serving the mobile app, and changing its contracts would have meant coordinating a mobile release for every web adjustment. The web client took the API as given and did its shaping on the server side inside Next.js, so the mobile app was never blocked on frontend work.
The site went live with the first page and stayed live — every feature after that shipped straight to production. It's still running.
Redux was the wrong tool for this site and I picked it because it was the state library I knew. A listings site with a city selector and a few filters has almost no client state worth centralising — most of what I put in the store belonged in the URL or on the server. It worked, but it added a layer the project never needed.
The bigger cost was in the navigation. Catalogue pages are server-rendered with cache invalidation, which is right for content that changes daily, but clicking through to an event or a location does nothing visible for a second or two — the page you're on stays put until the next one arrives fully formed. It's correct and it feels broken. A pending state, or a route transition that acknowledges the click, would have cost very little and fixed the one thing every visitor actually experienced.
MongoDB with Mongoose was inherited rather than chosen — the backend already served the mobile app when I arrived. For data this relational, a relational database would have fit better, but the schema wasn't mine to redesign for a web client arriving second.
Let's talk
Open to full stack roles, remote or on-site in Varna. The fastest way to reach me is email or Telegram.