The Problem
Most portfolio tools are built for a single content type and a transactional relationship with the audience. A fine artist's practice is categorically different. Bandu's work spans durational performance, installation, sculpture, and drawing, each with its own documentation logic, its own metadata, its own audience. Performance work produces photographs of bodies in space, written scores, video stills, material traces of events that no longer exist. Artworks carry provenance, medium specifics, series affiliations, dimensions. Exhibitions belong to a professional record tied to institutions, cities, years, and the distinction between solo and group showing.
None of this maps cleanly onto a page with a title and a body field. And yet that is what most tools offer.
Bandu also had no digital infrastructure that matched the scope of his practice. Work from decades of international exhibitions existed across files, emails, and memory. The brief was to build a home for all of it, and to make it something he could manage himself, without a developer in the loop every time he needed to add a new piece.
The Process
The research phase began before any design work. Rather than looking only at artist portfolio sites, I widened the reference pool significantly: architects, musicians, interior designers, hotels, people whose work spans creative disciplines and who have found ways to represent that breadth online without flattening it. The question guiding the research was not "what do artist sites look like" but "how do people with serious, multidisciplinary practices present themselves digitally." The answer, across almost every strong example, came down to restraint, editorial typography, and letting images carry the weight.
Before designing anything, I sat with Bandu and asked him how he thinks about his work, how he wants to be represented, and what a website would need to do to feel like it actually belonged to him. What came out of that conversation shaped every structural decision that followed. He does not think in content types. He thinks in series, periods, and medium. An artwork is not a post. It is an object with a history, a place in a larger body of work, and a relationship to other objects. The website had to reflect that.
The hardest single decision was how to structure his work: what the categories would be, how an individual artwork should be presented, what connections the system needed to make between pieces. We landed on a principle that guided everything after it: minimal and simple, without sacrificing depth. Classic typefaces, Helvetica and Times New Roman, serif-led hierarchy, images given the space to speak as much as text. The design would not try to be expressive on Bandu's behalf. It would get out of the way.
WordPress came up early as a CMS option. We tested it and set it aside. The problem was not the technology itself but the structural model underneath it. Collections in WordPress do not naturally make meaningful connections to one another. Telling a proper story across a body of work, linking an artwork to a series, a series to a period, a period to an exhibition history, required a level of relational structure that page-builder tools are not built for. Building from scratch was the only way to model the content correctly.
The Solution
The site runs on Next.js with Supabase handling the database, authentication, and media storage. The public-facing side uses server-side rendering throughout, keeping pages fast and fully indexable. The architecture was designed around two distinct users from the start: the public visitor, and Bandu as the editor.
The CMS is entirely bespoke. The data model covers five primary collections: artworks, exhibitions, performances, CV entries, and site settings. Each collection holds the metadata that actually matters for that content type in the art world, not a generic set of fields borrowed from a blog platform. Artworks carry provenance and medium fields. Performances carry duration and location records. Exhibitions carry institutional affiliation data. The admin interface maps directly onto Bandu's professional vocabulary, so adding a new work feels like filling in a label or a catalogue entry, not submitting a web form.
The most technically demanding thing we built was the bulk upload system. Archiving a practice of this scale meant handling hundreds of works at once. The tool we built allows repetitive fields, year, medium, series, to be assigned across an entire batch in a single action, while still allowing individual edits for anything that changes piece to piece. All of that processing happens on the front end first, then moves to the backend through the API once everything is confirmed. It was not something I anticipated needing until we got deep into testing, when the reality of uploading a full archive made it obvious that field-by-field entry would be completely unworkable.
Testing surfaced a number of things I had not anticipated, and the bulk upload flow was the biggest. That experience pointed toward something we are now actively exploring: bringing AI into the system to help organise and suggest collection structures, identify thematic groupings, and surface connections across a large body of work. The idea is that an artist uploading a hundred pieces should not have to manually think through how they relate. The system should be able to propose it.
The Outcome
The site is live at bandumanamperi.com. Bandu updates it himself, roughly once a month, without any developer involvement. It functions as both an active portfolio for exhibition inquiries and collector contact, and as a permanent, structured archive of a practice that spans more than two decades.
The project clarified something that eventually became the foundation of AetherLabs: artists need back-office infrastructure built specifically for how they work, not adapted from tools designed for other industries. Building for Bandu was the first time I worked through that problem at full depth, from the data model outward. The bulk upload problem, the relational structure of collections, the question of how AI might assist with organisation rather than replace judgement: all of it seeded what AetherLabs is becoming.
What I Learned
The biggest shift this project demanded was moving from thinking about content management to thinking about how a specific person understands their own practice. Every structural decision that worked came from that conversation with Bandu at the start. Every decision that did not work came from assuming a technical pattern would be good enough. The research mattered, the architecture mattered, but the quality of the listening mattered most. That is the thing I carry into every project now.
Gallery
