Loading
[ about ]

I’m Oluwafemi Bamigboye, a software developer with a background spanning medicine, civil engineering and art.

I take a user-centric approach to building solutions, which is why I focus on the experience design of the systems I create. These include websites and web apps, full-stack software, interactive systems and unified systems that combine hardware and software.

[ AI ]

The rapid development of AI over the past couple of years has made writing code more accessible, but it doesn’t replace the need for sound, well-designed architecture. Over the past year, I’ve been refining workflows built on software development standards and best practices, giving AI tools a grounded framework for integration and execution.

Another theme is the steadily improving cybersecurity capabilities of these models, and the resulting need to harden both current systems and the new ones we build.

Here’s some of my work

Proposal prototype 2026

Car Park Website

AstroTypeScriptschema.orgWCAG 2.2 AAPlaywright

A car park website that people, search engines and AI assistants can all read and trust, in three languages.

Role
Sole designer and developer: audit, requirements, design, build, testing
Context
Self-initiated proposal to a family-run car park in a German city centre
Timeframe
52 hours planned, September–October 2026
Tools
Astro, TypeScript, schema.org JSON-LD, Vitest, Playwright, axe-core
Status
Proposal

The brief

A family-run car park earns from more than hourly parking: monthly spaces, a chauffeur service, advertising, a prepaid ticket and EV charging. A lot of customers, especially today, decide on a phone, through a search engine, a map app or an AI assistant, and act on whatever answer they find. My audit found the site failing them. Expired notices came first, the height limit differed between two pages, the free-space count was an image, and the English page renamed the business. Information around the website isn't generally easily accessible.

Two phone screens side by side. Left, a reconstruction of the old homepage: contact details, a logo, a photo banner, a welcome line and a green notice about prices from April 2023. Right, the new homepage: opening status, occupancy, entry height and prices on the first screen, with Call and Route buttons fixed at the bottom.
This item did not load.
The first screen, before and after. Left: a reconstruction of the old layout, rebuilt in the anonymised demo brand.

What it does

The site opens with what a driver needs: is it open, how many spaces, how high, what does it cost, with call and directions one tap away. Every service makes its own case, from monthly spaces to the chauffeur service and advertising, each with a way to ask. Notices appear and disappear on their own dates, and a date picker shows the owner any day. Visitors in three languages, search engines and AI assistants all get the same facts.

The new homepage on desktop. Five numbered callouts mark the opening status, the entry height, the number of spaces with occupancy, the price per hour with the daily maximum, and the Route and Call buttons.
This item did not load.
The first screen answers the driver. Prototype, anonymised demo brand.
This item did not load.
The date preview: Rosenmontag 2027 brings up a closure notice, the first Sunday of Advent a price cap and a Christmas-market notice, and a normal Tuesday clears them.

What it took

AAn audit before an offer

Instead of pitching a redesign straight away, I went through the live site page by page and wrote down what worked, as well as things that could use an update. The audit formed the foundation for the project and defined the scope of work to be done.

BOne set of facts for people and machines

Prices, hours and the height limit are written once, in one file. Every page in every language reads them, and so does the structured data that search engines and AI agents read. Carnival and holiday dates are computed, not typed, so the parade closure appears on the page and in the machine-readable opening hours from the same date.

CAccessibility

A screen reader and a search engine have the same problem: neither can see the page. Both need real headings, links that say where they go, and text instead of pictures of text, so building for one serves the other. Germany's accessibility law (BFSG) probably doesn't cover a site this small, but I held the work to WCAG 2.2 AA anyway and tested for it from the first page.

DTranslations that can't change a fact

The office writes only German. Before an English or Dutch draft counts, a check confirms that every number, time, price and link from the German survived and that key terms follow a glossary. If the German changes, the old translation stops showing until a new one passes. Legal pages stay German.

This item did not load.
The homepage switches from German to English to Dutch and back; the headline, navigation and facts change language each time.

Where it stands

  • The site is built: 12 pages in German, the 9 public ones also in English and Dutch
  • 254 unit tests and an axe-core scan that finds no WCAG 2.2 A or AA violation
  • Automated scans catch only part of WCAG, so a manual check with a screen reader is still to do
  • Next: a native speaker reviews the English and Dutch text, then the presentation to the owner. The real-brand version stays private until the owner agrees in writing

The content comes from the business's current website. I drafted the English and Dutch text with AI help.

Contact

0 / 3000