Making African screen history easier to discover and harder to lose

An actor's career is bigger than the films the internet remembers.

Imagine an actor who started performing in the 1990s.

Their early career was built on stage. They appeared in films released on VHS, VCD and DVD. Years later, they moved into television and cinema. Today, they might be appearing in Netflix productions, independent YouTube films and creator-led comedy skits.

Now imagine searching for their filmography.

You might find their recent cinema releases on IMDb, a few streaming titles through Google and some YouTube appearances scattered across different channels.

But what happened to everything else?

The stage performances, direct-to-video films, supporting roles and older productions that never made it online? Even recent YouTube releases might be absent because no one has connected them to the actor's professional record.

And the same problem affects directors, editors, cinematographers, costume designers, producers and the companies behind these productions.

That's where MuviDB began.

I wanted to build a place where African screen entertainment could be documented across generations, formats and distribution channels, with the people behind each production connected to the work they've done.

Not simply a list of films, but a record of the industry that made them.

The familiar databases solved parts of the problem. Not the whole problem.

Before deciding what to build, I looked at the places people already use to discover and document films.

IMDb is useful for established film and television credits. Letterboxd focuses on watching, reviewing and discussing films. JustWatch helps people find where titles are available. YouTube has become an important distribution channel for African productions.

Each serves a useful purpose.

But when I looked at the broader career of an African actor, I could see how easily the records became disconnected.

A traditional filmography might document cinema and television work while overlooking an actor's significant body of direct-to-video productions. YouTube might host hundreds of films featuring that actor, but their credits are usually buried in descriptions, thumbnails or closing sequences.

And stage work has another problem altogether. A production might run for only a few performances, leaving behind a poster, an event announcement and little else.

I couldn't solve this by making another catalogue of popular titles.

I needed to reconsider what a filmography should contain.

A production shouldn't stop counting because of where it was released.

This became one of the first important decisions.

Cinema releases, streaming originals, YouTube films, home-video productions, stage plays, short films and creator-led work don't all behave the same way.

A stage play has performance dates and venues. A cinema film has theatrical release information. A YouTube production may have a channel, publication date and viewership data. An old VHS film might have no reliable online release information at all.

Trying to force them into an identical set of fields would either lose valuable information or fill profiles with irrelevant details.

So the direction was to give productions distinct identities and appropriate metadata while connecting them through the people and organisations involved.

The ambition was broad coverage, but that didn't mean every category would have the same completeness from day one. Recent digital releases are easier to document than a lost or poorly archived home-video production.

That difference had to be accommodated rather than hidden.

Then I had to separate a film from the places it appeared.

Consider a film originally released on VCD.

Years later, someone uploads it to YouTube. Another distributor makes it available on a streaming service, perhaps under a slightly different title.

Are those three different films?

No. They're different appearances of the same underlying production.

If each appearance became a new film record, its cast, crew and history could be split across multiple pages. But if I only kept the newest digital version, I'd lose the context of the original release.

This shaped the data model: the production is the underlying identity, credits describe the people involved, and release or availability information describes how audiences encountered it.

It seems like a small distinction, but it prevented the product from becoming a collection of disconnected platform listings.

Choosing what MuviDB would not become

This wider scope could easily have turned into several different products.

I deliberately avoided trying to build a streaming service, a full social network or a large editorial publication. I also resisted adding AI to workflows simply because AI was available.

Those directions would introduce different operating costs, content requirements and user expectations.

Instead, I wanted to focus on the underlying record and the experiences that made that record valuable.

The question became: If MuviDB knows what a production is, who made it and where it can be found, what can that information make possible?

A name in a cast list isn't a filmography.

Consider a YouTube movie description containing 12 cast members and a director.

Displaying those names on a film page would be easy.

But unless each name is connected to a recognised person, the information remains useful only within that particular page.

The next film could list the same actor under a different spelling, a shortened name or a stage name. Without a consistent identity, the two credits would never form a career history.

So I designed the relationships around four connected records: productions, people, credits and companies.

A person has a profile. A production has a record. A credit explains the person's contribution to that production. A company can be connected through its role in producing or distributing the work.

This meant one verified credit could update several useful experiences simultaneously.

Add a cinematographer to a film, and that relationship can appear both on the film page and in the cinematographer's career history.

Connect a producer to a production company, and the same work can contribute to the company's catalogue.

