Tasks: a Laravel API and a Next.js frontend, built test-first with Claude Code in a 4-hour assessment

Video transcript

Full narration of the 7-minute walkthrough, with start times.

0:00 Hi Chris. This is McKeen. This is my submission for the Caravea technical assessment: a small task tracker, with a Laravel API and a Next.js frontend. I'll show it working, walk through the key parts of the code, and explain how I used AI to build it.

0:22 Here's the shape of it. There are two apps in one repo. The api folder is Laravel 13. It's a plain JSON API, on top of SQLite. The web folder is Next.js 16. The browser only talks to Next.js, and Next.js talks to Laravel from the server. So there's no cross origin setup, the API address never reaches the browser, and the forms work even before JavaScript loads.

0:54 Here it is running. This is the task list, newest first. Each task has a status, a priority, and an optional due date.

1:04 If I try to create a task without a title, Laravel rejects it with a 422, and the error shows up right under the field. The Next.js form does no validation of its own. Laravel is the single source of truth.

1:19 Now I'll give it a title and high priority, and create it. It lands at the top of the list.

1:33 Editing works the same way. I'll mark this one as done.

1:42 The filter uses the status in the URL, so a filtered view can be shared or bookmarked.

1:52 And delete asks for confirmation first, then removes it.

1:57 Now the code, starting with the database. The migration is one table: title, notes, a due date, status, and priority. Status has an index, because the list filters on it. Status and priority default to todo and medium in the database.

2:14 In the model, the allowed statuses and priorities live in two constants. Validation, the factory, and the tests all read from them, so there's one list to change. Fillable protects against mass assignment. And the attribute defaults mirror the database defaults, so a freshly created task returns the same values the database stores.

2:37 Validation lives in a form request. Creating needs a title. Updating uses sometimes, instead of required, so a PATCH can change only the status, without resending the whole task. The due date must be a real date in year, month, day format. Status and priority must be one of the allowed values.

2:56 The controller stays small. Index validates the optional status filter, then uses when, to apply it only if it's there. It sorts newest first, with the id as a tie breaker. Store returns a 201. Update saves only the validated fields. Destroy returns a 204, with no content. And route model binding means a missing task returns a 404 automatically.

3:24 The resource decides the exact JSON shape, so the table can change later without breaking the frontend.

3:32 I wrote these seven feature tests first, watched them fail, then wrote the code until they passed. They cover the list and its order, the filter, creating with defaults, rejecting bad input, showing one task and the 404, a partial update, and delete. They run on an in memory SQLite database, so they're fast and never touch real data.

3:57 On the Next.js side, this file is the only place that knows the API address. Every request asks for JSON in its headers, so Laravel always answers errors as JSON, instead of an HTML page.

4:12 Saving goes through server actions. Save task handles both create and update. It sends a POST or a PATCH. If Laravel answers 422, it returns the errors, and what the user typed, back to the form. On success, it revalidates the list and redirects home.

4:31 The form is a client component, using useActionState. It shows each Laravel error under its field, keeps the user's input after a failed save, and disables the button while saving.

4:46 The list page wraps the data in Suspense. Next.js 16 turns on cache components by default. Task data must always be fresh, so instead of caching it, the list streams in behind a loading state.

5:00 Finally, a real browser test with Playwright clicks through the whole flow: validation, create, edit, filter, and delete. All five steps pass.

5:12 Now, how I used AI. Claude Code, with Claude Opus, is my coding driver. It wrote the first drafts of the code, the tests, and the README. I directed it, and reviewed every diff. I made the design calls myself. I chose SQLite so a reviewer runs it with zero database setup.

5:47 Here's one thing the AI got wrong. Claude's first browser test failed on the edit step. It said the status field was not visible. It assumed only one form was on the page. But Next.js 16 keeps pages you've left mounted, just hidden, so going back is instant. After visiting New task and then Edit, both forms were in the page, and the test grabbed the hidden one. I found it by listing every page section and whether it was visible, and fixed it by scoping the test to the visible page. A second one: the AI's training is older than Next.js 16, so I had it read the docs that ship with Next.js, before writing the frontend.

6:26 My setup is in the repo: context files for Laravel and Next.js, my own rules file, and agent skills for design first, test driven development, and keeping the code minimal. And the process is visible in the commit history: scaffold, tests and API, frontend, docs, and a fix I caught by testing a fresh clone.

6:49 Everything is in the repo, with a README that explains how to run it, and why I built it this way. Thanks for watching, Chris.