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