I wasn't designing four unrelated page types. I was designing different views into the same connected information.

An actor's profile needed to represent more than popularity.

This changed how I approached the people pages.

A useful actor profile needs an identifiable professional record: names and aliases where relevant, occupations, biographical context, individual production credits, roles and the history of their work.

But more importantly, the filmography shouldn't be determined by which platform made a title famous.

Take Ibrahim Yekini.

A filmography centred on mainstream cinema alone would offer an incomplete view of someone whose work is strongly associated with Yoruba-language and YouTube-distributed productions.

That is why MuviDB's people experience needed to accommodate those productions as actual career credits, not as unrelated video links.

I designed filmographies to connect users from the person to individual productions, and from those productions to their collaborators.

A visitor arriving because of a recent YouTube release should be able to explore the actor's earlier work through the same system.

And an editor or cinematographer deserves that same discoverability, even when their contributions happen behind the camera.

The same relationships made company profiles possible.

I encountered a similar problem with production and distribution companies.

A company might be involved in theatrical releases, streaming distribution or digital publishing. But those activities shouldn't be treated as identical measures of success.

For example, theatrical box-office performance tells a different story from YouTube viewership. Both can demonstrate a company's reach, but they shouldn't be combined into a misleading figure.

This informed the company experience.

A profile could connect an organisation to relevant productions while preserving the different ways those productions reached audiences.

FilmOne is a useful example of why this distinction matters.

Rather than reducing the company to a generic list of titles, its profile can demonstrate its catalogue and associated distribution activity without treating every channel as equivalent.

At this point, the foundation was in place.

Films could connect to people. People could connect to other films. Companies could be understood through the work they contributed to.

Now the question changed.

Discovery was the obvious starting point. But I didn't want it to end at search.

Someone might arrive at MuviDB knowing exactly what they're looking for.

They remember a title, recognise a poster or want to find an actor's latest film.

Others arrive without a title in mind. They might want a new Yoruba film, something in cinemas, a highly regarded production or another movie featuring an actor they enjoy.

Those are different starting points, but they can lead into the same connected records.

I organised the public experience around three recurring questions:

This guided the information hierarchy across film pages, people profiles, browsing and search.

A film page shouldn't require someone to scroll through every credit before finding the title, synopsis or availability. But it also shouldn't hide the cast and crew so deeply that the relationships become useless.

The solution was to give immediate viewing information prominence while keeping the wider production record accessible.

On mobile, this meant prioritising posters, essential details and viewing options, with additional information progressively available as people explored.

Visual evidenceFilm detail

01 / 02Auto / 30s

←→

Fig. 04

Immediate viewing information is prominent without disconnecting the wider production record.

Film detailMuviDB · Mobile experience

Then came the question a film database can't ignore.

Imagine finding an interesting film through Ibrahim Yekini's profile.

You've read the synopsis, seen the cast and decided you want to watch it.

What next?

Without a direct way to find the film, MuviDB would send you back to Google to repeat another search.

So I added distribution and availability as part of the discovery experience.

The important design choice was to keep the film record separate from its changing viewing options.

A film could be in cinemas during its theatrical run, appear on a streaming service later and eventually become available on YouTube.

The film remains the same. Its availability changes.

This allowed me to design a where-to-watch experience that could evolve without duplicating the underlying production.

It also influenced how platforms and channels were represented across the product. They weren't simply promotional buttons. They were part of the information connecting a production to its audience.

But availability doesn't tell someone whether they'll enjoy it.

Once people could discover and find films, another question emerged.

How should MuviDB represent audience opinion?

My earlier approach included user reviews. On paper, written reviews made sense. Someone watches a film, rates it and explains what they thought.

But not everyone wants to write several sentences after watching a movie.

Sometimes the response is simpler: I liked this.

Requiring a written review for that kind of participation adds effort that may not be justified.

So I began testing likes as a lower-effort signal alongside ratings, rather than making written commentary the primary requirement for expressing appreciation.

This wasn't about removing the value of opinions. It was about recognising that different kinds of opinions need different levels of effort.

And it led to a second distinction.

Audience appreciation isn't the same as criticism.

A film can be popular with audiences while receiving mixed critical responses.

Those perspectives are both useful, but combining them into one undifferentiated measure would remove important context.

I wanted room for lightweight audience reactions alongside more detailed critical assessments.

