sean2025's avatar

New to Laravel - a quick question on workflow

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.

1 like
8 replies
LaryAI's avatar
Level 58

Absolutely, it's a great question — and workflow varies a bit between teams and developers, but here’s how experienced Laravel developers typically approach building an app:

1. Planning and Prototyping:
Before you touch code, it helps to plan the features and user flow. If you need design approval, you might work with static HTML/CSS mockups first (sometimes using tools like Figma or Sketch).

2. Jumping in with Laravel:
If there’s no need for upfront design sign-off, most Laravel developers start directly with Laravel's tooling, as it provides a nice structure out of the box. This means:

  • Set up your Laravel project.
  • Create your routes in routes/web.php.
  • Create controllers to group related logic.
  • Build out Blade views for your pages.
  • Start splitting common parts into Blade components or layouts as you see repetition.

This way, your app quickly becomes maintainable and organized, and you avoid wasting time doing things twice (e.g., moving static HTML into Blade).

Typical Workflow Example:

  1. Define a route.
  2. Create a controller method to handle logic for the route.
  3. Return a Blade view from the controller.
  4. Develop your Blade template, using @include or components as necessary.
// routes/web.php
Route::get('/projects', [ProjectController::class, 'index']);

// app/Http/Controllers/ProjectController.php
public function index() {
    $projects = Project::all();
    return view('projects.index', compact('projects'));
}

// resources/views/projects/index.blade.php
@extends('layouts.app')

@section('content')
    @foreach ($projects as $project)
        <x-project-card :project="$project" />
    @endforeach
@endsection

Summary:

  • If you need sign-off, start with static HTML or design.
  • If not, definitely start directly with Laravel’s routing, controllers, and Blade templates, then extract layouts and components as your codebase matures.
  • Most experienced developers prefer to develop "in context," creating layouts, routes, and logic together, then splitting code for reusability and clarity.

Let me know if you’d like more detailed workflow tips, or advice specific to your project's stage!

DoubleClickDesignLtd's avatar

@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 :-)

2 likes
sean2025's avatar

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. :)

1 like
DoubleClickDesignLtd's avatar

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

2 likes
sean2025's avatar

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.

1 like
jlrdw's avatar

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.

2 likes
vincent15000's avatar

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.

2 likes

Please or to participate in this conversation.