Back in 2016, I had a package which was called LaraCogs. It was initially a boilerplate app. Then grew into a tool that added various files and adjusted a basic Laravel app. But due to consistent changes to Laravel's base app, it became cumbersome to maintain the package. My needs kept changing, so I scraped LaraCogs and put together a basic boilerplate app again. So I built Scaffold, and I'd like to detail why I think boilerplate projects are not bad.
Packages can be hard to maintain when built around third-party elements with consistent changes. Instead of making a few updates, you have to explore the impact of those updates on deeper stub files and the patterns they follow etc. I'm a big fan of Laravel Shift, which allows me to update projects of any size quickly. So running Laravel Shift on Scaffold takes all of 5 minutes tops. This process lets me examine those changes and apply them to any app which was based on Scaffold.
Similar to the maintenance benefits, I can easily make adjustments to Scaffold, and when these improvements are obvious and beneficial to other apps, I can quickly extract them and apply them to the other projects. This is very beneficial when exploring new dependencies. Its easy to place something inside a tiny app you know very well and then carry that forward versus having to examine its impact in a package, spin up a new Laravel instance, run the package, and test the effect on the app.
I use Scaffold for all sorts of experiments, testing ideas, testing integrations testing UI adjustments. This is the most significant benefit of a boilerplate project versus the LaraCogs package or things like Laravel presets. Presets and starter kits are handy tools but are a giant pain when rapidly testing and tinkering with a new idea. I can explore something in minutes on Scaffold and take those ideas to a new or old app, or leave them in Scaffold when needed.