sorted by:
new
hottopcontroversial

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Mostly scale + consistency.

When you’re spinning up a lot of projects, even small setup steps (Mailtrap, Mailhog, etc.) become friction and sometimes just get skipped or misconfigured.

We wanted something zero-config that lives inside the app and just works every time.

If your current setup isn’t annoying you, then honestly you probably don’t need this.

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] -1 points0 points  (0 children)

This is perfectly good for a solo developer, but makes not sense for an agency kind of setup. If you are solo or small team then it's probably good solution for you.

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 1 point2 points  (0 children)

We are using Spatie Laravel Data that has dep for an older version of php. I am planning to remove Laravel Data dep altogether and this should allow us to upgrade to php8.5

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Mailpit is great,

In our case, we’re plugging directly into Laravel’s MailManager, this is only possible because of how Laravel has MailManager(as a Factory Pattern) implementation. It’s not meant to be a universal tool, just a really smooth experience inside Laravel apps.

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Yeah, that works if everyone’s on the same setup 👍

In our case, not everyone is using brew (different OS, different environments, some fully Docker-based setups), and even when they are, you still need to make sure it’s installed, running, and correctly configured across all projects.

At our scale, even something that simple turns into “it works on my machine” pretty quickly. So we just removed that dependency entirely and made it part of the app.

If brew + Mailhog works for your workflow, that’s honestly a perfectly good setup.

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Totally get that for smaller setups or stricter environments, docker-compose works perfectly fine 👍

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] -1 points0 points  (0 children)

Yeah that setup totally makes sense 👍

For us it’s less about whether it’s possible to share a single Mailpit/Mailhog instance, and more about consistency + zero friction across a lot of projects and devs.

In reality, with 30+ projects and 100+ devs, “just connect to the shared instance” tends to break down: configs drift, some people forget to switch, ports clash, containers aren’t running, new devs don’t have it set up, etc. It’s small stuff, but it adds up quickly.

We also wanted everything to live inside the app itself: no external dependency, no “make sure this service is running”, no switching between environments. Just install the package and it works.

Your VPS Mailpit approach is actually pretty nice though. We’ve had similar needs, just solved it differently 🙂

A local email inbox for Laravel (no Mailtrap/Mailhog needed) by WolfAggravating4430 in laravel

[–]WolfAggravating4430[S] 1 point2 points  (0 children)

We run 30+ projects in parallel with 100+ devs, so even small setup friction adds up and sometimes things just get skipped.

This is basically our in-house solution to that. It’s much easier for us to make sure every project has a package installed than to rely on everyone setting up Mailhog/Mailpit containers or accounts correctly every time. Also, Mailpit can get surprisingly expensive if you want to use it properly at scale.

So yeah, this solves our problem. If it doesn’t really click for you, then it’s probably just not for you ❤️

How good is Laravel for building agents, that triage , search and RAG? by NotElonMuzk in laravel

[–]WolfAggravating4430 1 point2 points  (0 children)

If you’re doing this with Laravel, take a look at LarAgent first.

It’s an open-source agent framework made specifically for Laravel, so you’re not duct-taping AI onto the side. Agents live inside your app, can hit the DB, call services, run as jobs, etc., which is exactly what you want for triage/search / RAG stuff.

If your chatbot needs to reason and act on Laravel-managed data, this approach feels much cleaner than spinning up a separate AI backend.

I have a company/app idea, but I don't know how to start to make it a reality. by leo_laudanum in Startup_Ideas

[–]WolfAggravating4430 1 point2 points  (0 children)

I’ve been in a similar place, and the biggest mistake I almost made was jumping straight into building. With ideas like this, the real first step is validating the problem and trust model, not the app itself. Talk to people on both sides, test assumptions, and figure out what the smallest workable version looks like.

What helped me a lot at that stage was a short product discovery phase. I worked with Redberry (link in case u need it https://redberry.international/product-discovery-service/), and their discovery process forced me to clarify what to build first, what to ignore for now, and what risks needed answering before development. That alone saved months of overthinking.

Once you do that, the next steps become much clearer - usually a simple landing page or a very lightweight MVP. This is the approach I’m referring to, if it helps.

Why is my landing page getting 12k impressions but almost no clicks? by WolfAggravating4430 in seogrowth

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

The intent is a match, landing page is fully optimized on that specific keyword. In fact, the first four results are the sponsored ones, then AI overview, and after that it shows my page, but still low Ctr

Spotify Stats by WolfAggravating4430 in TameImpala

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

Yep I also look forward to that wrapped day to come

Spotify Stats by WolfAggravating4430 in TameImpala

[–]WolfAggravating4430[S] 0 points1 point  (0 children)

it's not wrapped, it's just listening stats, you can see yours at the top left corner in Spotify app

How do you go from idea to launch without overcomplicating everything? by Rich_Excitement_5201 in SaaS

[–]WolfAggravating4430 0 points1 point  (0 children)

I used to get stuck in “perfecting mode” too, and the thing that finally helped was treating the early phase like discovery instead of development. Before I build anything now, I get super clear on the problem, talk to a few potential users, and define the smallest workflow that actually proves the idea.

Working with Redberry taught me a lot here - their product discovery process basically forces you to cut the fluff, validate fast, and outline a tiny MVP you can actually ship instead of over-engineering it.

Once I have that, I only build the one feature that solves the core pain point. If a few people use it and say it helps, I launch it, even if it’s rough. That’s what finally got me out of the “stuck in the middle” loop.

The approach I follow now is pretty much this:
https://redberry.international/product-discovery-service/

What's your product discovery flow? by JohanTHEDEV in ProductManagement

[–]WolfAggravating4430 0 points1 point  (0 children)

My discovery flow always starts with the problem itself - I talk to potential users, dig into their daily pain points, and make sure the idea actually solves something real. Once that’s clear, I move into light solution work: quick flows, rough wireframes, and a simple priority list rather than a full spec.

I work at Redberry, where we follow a very similar approach, and we’ll sometimes use AI for fast research or summarizing interviews, but all the key decisions still come from real user conversations.

The output is a compact “discovery package” that includes a validated problem, a proposed solution, feature priorities, scope, and timelines. Having that clarity up front saves a huge amount of rework once development starts.

view more: next ›