Full Revamp of a Ticketing Platform for Officina

Nowr

How rebuilding a flawed ticketing platform’s prototype from scratch helped an Italian startup accelerate software development by 40%, reduce infrastructure and DevOps overhead by 25%, and get a production-ready solution.

Download

Business challenge

Every growing product carries the weight of early-stage decisions. What accelerates launch in year one can quietly constrain scalability by year two. Our client, Officina s.r.l., an Italian startup, was no exception.

After launching as an offline event platform, the company decided to enter the regulated online ticketing market by obtaining SIAE certification, a mandatory requirement for selling tickets to music events online in Italy.

To move fast with this new project – NOWR – and reduce certification time, they made some tradeoffs that later shaped the platform’s operational and technical constraints and became hard to ignore.

A flowchart with four labeled boxes: Officina – client at top, NOWR – Officina’s SIAE-certifed online ticketing platform below it, SIAE – Italian copyright authority granting homologation for music event ticketing systems to the right, and Ticka – licensed SIAE intermediary below SIAE. Dashed arrows connect the boxes.

Ticka-imposed limitations

Instead of pursuing direct SIAE regulatory approval of their own ticketing infrastructure, Officina chose to operate through Ticka, a licensed SIAE intermediary. While this decision reduced time-to-market, it also meant a few technical bottlenecks:

  • No smooth integration path. Connecting the platform via API simply wasn’t on the list. Operations had to rely on export/import files and manual copy-paste.
  • No built-in booking or refund logic. Critical safeguards had to be implemented outside Ticka.

Rigid architecture and self-contradictory infrastructure

Although outsourcing software development has numerous benefits, you reap none of them if you partner with an unreliable company. That’s what initially happened to Officina. Their previous contractor walked away leaving:

  • A monolithic, hard-to-scale architecture
  • A mix of Google Cloud and AWS infrastructure
  • Three separate backends
  • Fragmented frontend drafts
  • No CI/CD pipeline
  • Multiple code repositories

Torn between operational constraints and a brittle technical foundation, the client needed a trusted tech partner to assess what could be preserved, what required rebuilding, and how to work around Ticka-related limitations. Instinctools’ dedicated team proved to be up to the task.

Solution

After evaluating the development artifacts, it became clear that rewriting the platform from scratch would be faster, safer, and more future-proof than continuing to patch up and reuse the legacy core.

  1. Replacing a rigid monolith with flexible and secure microservices

Once the decision to rebuild was made, the question was how to design a platform that would not collapse under its own growth again. That’s why, we deliberately chose a microservices architecture as the structural backbone of the new NOWR platform.

What it meant in practice:

  • Clear function boundaries
  • A dedicated database per service
  • No shared internal logic
  • Service-to-service communication via REST and message queues

As Officina’s business model depends on third-party providers, including SIAE intermediaries like Ticka and payment operators like Stripe, staying flexible is a tough call. We designed every external integration as an isolated microservice, so that if the client’s providers change, the platform can adapt without undergoing another full rewrite.

Our delivery stack included:

  • NestJS to structure scalable backend services
  • Nx mono repository to maintain development speed without sacrificing modular boundaries
  • REST for fast frontend iteration
  • Message queues for asynchronous service coordination
  • Separate databases per microservice to prevent tight coupling

The outcome was strategic optionality. NOWR is no longer locked into architectural decisions made under time pressure years ago. The new foundation supports experimentation, provider replacement, and controlled scaling, all without destabilizing the entire system.

  1. Moving from two clouds to one

Ticket sales, especially for SIAE-regulated events, require strict ordering. Any inconsistency brings the risk of customer disputes, compliance violations, and revenue loss. Officina’s fragmented infrastructure simply wasn’t built for that level of rigor.

With some components running on Google Cloud and others on AWS, it caused operational inconsistencies and hindered scaling initiatives, not to mention the cost of maintaining two setups. As Officina already used AWS S3 as their primary cloud storage, we consolidated the rest of the stack on AWS to standardize operations and ensure correct processing order and resilience under load:

  • Amazon SQS/SNS for queued workflows and event notifications
  • EC2 with Elastic Load Balancing (ELB) to seamlessly scale server performance
  • Asynchronous processing for non-blocking operations

As part of the consolidation, we migrated operational services and related datasets from Google Cloud to AWS S3. This included transferring application data, reconfiguring storage, and aligning networking and access policies.

