APP DEVELOPMENT
ADMAF
ADICC: Building an Anonymous Competition Platform from Brief to Launch
What is ADICC?
ADICC (Abu Dhabi International Competition for Composition) gives emerging and established composers from around the world an opportunity to submit original work for major cash prizes, mentoring, international recognition and performance opportunities. Its second edition welcomes entries in two categories: orchestral composition and solo piano.
Due to the vast number of entries, ADMAF required a digital platform to be created to support the both public application experience and judging as well as the internal competition admin process.
Composers needed to create an account, prepare their entry, upload their work and receive confirmation. Administrators needed access to entrant information and submission records. Jurors needed to review the music without receiving the personal information that could identify its composer.
The anonimity requirement was paramount, as was enforcing the rules of the competition, all of which the platform had to do. It needed to connect the competition’s participants while maintaining clear boundaries between what each person could see and do.
The Challenge
An anonymous competition presents a more complex problem than a standard online application form.
ADMAF needed to collect personal information for eligibility checks and communication while withholding that information from the jury. Musical scores and recordings introduced another risk: a file could look anonymous on screen but still contain its creator’s name in its filename or hidden properties.
The submission process also needed to accommodate real behaviour. Composers might prepare an application over several sessions, encounter an upload error or need to return after correcting their files. Administrators needed to distinguish unfinished drafts from completed submissions and manage records without compromising anonymous review.
CrisP Digital’s task was to translate those operational requirements into a clear user experience and an enforceable technical workflow.
Business Analysis and Requirements Definition
The work began by turning the competition brief into a structured specification.
Chris worked with ADMAF to define the information collected from composers, the composition details required for each entry and the supporting materials accepted by the portal. This included a mandatory score PDF, optional audio and optional programme notes, alongside declarations and acceptance of the competition rules.
The requirements were then mapped across three user groups:
User Group | Core Requirements |
Composers | Account access, application preparation, save and resume, reference codes, file uploads, validation and submission confirmation |
Administrators | Entrant information, submission oversight, status management, jury assignment, exports and controlled content updates |
Jurors | Assigned submissions, anonymous references and access to the materials required for review |
This stage also surfaced policy decisions that affected implementation, including entry limits, category participation and the jury’s review process. Those questions were treated as business decisions requiring client input.
A central output was the submission specification itself. It made the anonymity requirements explicit: reference-based filenames, checks for identifying metadata and separation of composer information from jury-visible material.
That gave design, development and testing a common basis.
Solution Design
CrisP Digital proposed a standalone competition application connected to ADMAF’s existing public website.
This gave the portal its own authentication, database and private file storage while allowing the organisation’s website to remain the entry point for competition information.
The solution connected three experiences through one underlying submission record.
For composers, it provided a guided route from account creation to final submission. For administrators, it provided the information and controls needed to operate the competition. For jurors, it provided a restricted view of assigned work identified by an anonymous reference.
The reference code linked those experiences. Administrators could associate an entry with its composer while the jury could identify and review the same work without access to the composer’s profile.
User Experience and Interface Design
The interface was organised around the tasks users needed to complete.
For composers, the application separated personal information, composition details, submission files and declarations into understandable sections. Anonymous file instructions explained how to name uploads and why hidden file properties mattered.
Save-and-resume functionality allowed entrants to return to an unfinished application. Upload feedback helped them identify problems before final submission. Submission states and confirmation messages made the distinction between saving work and formally entering the competition clear.
Interaction details were refined during testing, including loading states, duplicate-submit prevention and clearer focus on successful submission feedback.
For administrators, the experience centred on managing applications and preparing submissions for review. A limited content-editing area allowed approved form copy to be updated while keeping validation rules, data mappings and workflow controls protected.
For jurors, the interface prioritised assigned entries and the materials needed for anonymous review. The final scope supported that review process without an online scoring system.
Technical Architecture
The platform used a custom application architecture with managed infrastructure.
Component | Purpose |
|---|---|
Next.js and TypeScript | Application interface, server-side workflows and typed application logic |
Tailwind CSS | Interface styling |
Supabase Auth | Account authentication and session management |
Supabase PostgreSQL | Entrant records, applications, references and workflow data |
Supabase Private Storage | Restricted storage for submission files |
Database access policies and restricted jury views | Enforcement of role and data boundaries |
Vercel | Application hosting and deployment |
Resend | Transactional emails, including submission confirmation |
GitHub | Version-controlled source and delivery history |
Access control extended beyond the interface. Entrants, administrators and jurors had different permissions enforced through application checks and database controls.
Jury-facing data exposed the anonymous information required for review. File access used server-side authorisation and short-lived signed links, keeping submission materials in private storage.
This architecture supported the central design principle: collecting identifying information for administration should not make that information available to the jury.
Development and Workflow Implementation
Development connected the interface to the underlying competition process.
The entrant workflow covered account access, application preparation, reference generation, file uploads, declarations and final submission. Drafts remained distinct from submitted entries, with jury assignment forming an explicit step in the review workflow.
File validation addressed several different concerns. Filename checks linked uploaded work to the correct reference. Metadata checks examined properties such as PDF Author and Title fields and MP3 ID3 tags for identifying information. File-content checks helped detect uploads that did not match their stated format.
These checks supported the competition’s anonymity requirements alongside entrant declarations and administrative review.
The administration workflow included submission management, jury assignment, export functionality and audit logging. Controlled content editing gave ADMAF a practical way to maintain selected wording without exposing the application’s operational rules to accidental changes.
The jury workflow completed the connection, providing access to assigned submission materials while retaining the separation between composer identity and anonymous review.
Testing and Quality Assurance
Testing covered complete user journeys as well as individual features.
The work included authentication and recovery, draft saving, upload handling, validation feedback, declarations, final submission, confirmation emails, administration and jury access.
Permission checks examined whether each user group could access the appropriate records and files. Workflow checks addressed duplicate submission attempts and the distinction between drafts and entries ready for review.
Automated tests, browser-based checks, TypeScript checks, linting and production builds supported the delivery process. Client testing added feedback on the practical application experience and administration workflow.
Post-deployment investigation also helped refine the platform. In one reported case, a valid MP3 passed the filename check and reached storage but was rejected by an overly narrow file-signature validator. The fix improved MPEG Layer III frame validation so legitimate recordings could be recognised more reliably.
Another correction addressed the interaction between withdrawn applications and the rule limiting active entries. The database constraint was adjusted to allow the intended resubmission workflow while preserving the active-entry restriction. These examples show why QA had to cover realistic files and state changes as well as a successful first submission.
For ongoing testing and QA logs were built into the administrator profile in order to track real time entries and error handling.
Deployment and Launch Support
Delivery extended through production deployment at adicc.admaf.org.
The launch process brought together the application, database changes, authentication, private storage, transactional email and production configuration.
Final content updates aligned the portal with approved competition information, including dates, eligibility, calls to action and links to the rules. Client access and testing supported preparation for public submissions.
Support continued after deployment through investigation of reported issues and targeted fixes. The work connected diagnosis, implementation and production release, maintaining continuity between the original requirements and the live service.
The Outcome
ADMAF received a live submission platform supporting the second edition of ADICC, where they were able to monitor applicant progress, track and support user errors and ensure fair unbiased judging.
Composers could prepare and submit their entries through an account-based process. Administrators could manage the records and review workflow. Jurors could access assigned work through an anonymous view.
The delivered value lay in bringing those activities together with explicit permissions, submission states, validation and confirmation.
For CrisP Digital, the project demonstrates end-to-end delivery: understanding the business process, designing the service, building its technical foundations and carrying it through testing, deployment and launch support.
A competition process translated into a working service
ADICC shows how business analysis and technical delivery can work together.
The competition rules shaped the data model
Anonymity shaped permissions and file handling
The composer's needs shaped the application journey
Administrative needs shaped management and export tools
CrisP Digital took the work across the full project lifecycle, giving ADMAF one delivery lead from the initial brief through to the live platform.
Have a process that needs a purpose-built digital platform? Contact CrisP Digital to discuss the requirements, solution and delivery.
Let’s build something that works better together.
Whether you need a new website, stronger marketing, better SEO, CRM implementation or practical AI enablement, CrisP Digital can help.