Album Database

This was never a client project. I first wrote the album form in plain PHP, as a way to learn a bit of the language. Then I chose to build the same app again in Laravel, which made it my first Laravel app.

It was practice, but I treated it like a product: three rounds of testing with real people, and a full rebuild of the front end in Livewire and Alpine along the way.

The screens show both versions with the same seven albums, taken from the PHP version’s database. The Laravel version was always tested with generated data.

Two testers described the same layout problem in completely different words, and each was sure they had found something separate. Removing one misleading refresh button fixed both.

Three rounds of testing, each with one goal. Every tester got the same laptop, the same browser and the same questions.

1. 3.1I watched quietly and stepped in only when needed, looking out for frustration as much as for mistakes.
2. 3.2Raw notes became summaries and quotes became themes, each tagged with a usability heuristic.
3. 3.3I kept asking why until a complaint pointed to a specific design or logic choice.
4. 3.4Every finding became a change I could test, and I retested after each big one.
5. 3.5Reports were versioned in Obsidian, and an effort and impact matrix set the order.
6. 3.6Silence about a section usually means it works.

I started out not knowing why I was testing. By the final round it was a process I could rely on.

The plain-PHP version came first, then the Laravel rebuild, and every step on the way is documented.

The app stopped trying to keep up with the user.

1. 4.1Plain PHP with PDO first, then Laravel’s MVC.
2. 4.2Debugbar to trace every request.
3. 4.3Migrations, factories and seeders, so the data can be rebuilt at any time.
4. 4.4A many-to-many pivot table between albums and genres.
5. 4.5An N+1 query problem, fixed with eager loading.
6. 4.6A full rebuild from server-rendered PHP to Livewire and Alpine.
7. 4.7Safe cover uploads, with temporary files cleaned up.