That meant giving critics their own identities and connecting their published reviews to the films they discuss.

Joseph Jonathan's critic profile provides an example of this connected approach. A review isn't just isolated editorial content. It can contribute to the film's record while remaining attributable to the critic who wrote it.

The design challenge was to help readers understand whether they're looking at audience appreciation, a rating or a critic's judgement.

Not every opinion needs to be represented in the same way.

The more of the industry I documented, the more I noticed what conventional discovery overlooks.

So far, the experience largely followed a familiar pattern: find a production, learn about it and locate somewhere to watch it.

But what about a stage play whose performances have ended?

Or an older film that is no longer commercially available?

Its absence from today's viewing platforms doesn't mean it has stopped being relevant.

The people who worked on it still contributed to the industry. The production may have been significant in their careers. Its cultural value doesn't disappear because there's no streaming link.

This introduced a different responsibility for MuviDB.

Live theatre required a different kind of experience.

A stage production isn't simply a film without a streaming link.

It has performance dates, venues, ticket information and often a limited run. Some productions return with new performances or different casts.

For someone discovering an upcoming play, the most important question may be where and when it's happening.

For someone researching the production years later, the value may be who performed in it, who produced it and where it took place.

So theatre needed to be represented with the information relevant to live performance rather than squeezed into the same presentation as a cinema release.

But its people and organisations could still connect to the wider MuviDB record.

That means a performer could have their stage work documented alongside screen credits without pretending the two are identical formats.

Awards and criticism also contribute to a career's history.

Filmographies tell us what someone worked on.

Awards, nominations and critical assessments can add context about how that work was recognised or received.

Rather than treating those as unrelated articles or promotional announcements, I began thinking about them as connected industry records.

An award can relate to a person, production, ceremony, year and category. A critic's review can connect a published assessment to a specific title.

These relationships make it possible to explore more than a list of releases.

They help preserve a broader picture of the industry around those releases.

By now, the challenge had expanded significantly.

MuviDB wasn't just helping people discover what to watch.

It was accumulating information that might be difficult to reconstruct if those connections were lost.

And that made accuracy increasingly important.

A beautiful film page can still be wrong.

It's easy to concentrate on the public interface when designing a product like MuviDB.

But a film page is only as trustworthy as the information behind it.

As I added more productions, I encountered the operational problems created by incomplete and inconsistent records.

Names appear with different spellings. Some YouTube descriptions leave out crew members. Older films can have unreliable dates. The same production may appear under multiple titles.

And sometimes two different records describe the same film.

This became more than a data-cleaning task.

Imagine an actor has two credits attached to separate records for the same production. Someone browsing their filmography sees a duplicate. Another person may open the less complete record and miss important information.

Even when the interface looks correct, the experience is broken.

One duplicate changed how I thought about record maintenance.

Suppose the same film appears twice.

One record contains the original title and more reliable release information.

The other includes a more complete cast and crew list.

Deleting one risks losing useful information. Keeping both allows the film's history to remain fragmented.

I needed a way to identify potential duplicates without assuming every similar title referred to the same production.

I explored deterministic matching and fingerprints built from record attributes instead of treating generative AI as the answer to every matching problem.

Where the available information was strong enough, structured comparisons could help identify likely matches. Where records were ambiguous or conflicted, the system needed to surface the differences for review.

The aim was not to automate away every editorial decision.

It was to make repetitive checks easier while preserving human judgement for cases that required context.

This became one of the most important lessons in the project.

A correct filmography depends on work users may never see.

At this scale, publishing a film became a workflow, not a page.

Early on, adding a record could be treated as a relatively small task.

But maintaining tens of thousands of records involves finding missing information, checking identities, correcting credits, handling media, reviewing sources and keeping distribution details current.

I realised I couldn't keep designing MuviDB as though the public website was the entire product.

The internal tools were becoming essential to the experience people saw.

This led me to organise operational work around different responsibilities, including editorial management, content production and outreach.

Each one supported a different part of keeping the database useful.

Social Studio: turning database records into reusable content

MuviDB needed people to discover the platform, not just the films indexed within it.

Social content was an obvious distribution channel, but manually assembling every film spotlight, actor card, watchlist and where-to-watch graphic would create another repetitive production process.

MuviDB already contained much of the information needed for those posts.

So why re-enter it manually?

I designed Social Studio around the idea that structured film and people records could feed reusable visual templates.