Operationally, shifting to a single cloud environment instead of juggling two partially integrated ecosystems also simplified DevOps activities, from monitoring deployment pipelines to managing cloud permissions and handling incident response.

A cloud architecture diagram showing AWS services: DynamoDB, SES, DocumentDB, PostgreSQL, Lambda, Cognito, API Gateway, WAF Captcha, S3, and a VPC. Services are grouped in a purple box with labeled components: Payments, Notifications, Core, and Tickla Plugin.

  1. Building a Ticka synchronization plugin to ease regulatory constraints

Fast SIAE certification with Ticka without full direct regulatory approval came at the price of tooling restrictions  For instance, our dedicated team had to bypass the lack of flexible APIs and limited automation capabilities. Since full API-level automation was off the table, we designed a viable workaround that eliminated the majority of manual steps, reduced copy-paste errors, and caught inconsistencies before they could affect ticket sales. 

Instead of embedding Ticka logic directly into the business core, we isolated it behind a dedicated Ticka synchronization plugin that serves as a controlled integration layer:

  • Pulls SIAE-certified events and tickets from Ticka
  • Synchronizes them with NOWR’s internal data structures
  • Automates export/import routines wherever technically possible
  • Validates incoming data before it enters the core system

That way, Ticka is encapsulated within its own service boundary and can’t leak constraints into the rest of the NOWR’s architecture.

  1. Ensuring compliant fiscal flows across the NOWR platform

Operating within a restricted certification scope meant that fiscal and commission handling required logic beyond Ticka’s approved tooling could support. To keep the platform compliant without slowing down ticket sales, we engineered safeguards around fiscal and payment workflows.

One of the critical challenges was monetizing ticket commissions in a tightly regulated environment while maintaining clear separation between organizer revenue and platform fees. To address it, we built a compliant fiscal backbone through integration with fiscal.com.

  • Real-time fiscalization of transactions, with compliant fiscal records generated automatically
  • Separate fiscal treatment of platform commissions, ensuring intermediary revenues were handled correctly
  • Clear audit trails for full transaction reconciliation
  • End-to-end traceability connecting each ticket sale to its fiscal record

  1. Derisking ticket purchase flow

When moving to a unified AWS-based infrastructure, we also reworked the ticket purchase flow. Previously, it ran synchronously: meaning, if any downstream component stalled or failed, the entire transaction was exposed to errors and duplication.

A simple flowchart titled Legacy flow in light gray. It has four boxes: Request captured, Direct call to provider, Immediate processing attempt, and Success or failure returned to user. Purple lines show the process sequence between boxes.

To minimize failed or duplicated transactions, we replaced direct synchronous calls with queued workflows.

A flowchart with three boxes connected by dotted arrows. The first box, highlighted, says Request captured. The second, faded, says Placed in a controlled queue. The third, faded, says Processed in strict sequence. Below the first is Confirmed only after successful execution.

  1. Orchestrating multi-party payments

As NOWR evolved into a platform that connects ticket buyers with event organizers, one challenge became central: moving money reliably between multiple parties without adding friction to checkout.

Since the market of software systems purpose-built for such transactions is broad, there was no need to hardcode financial logic into the platform. We implemented Stripe Connect, purpose-built exactly for multi-party payment flows.

A tablet displays a ticket refund management dashboard for an event. The screen shows a table listing ticket holders, ticket types, status, refund amounts, and admin notes, with search and export options at the top right.
A tablet screen displays an admin dashboard with a list of user transactions, including names, status, dates, and roles. Below, there are buttons for various actions like Refund, Copy barcode, and Stripe refund. The NOONR logo and footer links are at the bottom.

But this isn’t just “accepting payments via Stripe.” Each organizer is onboarded as a separate sub-entity within Stripe that is guided through KYC verification and configured for controlled payout flows. Revenues are automatically split between organizers and the platform, with Stripe handling fund routing and regulatory checks on its end.

Such an approach allowed the client to:

  • Manage multiple organizers within a single infrastructure
  • Automate commission distribution
  • Maintain full financial transparency and traceability

  1. Delivering advanced ticketing mechanics

Once compliance and payment flows were in place, we focused on what makes a ticketing platform truly competitive: flexible, intuitive ticketing built for the operational complexity of real-world events.

