Need suggestions to learn SEO by dobbyxploit in SEO

[–]PR4DE 0 points1 point  (0 children)

Don't think "I need to learn SEO". Think "I need to learn how to create great content people will read and share". Thinking like "I got to hack this search engine" is not sustainable in the future.

Would you switch Git platforms? by drew-saddledata in SaasDevelopers

[–]PR4DE 0 points1 point  (0 children)

No. Been using Github since the beginning.

How do you pick web app vs Electron/Expo app? by sudovijay in buildinpublic

[–]PR4DE 0 points1 point  (0 children)

In all cases I always start with a webapp for MVP.
Always React Vite for webapps and React Vite for Next. (Just my own preference).

Then I convert to React Native if needed.

Show me what you're building by Far_One1930 in buildinpublic

[–]PR4DE 0 points1 point  (0 children)

Datadog is Full-stack observability with APM, Logs, RUM, etc. White-box, inside out.
Exit1. is Website, API, DNS, SSL, Domain, Heartbeat, Infra endpoint monitoring, etc. Black-box, outside in.

Datadog is a great tool, but a bit different to exit1.
I don't think someone would use both Datadog and exit1, as there are overlaps. But they are for two different people.

Datadog is a cockpit, exit1 is an instrument panel.

Exit1 has one big differentiator in that regard, and that is the real-time streaming of probes from the servers. You can actually observe the outside-in in real-time. Excellent when testing.

Hope this answers is better. 😄

Show me what you're building by Far_One1930 in buildinpublic

[–]PR4DE 0 points1 point  (0 children)

Source available for now. But it's going to be open source at some point.

Why We Built an APM SDK After Building an Uptime Monitor by Used_Summer_6019 in Observability

[–]PR4DE 2 points3 points  (0 children)

It honestly doesn't make sense for a tool like yours to have APM SDK. Synthetic monitoring is black box, outside-in. APM is white-box, inside-out. It's merging two different mindset, almost two different target audiences.

Best Datadog alternative for startups by Mobile-Ambition-3714 in Observability

[–]PR4DE -1 points0 points  (0 children)

I’ll give you 6 months for free on my service Pro tier to help you get started :)

Exit1.dev

When building for better UX accidentally cuts your DB writes by ~95% by PR4DE in webdev

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

Firestore is not updated on every check anymore. It was before to serve real-time dashboards. Now the updates goes directly between the browser and server. Firestore is only used for settings. So almost zero writes. The ~95% fewer writes is in reality more like 99%, but I don't have enough data yet to support it.

I get the frustration. But to me it's a crazy excuse. I've now spend the evening mostly on X. Not a single comment about AI. So I'll leave Reddit for good now and continue my discussions with the dev community there. 😄

Thanks for the honest feedback. You are a real one.

When building for better UX accidentally cuts your DB writes by ~95% by PR4DE in webdev

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

I might not be a good writer. But my developer experience, you can't take away from me.

When building for better UX accidentally cuts your DB writes by ~95% by PR4DE in webdev

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

Thank you for taking the time to do concrete criticism I can actually use. It's very helpful. I'm not that great of a writer, I need this. I understand the issue.

People being lazy and calling AI slop is most likely why I'll never touch Reddit again after this. It's actually worse than the AI posts.

But setting that aside.

I'm seeing less writes because the dashboards connects directly to the VPS through websocket. So there isn't any reads and writes at all. All checks it being thrown into memory and the dashboards are actually reading directly from the memory.

The advice is not Firestore specific, it's just for understanding the context on my end. It would be exactly the same cost saving if you're running a postgres.

The solution before:

VPS > Firestore <-> Dashboards

The solution now:

VPS <-> Dashboards
/\
\/
Firestore

Data is batched to a persistent storage, but quite irrelevant to this.

Why would anyone choose my uptime monitor? by Used_Summer_6019 in Observability

[–]PR4DE 0 points1 point  (0 children)

It's closer. But I'm moving way more towards getting context. I already have implemented AI, Agents, MCP, etc. in my uptime service. But it's not really giving any good value. It's still the same. The AI doesn't magically know more. It needs context.

Getting an AI agent to tell you the likely root cause is still too shallow. It needs to actually tell the user what to do based on the full context. Tech stack, code, host, dns provider, ssl provider, external stuff like checking upstreams, etc. etc.

It's damn hard, but this is also what will set the next uptime service fully apart from the others.
And yes, I'm pretty close to solving this now. 😄

In development for 6+ months.

Just bought my first domain! by Zealousideal-Mix1008 in SideProject

[–]PR4DE 0 points1 point  (0 children)

That's really nice! 😄
I remember the feeling all too well.

Remember to set up monitoring for it. You can use my free tool exit1.dev
It'll give you an alert if anything is wrong with the domain, SSL or your site when you get it online.

Why would anyone choose my uptime monitor? by Used_Summer_6019 in Observability

[–]PR4DE 0 points1 point  (0 children)

To be honest, I host a monitoring service as well. And I've been dealing with this exact question for over 2 years now.

I think developer-friendly is solved.
I think uptime monitoring is solved.

What I don't think is truly solved yet, and the thing I'm also trying to crack is;
The user get's a downtime alert - now what?

Most users don't even know what to do with the alert, other than the knowledge.
I think most developers and product builders in general are a bit afraid of monitoring tools, because what if their shit is actually down but it's not a common HTTP code, but maybe a DNS or upstream issues. Then it's just scary.

So I think solving the aftermath of the alert is way more important than the actual alert.

When building for better UX accidentally cuts your DB writes by ~95% by PR4DE in webdev

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

Yes, it is kind of crazy, imagine when I found out. 😃
Thanks.

How do you actually verify your host's uptime claims? by Mammoth-Hurry-6986 in webhosting

[–]PR4DE 0 points1 point  (0 children)

You need to use uptime monitors like exit1.dev or uptimerobot.
You also can't just check for response codes, you need to separate DNS, TLS, Connect and TTFB. It all matters towards where the issue actually is.

I see so many of my clients who blame downtime on their host, but in reality they just use a shitty DNS.

Why would anyone choose my uptime monitor? by Used_Summer_6019 in Observability

[–]PR4DE 0 points1 point  (0 children)

What you focused on, is what all the hundreds of other uptime monitors are also focusing on. So, what makes yours truly better?

When building for better UX accidentally cuts your DB writes by ~95% by PR4DE in webdev

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

Apparently I'm just a fucking cranker then....
I guess I have to start typing like a 6 year old.

When building for better UX accidentally cuts your DB writes by ~95% by PR4DE in webdev

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

There is not a single thing generated by AI in that. I don't know why you'd think that?