A film spotlight could draw on its title, poster, synopsis, release information and viewing channel. An actor card could use their profile and credits. Different layouts could adapt the same underlying information for Instagram, Facebook or vertical social formats.

This reduced the need to rebuild every post from scratch and connected public-facing marketing work back to the database.

It also exposed a practical design challenge: the same data doesn't automatically make a good visual.

Long film titles, unusual poster proportions, missing portraits and inconsistent synopsis lengths all affect the result.

The templates therefore needed constraints, fallbacks and editorial control rather than assuming every record would fit perfectly.

Artist Outreach: getting information closer to the source

Another recurring problem was verification.

A public film description might list only the lead cast. A production company's announcement could contain information missing from another source.

Instead of relying entirely on third-party publications and manual searches, I began exploring ways to involve the people and companies closest to the productions.

Artist Outreach helped organise that work.

The intention was to make existing records useful during outreach, so an actor, filmmaker, agency or production company could see what MuviDB already knew and help identify missing or incorrect information.

This thinking also shaped the public correction experience.

Rather than requiring a person to create an account and manually maintain a complete professional profile, I could begin with the available records and provide a way to flag corrections.

A more formal claim and verification model remains a longer-term direction.

The principle tying these internal tools together was straightforward.

Social Studio can assemble information into reusable designs. Matching systems can identify candidates for review. Outreach workflows can make record corrections easier.

But each still needs safeguards where the information is incomplete or uncertain.

Building the product exposed problems the mockups couldn't.

MuviDB has changed the way I work because the design decisions have consequences beyond the prototype.

An actor's name can be much longer than the name used in a mockup.

A film may have no poster. Its synopsis may be missing. A title might have several release dates. A person might have dozens of credits, or just one unverified appearance from an older production.

Those cases are easy to overlook when every screen is filled with ideal content.

But in a live database, they are part of everyday product behaviour.

I found myself moving repeatedly between designing an experience, building it, inspecting real records and revising the decisions that didn't hold up.

That loop affected the interface, the information architecture and the operational workflows behind them.

Instead of treating development as the final step after design, I increasingly used the working product to test whether the design made sense.

The hardest decisions were often about what not to build.

A project like MuviDB can expand endlessly.

There are opportunities to build social features, recommendation systems, advanced publishing tools, contributor networks, streaming integrations and much more.

But each addition creates another system that needs to be maintained.

I had to become more deliberate about which problems were worth solving now and which should remain outside the immediate scope.

The same applied to automation.

Using AI everywhere would have been tempting, but not every task needs a language model. Some identity and duplication problems benefit more from structured rules, clear review states and deterministic matching.

And some work still needs a human.

This pushed me to think more carefully about operational cost, accuracy and maintainability, not just whether a feature was technically possible.

What I would approach differently

If I were starting MuviDB again, I'd establish some boundaries earlier.

I would define the minimum useful record for each production type, separate confirmed information from uncertain information more explicitly, and design the provenance and correction workflows sooner.

I would also make the operating requirements more visible during early product planning.

It's easier to design a new public-facing feature than to estimate the ongoing effort required to keep its information accurate.

Those costs become clearer only when the product is running.

Where the product stands

Today, MuviDB contains more than 41,000 film records, 31,000 people profiles, 75,000 credits and 3,000 reviews.

Those figures show the scale of the system built so far. They don't mean every credit is verified, every filmography is complete or that the business model has been proven.

There are still missing records, unresolved data-quality problems and significant operational challenges.

The next phase is about improving accuracy, reducing manual work and building better relationships with filmmakers, production companies and institutions that can contribute authoritative information.

But the original problem is still the one guiding the product.

An actor might have spent 30 years performing across stage, home video, cinema, streaming and digital productions.

Their career shouldn't appear to begin in the year a major streaming platform first credited them.

And a cinematographer, editor or producer shouldn't become invisible because their work was released on a format that no longer exists.

Every database has a watchlist. I started building one because that is what you do, and I got as far as a save toggle on the film card and a watched flag in the schema before someone stopped me.

They asked a question I had no answer for: why would I keep a watchlist here, and then go somewhere else to watch? They were not describing a missing feature. They were describing a chore I was about to invent for them. What they actually came to MuviDB for was narrower and sharper — to see what their favourite actor was in, and work out which of those films was worth their evening.

