Selected builds · status stated plainly

Six builds, in the state each one actually is in.

Nothing here carries a number we cannot show you in the room.

00

How to read this page

A small vocabulary

We would rather this page be short than the claims be large.

Most studio work pages are assembled the same way: a grid of screenshots, a number set very large, a logo, a line about transformation. We have six builds to describe and no interest in decorating them. Each entry below names the project, says what it was, and states where it stands today.

The vocabulary is deliberately small.

Live
A real domain serving real people, maintained by us.
Delivered
Built, finished and handed over as it was meant to be used.
Playable
The game runs, plays and is ours — shown where we choose to show it.
Prototype
A real thing you can touch, built to prove a mechanic.

Which of those words applies is the most useful thing we can tell you about a project. A live site with a modest audience is a different object from a beautiful prototype, and blurring the two is how studios spend trust that took years to earn.

01

The index

Five entries · six builds

Pizzeria · brand and website

Live in production

Forno DPR

Forno DPR is a pizzeria, and the work was the brand and the site that carries it. It is live in production, which in practice means that what a customer finds when they search the name is what we made. A restaurant site has one duty before any other: someone standing on a street with a phone should find the menu, the hours and the way to order without having to think.

Everything decorative on that site is subordinate to that duty. The photography and the typography do the atmospheric work, because food is bought with the eyes first. The structure underneath is plain on purpose: sections you can find quickly, a number that taps, pages that survive a weak connection.

It follows the standard we hold to on every hospitality build. The people who run the restaurant should be able to change a price without calling a developer, because menus move with the seasons and a site that cannot move with them quietly rots.

Being live is not the same as being finished. We still watch it, and small corrections continue.

Differently: we would hand over the back office earlier. The owner learned the price edit in a week — a week of us editing it for her first, which she did not need.

  • Brand direction
  • Website design
  • Front-end build
  • Hosting and care

Photography studio · private client galleries

Live

Villiz Pixels

Villiz Pixels is our own photography studio, live at villizpixels.com. It exists because we kept needing something the market did not sell: a place where a photographer can hand a client a private gallery that looks like the work, and where that client can download full-resolution files without an account, a subscription or an argument.

The gallery is the product. A public portfolio is easy. The difficult hour is the one after the shoot, when a family or a brand needs their images in a form they can actually use, and the delivery is where most photography businesses lose the goodwill they earned on the day.

We run it as a working studio rather than a demonstration of one. Sessions are booked through the site, and the same standard applies to a single portrait sitting as to a brand shoot with a crew and a schedule.

Differently: nothing structural. The gallery is the shape it should be. The next work is cadence — photographing more often than we publish, which is a discipline rather than a feature.

  • Photography
  • Gallery build
  • Client delivery
  • Secure downloads

National day event · event experience site

Delivered

Naija Day 2026

Naija Day 2026 is an event experience built for a national day, and it was delivered. Event sites have a hard lifecycle. They must be useful for a few weeks, memorable for longer, and cheap to keep once the day has passed.

Designing for the peak instead of for permanence changes every decision, from the weight of the first screen to the number of pages behind it. The structure here is a single confident front and a small number of deep pages: what the day is, who is behind it, where to be. An interactive canvas celebration sits inside the experience, because a moment you can play lingers longer than a banner you scroll past.

Most of what would normally live in a menu sits on one scroll instead, because the visitor is usually on a phone and usually deciding whether to come at all.

Differently: we would cut the one section we argued hardest to keep. Every event site has that section. The argument was fun; the visitor did not care.

  • Event identity
  • Experience design
  • Interactive canvas
  • Front-end build

Games · built in-house

Playable

The games

We build games. Not as a side note — as a discipline that keeps the rest of the work sharp, because a game is unforgiving: if the loop is wrong, nobody plays.

Coventry Run in-world — the Whittle arches junction in the 3D city, chase view

Coventry Run — an open-world 3D web game, built with the doctrine of a certain viral Lagos runner: a real city as the content rather than a backdrop. Coventry Run is playable end to end, carries our original landmark art — the whittle arches and Pool Meadow among them — and exists because a game that recognises where you actually live earns a smile before it earns a tap.

Status: playable build, ours
Nelson's Race Car — Grand Prix Edition title screen, car on a country circuit

Nelson's Race Car — Grand Prix Edition — a single-file racing game built on modern tooling: Three.js, an offline-capable shell, and a production audit that passed clean. Seventeen of seventeen tests, high-tier performance measured against a real browser, and a build small enough to load fast on the phone it will mostly be played on.

Status: built and verified
Candy Rush title screen in the Villiz arcade shell

