Full Revamp of a Ticketing Platform for Officina
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.
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.
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.
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.
-
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.
-
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.
-
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
-
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.
To minimize failed or duplicated transactions, we replaced direct synchronous calls with queued workflows.
-
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.
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
-
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.
-
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.
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
-
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
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.
