Typical development process?

I think you're going in a good direction.

Before setting up the database, make sure you fully scope (or at least as much as possible - requirements often change) what the application should be doing and ensure that you understand the relationships between the different entities in your system and any third party entities that you may need to interact with. You can sometimes find that you get a few days or weeks into a project and then find out about a particular business rule or relationship that you hadn't understood properly which could result in having to throw out all of your work.

Depending on the project it may be worth skipping the admin interface and instead filling in some seed data and designing the UI, some clients may not require much of an administrator panel or a package such as Laravel Administrator will suffice.

Thanks, Aeonax: that's reassuring. And I'll take a good look at that Admin package later today.

I guess where I was going with this is that I can't believe there isn't some sort of list/guide already. Sure there are loads of great videos and tutorials, but I'm finding myself having to re-watch/re-read these just to remind myself when and how to do basic things. To avoid this I've started building up an Evernote project to help me, but it's at that point I began to wonder if I'd missed something that describes a typical Laravel workflow process. I realise that no two projects will be the same, but there must be some commonality between them in the early stages.

I would recommend you using pseudocode on developing process. Take a piece of paper and write down what are you wanting to do and than follow those steps.

Different people focus on different things when building applications.

• Some might start working on the backend first and they won't create any views.
• Others might start with the front end.
• Some will go feature by feature.
• Others will go for one thing at a time in small steps.

Don't focus too much on the order of what you have to do next, you will figure that out on the spot when you need it.

Focus on the tasks you are working on, write them down in an app like Trello or some other task app and work step by step. You won't need all of the generated files right away.

Example:

Feature: 
1. Authentication

- Design the log in page.
- Design the log in form
- Implement log in functionality
- Implement log out functionality
- Implement roles in the system
- Implement permissions in the system
etc.

and go even deeper for each item on the list to figure out what input fields you will need and what else will that have like logging or caching, maybe some events, emails.

Write down all of the possible scenarios you can think of about how the user will use the application and from that list move on to the next list I wrote example of above.

Don't focus too much on the code or files at first, because that comes later in the process.

What the app will have, how it will be designed and how it will be used are more important steps than the code itself. I mean, code is important but as I said, it comes later in the process. You can even figure that out first before even touching Laravel. (if that's what you wanna do).

Some apps might not need this style of planning and design but it's good to have it in mind when building bigger apps that you plan on maintaining them for a long period of time.

'...but there must be some commonality between them in the early stages' - sadly, very little. Beyond installing laravel itself it'll vary between projects, between developers & over time. Sometimes you have a very rough idea of what you're going to be doing so maybe building up your views and models as you go, then thinking/altering/re-doing them and see what admin/reports are useful etc. Other times you might have a tight spec and be able to build your models & logic with barely any front-end code at all. And all the colours of the rainbow between :-)

For instance, I very, very rarely get a reasonable spec for projects I'm asked to do - so I tend to work on getting a functional user-facing interface done based on what I think they're wanting - let them play around with it then get feedback - keep repeating that until I've got what they are asking for and then refactor etc to make the code sane.

Thanks everyone. Some good points here that I hadn't considered.

The apps I'm building at the moment - for learning purposes - are all simple CRUD apps so they do seem to have a similar pattern to them, but I take on board the comments above about how things differ in the real world.

All good points!

First if you work in a team or will most of the Standard Operating Procedures are usually established.

For me as a freelancer/contract worker (many times the only developer) I develop in modular way as much as possible, a carry over from my C# and asp.net days. This way I develop and test a blog once, a authentication system with roles and permissions once etc. The key for me and I have posted in almost all similar threads is DOCUMENTATION. Scope document, feature set, explanation/mission statements, wireframes, db schema I even plan out namespaces, business logic($variables and method names) and folder structure along with descriptions of everything. Pain in the butt at first but once you get your docs set up it 1) easier 2) learn to can't work without them.

Client comes to me now and says I need a website for my lawn care and snow removal site. I need to tie in social media, how-to-blog, newsletter and coupon announcements and a way for customers to schedule/reschedule appointments.

I see: Authentication Socialite blog email newsletter sign up Customer area only with calendar

I grab: My Auth package, Socialite package, blog 70% code and 70 documentation done,

Find out what the client needs for newsletter (mailchip, campaign monitor smtp etc), grab that package I have done, and narrow down customer support area requirements.

I basicly have to build that 20% customer area, charge 100% of the time that is required, and I am almost done already. The documentation refreshes my mind, ensures the customer area has no conflicts (namespacing, business logic etc) and db schema issues as I combine the packages schemas and add and tweak as needed. A three month project in maybe two weeks and off to the designer....