Candy Rush (Villiz Arcade) — the smallest of the three, and honest about it: a match-mechanics prototype built and tested in-house. It exists as the proof that the muscle extends to pure gameplay, not only worlds and race cars.

Status: in-house prototype

What the three share: they load in a browser, they need no install, and every frame of them was made by this studio.

Differently: the games teach more when they ship earlier and patch louder. A playable shell in March taught us more about the city than a polished build in June ever would.

  • 3D web games
  • Game engineering
  • Test and audit

The engine behind the frames

In service

Genesis.

Genesis sits slightly apart from the six builds above, because it is not a project we delivered for one client. It is the content operating layer we built in-house and run in service: client knowledge, market context, drafts, approvals, publishing and evidence in one controlled workflow, with a recorded human approval behind every post.

If you want to understand what Genesis does before reading its page, the short version: it gathers what your business knows about clients and market, moves ideas through a visible review pipeline, fires each post on a recorded approval, and records what the audience did with it. The films are how it tells its own story; the workflow is the product.

Read the Genesis page →

Differently: the authority gates were designed in from the start, not added later. It is the right design now; it would have been the right design sooner.

02

The parts you cannot see

Direction · verification · rollback

A screenshot cannot show the work that decides whether a build survives its first year. Every project here went through a direction board before code, a verification pass before launch, and a rollback path in case the launch went wrong. Those steps are slow and invisible in a portfolio, which is the usual reason they get skipped. They are also the reason we can tell you which of these are live without going to check.

Verification means the build is checked against the brief on real devices, at the widths people actually hold, before anybody is told it is ready. It is not a formality at the end. It is the stage where we disbelieve our own work on purpose.

Games make the same argument from the engineering side: a frame that runs once at speed proves nothing, so we measure, test and audit ours the way the race car was measured.

03

Systems in service

Automation that runs, not automation promised

The builds above had a maker. Behind them sits a quieter estate: pipelines, watchers and harnesses that carry the studio’s daily work and the client work inside it. This is part of what working with us buys — not automation as a slide, but automation with an uptime history, running this week and again tomorrow.

Content pipeline

Scans, packs and queues the day’s content; a post fires only on a recorded approval, and every publish returns a receipt with the outcome attached.

In service

Genesis

The publishing authority layer — client knowledge, drafts, approvals, scheduling, receipts and the rooms between. Its own page tells it properly.

In service

Operating rhythm

A morning brief and an evening pulse, delivered to the people who owe the decisions, with the state of every open thread attached.

In service

Spend watch

Every recurring subscription and resource watched; a renewal nobody has authorised becomes a cancellation task before the card is charged.

In service

Verification harness

Every build on this page shipped through it — layout measured at both widths, interactions probed, frames inspected, loudness gated. Machines first; a human verdict last.

In service

Production factory

Photo grading, campaign creative, video post-production and web builds, each stage parameterised — the next campaign is configuration, not construction.

In service

04

Capability index

Read as a warning, too

Read as a list of what these collectively cover, the page spans brand and identity, website design and build, e-commerce, photography, private galleries, event experiences, interactive canvas, 3D web games, game engineering with test and audit discipline, AI film, and hosting and care.

Read as a warning, it is a reminder that a studio which claims everything usually does one thing well and the rest adequately. We say so when a brief lands outside the set. That restraint is why the list is six rather than seventy, and why the games are described exactly as they are, neither dressed up nor apologised for.

05

In the room

What a page cannot hold

What we can show you, if it helps, is more than this page holds. A walkthrough of a live build with the analytics open beside it. The direction boards that were rejected before the one that shipped. A run of Coventry, played by the person who mapped it. The verification sheet, if you want to see what that looks like.

We would rather have that conversation than publish numbers whose provenance you would have to take on faith. Screenshots flatter; a screen share does not.

06 — If you would like to be on this page

Six at a time, finished.

We take a small number of projects at a time and finish them, which is the whole reason the list is short. If you are weighing a build — a site, an event, a game, a film with a presenter at the front — the useful first message is a paragraph about what the thing is for and who it serves. A wish list with a budget attached tells us much less.

We will tell you honestly whether we are the right studio for it, including when we are not.

Every status on this page is checked against the build it describes. Live sites are checked by loading them. Games are checked by playing them, and by the tests and audits recorded at build time. A statement we would not be able to check does not appear on this page. Where a build is unfinished, the page says so — the most expensive sentence in this trade is the one a client finds out was never true.

Statuses are re-verified before any claim about this page is repeated elsewhere. Corrections are made in place.