To stand out against long-established players and give organizers real reasons to switch to NOWR, our team introduced:

  • Event scheduling

    An event is no longer limited to a single calendar entry. It can now include multiple schedules, allowing organizers to offer tickets for the same event across dozens of dates and time slots.

  • Event grouping

    Separate events can be brought together into a logical collection, for example, a three-day festival where each day is managed independently but presented as a single, cohesive experience.

  • Subscriptions and multi-event passes

    Multiple schedules, including those across grouped events, can be bundled into a single discounted pass, making it possible for users to purchase access to several dates in one transaction.

  • Promo code functionality

    Public and personalized discounts give organizers more room to experiment with pricing strategies and tailored ad campaigns.

  1. Building a solid admin panel

While building an MVP, we kept thinking strategically and planning for the time when NOWR will grow into a full-scale ticketing platform and compete with Italian market leaders like Ticketmaster and TicketOne.

To head off future bottlenecks, we focused on the back-office part of the platform, delivering a full-featured admin panel. At its core is a two-step moderation framework applied both to organizer onboarding and event creation. New organizers require approval before activation, and newly created events don’t go live automatically, but are routed to moderation first, where admins can edit, approve, or reject them.

A tablet displays a statistics dashboard for the event “LUMEN SPIN OFF + BNKR44 & FUERA.” A bar chart below shows monthly revenue and quantity data, with a total revenue of €234,042 highlighted at the top.
A tablet screen displays a ticket management page showing a list of purchased tickets with buyer names, ticket types, status, order numbers, cities, issue dates, and event dates. The interface also includes filter options, export button, and a navigation menu at the bottom.

This ensures tight operational control and strong platform governance, supported by:

  • Centralized management of accounts and event entities
  • Structured event editing and publishing
  • Real-time oversight of ticket availability and sales performance

  1. Refining brand identity alongside product development

Having contributed to the rollout of hundreds of digital products, we know that functionality alone is not enough to win users. A feature-rich, intuitive platform is only half a solution, but first, it has to catch the customer’s eye.

Going beyond engineering, we conducted a brand audit and proposed enhancing the platform’s logo and overall visual language to make it clearer and more cohesive:

  • Modernized the logo for better readability and responsive use
  • Standardized typography, spacing, and color usage across the interface
The image shows NOWR with the W as a turquoise geometric triangle. Below, three dashed arrows point down to a second NOWR, this time with a standard black W. The background has white and turquoise bands.

Before

  • Jerry-built prototype
  • Monolithic architecture with three separate backends and fragmented frontends
  • Mixed Google Cloud and AWS infrastructure
  • No CI/CD and code scattered across multiple repositories
  • Synchronous ticket purchase flow vulnerable to duplication and failures
  • Lack of foundation for compliant fiscal flows
  • No multi-party payments
  • Manual export/import workflows with Ticka
  • Baseline ticketing mechanics

After

  • Solid product
  • Microservices-based architecture with clear service boundaries
  • Fully consolidated AWS infrastructure
  • Structured mono repository with CI/CD pipelines
  • Queue-driven, asynchronous ticket purchase flow
  • Compliant fiscal flows
  • Smooth multi-party payments
  • Custom Ticka synchronization plugin acting as a controlled integration layer
  • Advanced ticketing mechanics

Business value

  • Scalable foundation for growth in a regulated EU ticketing market
  • Stronger platform governance thanks to a centralized admin panel with advanced moderation capabilities
  • + 40% in feature delivery speed thanks to independent microservice deployments
  • – 25% in infrastructure costs after shifting to a single AWS ecosystem

Multiplier effect

The constraints Officina faced, such as rigid legacy architecture, fragmented cloud infrastructure, and dependence on third-party providers with legacy integration options, are far from unique to the entertainment and media industry. Similar bottlenecks emerge in fintech, ecommerce, logistics, healthcare, and any integration-heavy domain where early technical shortcuts collide with long-term growth. If your team lacks the time or perspective to surface and fix them early, an experienced tech partner can step in before technical debt compounds.

Four young adults in a modern office work on laptops displaying code. One person stands, leaning over with a laptop, discussing something with the others, who are seated and listening attentively. Large monitors with code fill the background.
Related capabilities

Do you have a similar project idea?

Anna Vasilevskaya
Anna Vasilevskaya Account Executive

Get in touch

Drop us a line about your project at contact@instinctools.com or via the contact form below, and we will contact you soon.