2026 has started off with a bang on Laracasts with the quantity and quality of content!

I had a fear that AI might have discouraged content creation, but AI doesn't yet engage quite like an expert instructor. Keep up the good work!

@sean2025 Awesome, thanks! Music to my ears!

I've recently started learning Laravel, and Livewire was one of the things that pushed me in that direction. I'm so excited to see Livewire 4 released and in action.

Thanks for all the effort you put into Livewire and Flux. I'm also enjoying the beautiful Flux Pro components!

Merry Christmas to everyone !

I would say that it depends on how each one works.

I mean each one has his/her own habits, furthermore it also depends on the type of project.

For example for several projects I have always started to design the database as a first step, but for less projects, I begin with the frontend with hard-coded datas before coding the backend and creating the database to have dynamic datas.

Some pre-design with pencil and paper has always helped me. Especially form design layout per customer request.

For example some like left down then right down. Some like left to right.

As far as other "workflow", each project is different. Stick to laravel MVC and laravel conventions. And each projects RBAC or authentication and authorization will be different depending on how the users interaction with the app is.

Take more time making sure all the security is correct, this will usually be the bigger part of any project. Ckeck, double check, then triple check security. When you think it's good, check again.

That's my workflow.

That's a great reply, Mark. Thanks for taking the time to share your process.

I have significant experience of the design stage, UX and some front-end development. But modern backend (and full stack) development is new to me.

Hi @sean2025, that’s a great question and one I can definitely relate to. I’ve been working in software design and development for about 30 years, across many different projects, teams, and technologies.

The first thing to understand is that every company and team has its own way of working, so what I’m sharing here isn’t “the” way just a set of general principles based on my experience. Over time, and by working with other designers and developers, you’ll naturally develop your own workflow. Also, don’t be too hard on yourself when things don’t go as planned; you often learn the most when something goes wrong.

Below is a very rough outline of how I typically approach a project when working with a small team (around five developers).

It starts with the idea. Most of the projects I work on are about solving a real problem either for a client or as internal tooling for a team.

Write a short project brief. I start with a simple text document describing the idea and listing the project goals as bullet points. I keep this intentionally short no more than one page, ideally half a page.

Pitch and discuss the idea. I share the idea with the team and gather feedback. If you don’t have a team, friends or peers are a great substitute. The goal here is to understand whether it’s a good idea, what the pros and cons are, and to let others build on the original concept. Two heads really are better than one.

Refine the brief and explore architecture. Based on feedback, I update the document and start thinking about system architecture and the tech stack. I consider infrastructure and application choices together, because each decision has trade-offs that need to balance out.

Review as a team (iteration). Once the document is more fleshed out, we review it together. This iteration helps surface key issues early and aligns everyone on the direction.

Create rough wireframes. I usually use Balsamiq to sketch very rough wireframes that focus on user journeys rather than visuals. Alongside each screen, I list the required functionality. This often takes a couple of days things always look better with fresh eyes the next day, and logic issues tend to appear during revision.

Gather feedback and iterate again. I present the wireframes to the team, gather feedback, and refine them.

Write functional specifications per screen. For each screen, I create a more detailed functional document: high-level bullet points, followed by happy paths, error states (“sad paths”), and required functionality. I send this, along with the wireframes, to the developers for review. Don’t be afraid of having others check your work it’s how you grow.

Finalise infrastructure planning. Once the application scope is agreed upon, we design the infrastructure: diagrams, services, micro-services (if applicable), networking, and deployment considerations. This is also iterative.

Security and compliance review. We do a security and QA pass across the whole project, covering both technical and legal aspects authentication, authorisation, data governance, GDPR, etc.

Project planning and task breakdown. We create the project in Jira (or Trello for very small teams), define phases, create epics, and assign work.

Design work begins. The designer creates the brand identity and UI direction. For small projects, this might just be a logo and UI theme derived from the wireframes. Again, this is iterative.

Build reusable UI components. Design templates are broken down into reusable UI building blocks. Once these are coded, pages can be assembled by composing these components.

Application development (Phase 1). We build toward clearly defined Phase 1 objectives.

QA, review, and learning. After Phase 1, we stop to test, review results as a team, and feed lessons learned back into the design, architecture, or process.

There’s a lot more that could be said, I’ve probably skipped another 15 steps in between but I hope this gives you a realistic sense of how experienced teams often move from concept to design to code.

I hope this give you some insight into a project. It not the complete set of stages but I just wanted to give you a flavour of the process.

Best of luck and happy coding

Regards

Mark

Thanks Mark for taking the time to reply. My question was more about the design to code workflow.

Tutorials often present a demo app in a way that builds on core concepts, rather than illustrate project flow. So I was wondering how experienced Laravel developers typically move from concept to prototype with respect to design. (Was it full static layout first, then broken up into views? Maybe then models, controllers, etc.)

The LaryAI bot responded above with a nicely detailed reply, which I found helpful.

