Paranoise Radio is a community web radio station established in Thessaloniki in 2008. I joined as a resident producer in 2010-11, initially curating a radio show and gradually taking on responsibilities across programming, operations, and digital product design. After several iterations of the audience-facing website, I turned my attention to the internal systems that keep the station on air.
Paranoise is run by its members. Residents produce shows, but they can also take on operational tasks alongside their residency. The boundaries between resident, operator, guest, and audience member are fluid: a person’s role depends on what they are doing at a particular moment.
The station runs in seasons from October to mid-July. Within each season, recurring shows produce episodes that must be scheduled, prepared, aired, announced, published, and archived. Keeping a continuous 24/7 stream running means coordinating both the programme that is expected to happen and the media that is actually delivered.
Over time, Paranoise’s digital ecosystem grew from a home-hosted radio server, a blog, and a downloadable .pls file into an array of specialised services. No single system represented the complete journey that episodes, residents, guests and radio operators go through during a season.
This fragmentation placed the burden of coordination on residents and volunteer operators. Submitting an episode meant moving files and metadata across services, keeping dates aligned, preparing artwork, and relying on operational knowledge that was not visible in any one interface.
This is where Console comes in. It aims to let the systems do the talking so that Paranoise members can focus on doing radio.
I built and deployed Console V0 in February 2026. It gave residents a single interface for submitting a show. After a resident uploaded an episode, Console:
Console V0 ran in learning mode until the end of the radio season. It allowed me to test whether one interface could successfully trigger several operational services while observing how the tool behaved under real use.
Feedback and observed use showed that the opportunity extended beyond episode submission. In October 2026 with the beginning of the new radio season, I begun experimenting with features that cover additional steps in the overall journey, such as automatic image templating, publishing, and sharing on social media.
Real use validated the product’s value, but it also exposed decisions that would limit Console as it grew.
The live product remains submission-centred. It does not yet store the complete programme as a domain model. Google Calendar provides scheduled occurrences, and Console associates uploaded content with them indirectly through the producer’s email, broadcast date, and sometimes start time.
Each upload creates a Submission containing content information and operational statuses for FTP, Drive, Mixcloud, and the website. The Calendar and Archive modules then group Submission records to reconstruct what users understand as one episode.
Because these relationships are inferred rather than durable, several failure modes remain possible:
For example, rescheduling an episode can weaken or break its connection with an upload because Console links them through changeable attributes instead of a persistent episode record.
Design response: model the radio domain first, then build workflows and interfaces on top of that shared structure.
To ship quickly, I created separate Resident and Admin interfaces. This simplified the first release but did not reflect how Paranoise works. Members move between production and operational responsibilities, so a rigid division by user type reproduces boundaries that the community itself does not have.
Design response: organise access and navigation around current capabilities and tasks rather than permanent categories of people.
Before cover generation was automated, residents could choose among different visual templates. The first automated workflow risked collapsing those choices into one uniform output.
Design response: automate the repetitive production work while preserving meaningful creative variation.
I began the redesign by mapping the concepts that structure the station: seasons, producers, residencies, episodes, episodes. The work moved from hand-drawn sketches into structured maps in JSON and FigJam, iterating until the relationships were clear enough for both people and software.
Two complementary maps guide the redesign:
I translated the conceptual model into an implementation-ready data specification, using an LLM to test relationships, expose inconsistencies, and accelerate documentation. The design decisions remained grounded in the operational model and the failure modes observed in V0.
The proposed model stores both what is expected to happen and what actually happens. This adds structure at the beginning, but removes repeated inference across Calendar, Archive, Centova, and publishing workflows.
The core trade-off is deliberate. The current model is operationally lightweight and centred on submissions. The proposed model is programme-centred: it creates a durable representation of how Paranoise organises seasons, residents, shows, episodes, and broadcasts.
Once the information architecture was stable enough to design against, I used it to identify user flows.
The flows follow the radio journey established during research. Programming, scheduling, production, sharing, and publishing become both the primary navigation of Console and the organising logic for its modules. Modules are assigned to different members, according to their current responsibilities.
For each flow I create detailed blueprints that capture user actions and system responses.
The interface extends the visual principles of paranoiseradio.com, drawing additional influence from music production software and hardware. The aim is to make Console feel part of Paranoise while giving operational information the clarity and density needed for repeated use.
Design decisions:
EPISODE, links it to the selected SLOT, and triggers the server upload, playlist assignment, and scheduling workflows.
Console has already changed episode submission from a sequence of disconnected operational tasks into a coordinated workflow. The live product has demonstrated measurable value while giving me the evidence needed to identify where its first architecture no longer supports the organisation.
Next steps include:
This project reflects how I approach AI-assisted product development. Building V0 quickly was useful: it put a real tool in front of residents, reduced work, and exposed constraints that a speculative design process might have missed. But I traded off speed with scalability.
The lasting lesson is to use rapid implementation with intent. A narrow first release can validate value, but the product must eventually be reconciled with the domain it serves. In Console, that means moving from automating a submission to building a web radio operations platform.
I shipped a focused tool that delivered measurable value, used real adoption to discover the limits of its architecture, and redesigned the system around the way Paranoise actually operates.
STEFANOS MONASTIRIDIS
0032485654553 STEFANOS@STMN-DESIGN.COM
LINKEDIN