iMidooh — DOOH Media Management
DOOH Media Management Platform
Building a scalable SaaS foundation for Digital Out Of Home media operations, focused on solid architecture, modular organization, and readiness for multi-tenant expansion.
Map-based media discovery, with offer and traffic filters
Panel record: price, availability and technical specs
iMidooh represents the construction of a scalable SaaS foundation for DOOH media operations, focused on solid architecture, modular organization and readiness for multi-tenant expansion.
Strategic Vision
iMidooh was built to structure and scale DOOH (Digital Out Of Home) media operations, offering a centralized platform for managing campaigns across LED panels distributed in multiple locations — with a solid foundation for SaaS evolution.
What needed to work from day one
- Updating content remotely, predictably
- Monitoring displays and operational status in real time
- Consolidating performance reports with confidence
Context and Product Construction
Development began with a deep discovery phase: operational flows, user profiles, display rules, and the physical limitations of the panel ecosystem. The strategy was to avoid improvisation and build a modular foundation ready to scale.
API
Campaign, panel, display and data integrity rules.
Admin (Next.js)
Operational management, configuration and a consolidated view.
Mobile (React Native)
Field operations and hands-on tracking.
Architecture and Technical Decisions
The architecture was designed to be decoupled, modular and easy to maintain — with well-defined domain modules (panels/media, campaigns/bookings, metrics) behind a single gateway, and a data model ready for multiple clients from the very first migration.
Consistent data
PostgreSQL with relational modeling for panels, campaigns, bookings and performance metrics.
Productivity with safety
Prisma to speed up data access with a typed, stable layer across the API and its modules.
Standardized environments
Docker isolating dev, staging and production, with configuration parity between them.
Domain-driven modules
NestJS organizes panels, campaigns/bookings and metrics as independent, individually testable modules.
Logical tenant isolation
Every record carries a tenant_id from the initial design, avoiding rework to separate clients later on.
Independently deployable layers
Gateway, API modules and database are versioned and deployable separately.
The system was structured to allow a future full rollout of multi-tenancy and white-label expansion, without requiring a rewrite of the data model or the domain modules already implemented.
Data Model and Performance Metrics
Each media panel carries operational data (location, resolution, weekly availability, price) and performance data (daily views, unique audience, conversion rate and rating), with audience demographics broken down by age range. This model let clients decide whether to book based on real data, not a sales estimate.
Core entities in the data model
- Panel/Media: location, resolution, price and availability windows
- Campaign/Booking: contracted period, status and schedule conflicts
- Performance metric: views/day, unique audience, conversion, rating
- Audience demographics: breakdown by age range
Per-panel metrics: views, audience, conversion and demographics
Execution and Integration
Execution covered campaign rules, display control and panel management — with clear integration between backend, admin panel and mobile operations.
Implementation principles
- Organized, predictable code
- Separation of layers and responsibilities
- Evolvable communication between applications
- Foundation ready for future integrations
- Schedule-conflict checks before confirming a booking
- Geolocation-based media discovery, with offer and traffic filters
Deploy and Operations
The application was prepared for distinct environments (development, staging and production) with containerization and structured versioning.
The infrastructure was designed to ensure:
- Deploy predictability
- Environment isolation
- Future scalability
- Ease of maintenance
The project was structured from the start with observability and operational growth in mind.
Project Impact
iMidooh established a robust foundation for centralizing DOOH media operations, reducing reliance on manual processes and paving the way for commercial expansion.
Beyond the technical solution, the project established a replicable architectural model for SaaS products — focused on organization, scalability and maintainability.
The project was discontinued before its commercial phase, but it reached a clear point of technical maturity: a data model ready for multiple clients, isolated domain modules, real per-panel performance metrics, and containerized infrastructure across three environments. That stopping point — not an unfinished version — is what this case study documents.
Trade-offs and what I'd do differently
What I chose not to build
- Per-tenant schema isolation: stayed on a single schema with tenant keys, simpler to run solo, knowing it would need revisiting before any real client hit production.
- Billing and subscriptions: the project was discontinued before the commercial phase, so I didn't build charging — I prioritized leaving the data model ready for it later.
What I'd do differently today
I'd invest in automated tenant-provisioning tests from the start instead of validating it manually with every new module. With the project stopped at a clear point of technical maturity, that's the clearest gap between what exists today and what it would take to safely onboard the first client.
Rights and Ownership
iMidooh is a product conceived and owned by Click Software House. All rights to the project, including brand, source code, design and other materials, are reserved to Click Software House. This case study is presented solely to demonstrate the technical work performed, and any reproduction, copying or reuse of the project without prior authorization from the originating company is prohibited.
Key Challenges Faced
iMidooh's complexity wasn't just in the code, but in modeling a product that needed to be built ready to grow from day one.
Designing a data model ready for multiple clients from the very start
Ensuring data consistency and integrity across simultaneous, distributed campaigns
Organizing a modular backend for future white-label expansion without a rewrite
Structural Technical Indicators
- Modular architecture
- Normalized relational database
- Containerization with Docker
- Isolated environments (dev / staging / prod)
- Foundation ready for multi-tenancy