So I stopped. The watchlist in the codebase is still exactly what it was that day: a save toggle and nothing else. No list page, no management screens, no empty states for a feature nobody asked to maintain.

What I built instead was the inverse. You follow an actor, and MuviDB comes to you — a WhatsApp alert when someone you follow turns up in something new. The need was real. The interface I had imagined for it was wrong. Follow three actors who all appear in the same film and you get one message, not three; that deduplication took longer to get right than the entire watchlist would have, and it is the part that decides whether people keep the alerts switched on.

1. 01

   A watchlist

   Save films, manage a list, come back to it. Familiar, expected, and a maintenance task handed to the user on a site they do not watch films on.

2. 02

   Follow an actor, get told

   The same need with the work removed. One message per film regardless of how many followed actors are in it, gated on release date and throttled, because an alert that annoys people is worse than no alert.

An industry professional put it to me plainly: when a Nigerian film performs, the figure is announced by the people who own it. The producer gets the headline, the director sometimes. The actors who drew the audience into the cinema are not in the sentence. The money is recorded. The contribution is not.

That is not a reporting gap, it is a credit gap, and it is the kind of thing a database can actually fix. So billing order stopped being metadata and became structure: awards, box-office figures and YouTube performance now attach to people according to where they sat on the bill, not only to the title they appeared in.

I was careful about what that is allowed to claim. Every attributed ranking carries its source — the publication, the page, the criteria, the year — and the schema says in writing that these are ranking facts for a year and a category, never lifetime actor totals. The difference matters. One is a record. The other is a number that sounds impressive and cannot be defended.

The same discipline runs through the rest of the catalogue. A complete credit means the stage work, the theatre run, the cinema release, the YouTube upload and the VHS and VCD era treated as one career rather than the handful of formats a Western database happens to index. For a Nigerian actor, leaving out home video does not shorten the record — it removes the decade that built the industry.

The trade-offs that shaped MuviDB most were not about screens. They were about money and headcount, because there is one of me and no budget to hire against. Every feature had to answer a second question after is this good: who operates this on a Tuesday?

Credit harvesting, copyright checks and catalogue enrichment all run as automation, because the alternative was me doing them by hand forever and the catalogue stopping the day I got bored. Storage is split between Supabase and Cloudflare so the heavy media sits where it is cheap and the relational work stays where it is useful — a cost decision that reads as architecture.

The part I am most pleased with is the least visible. Account claims, moderation and operational alerts were all supposed to need staff. Instead the product's operations are addressable from Telegram: approvals, blocking a scraper, checking who is hammering the API. The admin interface is a chat app I already carry, which meant no admin team, and no admin product to design and maintain either.

Social was the decision that cost something. I hired someone to run it, and watching the work go out taught me something I had not expected to learn: almost all of it was patterned. Pick a film, pull the poster, assemble a card, write a caption around a rating and a release date, post it on a schedule. MuviDB already held every one of those inputs. The job was not hard — it was repetitive in a way the database could absorb, and I had hired a person to do it because I had not looked closely enough at it first.

So I built the pipeline instead: scheduled drafting, caption generation, template rendering, a preflight that refuses to publish a film with missing data, and a rule that stops the same title going out twice in a week. It does the job more consistently than any schedule I could keep. It also ended someone's role, and I do not want to write that as a clean win, because it wasn't one. The lesson I actually took is narrower and more useful: look hard at whether work is systematisable before you hire a person to absorb it.

This is the part of the job I did not have fourteen years ago. Designing the interface is a smaller discipline than designing the conditions under which the interface can keep existing. On MuviDB those were the same decision, and the budget made that impossible to avoid.

1. 01

   Split storage across two providers

   Media on Cloudflare, relational data on Supabase. Not elegance — the storage bill is the difference between the catalogue growing and the catalogue stopping.

2. 02

   Automate the catalogue work

   Credit harvesting, copyright and enrichment run on schedules rather than on me. A catalogue maintained by hand is a catalogue with an expiry date.

3. 03

   Run operations from Telegram

   Claims, moderation and infrastructure alerts handled from a chat app. No ops hires, and no internal admin product to build and maintain alongside the real one.

4. 04

   Automate social, end the role

   I hired for social before checking whether the work was patterned. It was, and the database already held every input it needed. Automating it was right for the product and expensive for a person. Look at the shape of the work before you hire someone to absorb it.