aculver
I recently re-read "Cyberpunk: Outlaws and Hackers on the Computer Frontier". It was published in 1991 and the first third of the book provides an early contemporary account of Kevin Mitnick. It's a great book that I first read in my high school library in the 90s and it completely captured my imagination.
However, I had never connected the dots that the subject of the last third of the book was Robert Tappan Morris, creator of the Morris worm, who went on to cofound Y Combinator! Paul Graham is also quoted in the book.
The book has aged pretty great. They added an updated epilogue in 1995 in the early part of the Free Kevin era, but honestly re-listening to the book in 2025, I was wondering where the updated Y Combinator epilogue was!
Hey all! Kinda surprised this has "taken off" haha
It has nothing to do with raising money. It has everything to do with the fact that based on the data we have, there is a large increase in the number of people trying Laravel who haven't coded before or are getting deeper into web development for the first time. That is a good thing!
The previous guidelines would have potentially directed them to configure Nginx or FrankenPHP manually, and while that is certainly possible for experienced devs, it's not the path to success for someone new to the framework.
We want them to be able to get their projects online as smoothly as possible, so that hopefully they become a long-lasting member of our awesome community.
It is no secret that PHP has a "pipeline problem". If you look at the year-over-year data from GitHub, PHP developers only grew 5%, JavaScript + TypeScript grew almost 90%. We have to get more people into our community and enjoying what's possible here. Previously, learning PHP from scratch was a barrier, now, thanks to AI, it's not. This is a unique opportunity to dramatically expand who can bring their ideas to life using Laravel.
In fact, I already have friends in "real life" who are building Laravel apps. They have never coded before.
Does that mean Laravel is going to just cater to "vibe coders"? Absolutely not. We're still building deeply technical features and content for experienced devs who are operating at high scale. But, it is existentially important to the health of the ecosystem and PHP itself that we do a good job getting people up and running on Laravel. They aren't going to know as much as you guys - even Forge can be overwhelming to them. Cloud gives them a simple on-ramp to production that doesn't require much technical knowledge. This is there to facilitate that.
That being said, we've moved this guideline to a "deployment" guideline folder so it's easy to disable or modify or remove to have your own deployment recommendations built right into your Boost install. And, of course, Boost itself is not included with Laravel by default.
[1] https://www.reddit.com/r/laravel/comments/1sn70d7/laravel_ad...
[1] https://x.com/andrewculver/status/1297575768520716288/photo/...
I'm the original creator of Bullet Train, although a number of people now work on it. It's been a fun journey to this point!
When I first started building Bullet Train, it was a relatively unique offering. There weren't that many full-featured "SaaS starter kits" out there, although there was some prior art. The biggest inspiration for Bullet Train was what Laravel Spark was at the time. In fact, one of the guys who had got me into Rails in the first place had started building his next product on Laravel so they could take advantage of Spark!
These days there are an abundance of SaaS starter kits available in most ecosystems. I've had the pleasure of meeting and interacting with the authors of a bunch of high-quality starter kits built in different languages and frameworks and some of them have told me they were inspired in part by Bullet Train. I love that.
If you're interested in Rails and SaaS, we're running a conference in Athens, Greece on June 1–2 this year and we'd love to have you! https://railssaas.com
Happy to answer any questions anyone may have!
I disagree that Bullet Train is "really overpriced". The features it provides to customers can save them hundreds of hours of development time in total. There are individual features in Bullet Train (the teams functionality, the Stripe integration, outbound webhooks, scaffolding real-time chat conversation threads onto models and an inbox for all of them, Zapier integration, just to name a few) that would each save most development teams at least $1,450 in development costs, and that's before you take into account the power of Super Scaffolding for code generation.
Bullet Train will save most development teams months in effort right off the bat. That's well worth $1,450 to the customers who have been able to get to market faster with components they know are being used and maintained across many different products. Bullet Train is only two years old, and there are already folks running seven-figure businesses around products that cost five-figures to build using Bullet Train. I'm not trying to imply it's magic, I'm just trying to point out that there are situations where $1,450 can be a no-brainer.
I love that you're starting with an open source base. If I knew when I started what I now know after two years of selling Bullet Train, I would probably do something similar. But you will need (as I've needed and as others who are doing similar projects have needed) help along the way. (For example, you'll definitely want to get the support of a designer.) Unless you want to bring those people on as partners, that help will cost you money, sometimes lots of it, so make sure you're charging enough for your premium components to pay for the help you need to make the product a success and the best it can be.
Best of luck! Wishing you a lot of success!
On the development side, I still think Rails is an excellent choice, but I also felt a lot of the same pain you're expressing, but instead of with server configuration, I started feeling it more specifically with the redundancy of putting together the same libraries over and over for each app.
To try to revive the joy of creating new projects, I created Bullet Train (https://bullettrain.co), which I describe as "Rails on Rails". It's an app template with authentication (Devise), authorization (CanCanCan), subscriptions (Koudoku), teams, invitations, OAuth integrations, etc. all wrapped in a consistent theme with a full feature-level test suite.
It also has a powerful code generation/scaffolding engine for pumping out CRUD views and controllers for the web, API endpoints, API documentation, and soon it'll handle your Zapier integration as well. (Posted a demo video of this here at https://twitter.com/andrewculver/status/934251715175395328) It also has a thin layer of conventions on top of vanilla Rails, like namespacing the public vs. account sections of an app. It's stuff that most of us were doing previously, just slightly different from app to app, and this is an attempt to standardize so we can build other magic on top of it.
As a demo, a few months ago I used Bullet Train + Heroku to build and launch a simple Trello clone in two hours: https://bt-cardboard.herokuapp.com/ . It's limited, and I haven't come back to it since, but I thought the end result was a powerful example of what you can get done quickly when you're using the right tools. (I have a video recording of the entire process which I'll upload to YouTube if anyone is interested in seeing it.)
Anyway, I wouldn't normally peddle my wares on HN, but the whole point of Bullet Train is to try to achieve new levels of developer productivity and happiness, which seemed relevant to the question you were asking. There's nothing quite like this in the Python world (I'm frequently told by Python developers,) but there probably should be, and I imagine it's just a matter of time before there is.
One of my favorite things about having so much screen real estate is eliminating the need for overlapping windows, which is really great when you're developing and have a ton of different things going on.
The idea with this new setup isn't that you would use the desk display for stuff you're actively working on, (I think that would be terrible for your neck,) but instead just as a place to put things you glance at occasionally or receive notifications from.
I only just set this up today so the verdict is still out on this new setup with the desk display, but a few initial observations:
- The texture of the display is similar to an iPhone or iPad, and it's a really great feel for your arms.
- The display gives off a little bit of heat, which is actually nice for resting your arms on.
- Because of the back of this specific display (Samsung 8-series) there is a tiny bit of give (e.g. a little bounciness,) on the part of the display where I'm resting my hands and typing. It's a _huge_ improvement over a hard desk.
The image is obviously not going to be as great as when you're looking at one of these displays head on, but it's not horrible either on the higher end displays. I've set mine up on a bit of an incline, which both helps the viewing angle and actually feels really great for my arms as well, but I'm not sure whether this will come back to bite me at all ergonomically.
Curious if anyone else has done anything similar and how they felt it worked or didn't work.
> "What advice would you give to hackers who are thinking about starting a company or making something on their own?"
> "Wozniak: First of all, try to have the highest of ethics and to be open and truthful about things, not hiding. If you have to hide something for company reasons, at least explain what you're doing. Don't mislead people. Know in your heart that you are a good person with good goals because that will carry over to your own self-confidence and your belief in your engineering abilities. Always seek excellence: make your product better than the average person would."
Build a machine that prints money.
Find a problem that regular business computer users are solving with some combination of raw effort and a spreadsheet to keep track. Write an app that accomplishes the same thing, but better, and in a mostly automated fashion, and charge them monthly for access to your tool.
It's a lot of work upfront, but the gains you make each month compound. Most of the customers you sign up this month will still be customers next month and you don't have to resell them. Instead you focus on selling new customers, who themselves will be around the month after that. Eventually, the amount of money the machine prints each month is greater than the effort you're putting into it each month, and you've freed yourself from exchanging time for money.
In terms of life hacks that are particularly attainable for developers specifically, I think starting a SaaS is near the top.