I've also picked up lots of knowledge here about the Laravel options for reactive frontends since I wrote the original post. :)

@sean2025 this is hard to answer as everyone journey is different as I would have to say it depends on your experience in development.

For me I started with a very basic Laravel Course years ago which taught the me about the basic feature of the framework and then using my previous experience in PHP and software development I went from there.

If you can give me some idea of your experience level I'll try and direct you.

All the Best

Mark :-)

Best to wait for the stable release if it is a real world project.

Take a look at the changes per Beta version on the Livewire GitHub releases page. Some of those changes would likely be breaking changes for a project even as they reach Beta.4.

Best to wait for the stable release if it is a real world project.

Take a look at the changes per Beta version on the Livewire GitHub releases page. Some of those changes would likely be breaking changes for a project even as they reach Beta.4.

@sean2025 I'm so glad this series was helpful to you. Thanks for leaving this review!

This is a perfect introduction to the TALL stack for me.

I'm planning on having a basic prototype of my first Laravel/Livewire application running in the coming weeks. While I will go back and do some of the more in-depth series later, this series is ideal for getting up and running quickly with the different parts of the stack.

Thanks for putting together a great series!

Thanks for that link. I am a new subscriber, so I was not aware of the issues around XP. That wasn't a vibe I had picked up on before subscribing.

Personally, I have ZERO interest in being on any leaderboard, I wish there was an opt-out option for that kind of thing.

I had hoped to use accumulating XP and levelling up as a measure of progress and consistency as I go from starting PHP/Laravel to getting my first small prototype running in the coming weeks. I have much to learn in that quest.

However, it seems (from reading that thread) that someone who has set significant time aside for watching/rewatching videos may be suspected of gaming a competitive XP system. My XP is currently frozen without explanation.

@JeffreyWay Would it be possible to allow subscribers to opt-out of XP leaderboards entirely in return for a reliable, predictable XP/Level progress score? These subscribers would then be beyond suspicion of gaming the system, as they are solely interested in personal tracking. Thanks.

There is a thread about XP for watching videos here https://laracasts.com/discuss/channels/site-improvements/forum-leaderboard-updates-and-question

The Forum part I know nothing about a change.

When doing the lessons with an exam, or even checking out the comments on the tutorial, it is useful to have that alert. I cancel it as often as I accept it. It's only for a couple of seconds anyway.

There may be a bug with XP. I have noticed the same, though I only started last week. Despite 90 lessons this week, I've been stuck on 7600 XP for a few days.

XP is a fun feature, but I was also hoping to use it to set daily goals as I try to get up to speed with PHP and Laravel. Unfortunately XP is not updating for me either for activities on Laracasts.

(Really enjoying the tutorials anyway, and already getting value from the lifetime license!)

Thanks Jeff. Simple and cleary explaned. Keep up the good work.

@sean2025 You're making lots of great points! I hope you enjoy your time on Laracasts. Lifetime license is an incredible value-for-money deal for sure. I was a Laracasts customer long time before I became an instructor :)

I had some issues with videos stalling briefly over the weekend, while showing a spinner. I downloaded those instead using the download button under the video. They only took seconds to download and other content was fine, so it wasn't the speed of my connection. Yesterday, all lessons I tried streamed ok..

I do have some problems with some end of video test exams out of sync or not resolving the answers. I haven't tried those in a different browser so can't say whether those are not working or just that I'm hopeless with PHP :D

I've started to look at some of the excellent courses here on creating Laravel applications.

I know that course instructors may take an approach that differs in workflow to how an experienced developer would approach the same task on a project. Understandably, instructors want to isolate different parts for clarity, rather than do all together... like explaining Tailwind, Alpine, Livewire, etc.

Do experienced Laravel developers normally work their way up from full "static" and styled html layouts to then splitting the layouts into views, components, controllers, etc.? Or, is it recommended to start within Laravel and map out views, routes, and logic first? Would you opt for the latter approach if you don't have to submit layouts first for approval?

I'd appreciate any advice on a recommended workflow.

You can't prevent it, and you shouldn't try to. You have to make the app more resiliant. There are countless order systems on the internet, and they don't crash on back navigation.

I've noticed that some GSAP animations and elements may not work properly, or even display, if a user is using Ad blocking. That would be a consideration when designing with it.

Definitely test with a cleared cache and Ad blocking in place to see if visitors may have problems seeing or interacting with your content.

This is really great information! I love some subtle animations for effect and hinting, but really dislike overly animated interfaces and pages.

I have even had to abandon sites in the past due to janky animations making it difficult to browse the content. A pity, as you can tell that the developer put a lot of time into those pages.

I'll add that most people probably don't know how to turn off motion in their system, unless they suffer from acute effects and have been advised on accessibility. They probably won't do it globally for one site or app, so the subtle approach recommended here is a good way to go.

If all these Laracasts tutorials are as good as the first ones I have jumped into, I'm going to be spending a lot of time with my new Laracasts lifetime purchase :)