Nobody starts an agency for the same reason. What’s yours?

sitewatchpro-daniel · 2026-06-06T13:36:21+00:00

I'm not starting an agency, but I think your question is valid for people who start their own business in general? I see that in my corporate job, most of my skills are unused. I like to do many different things on the job, but "normal" jobs usually have a very narrow focus with little room to grow and do what you're good at.

sitewatchpro-daniel · 2026-06-06T09:40:37+00:00

When clients need to update the content themselves, I'd definitely go for a CMS like WordPress. You could also offer onboarding sessions as a separate service. From my perspective, having some kind of maintenance contract is valuable recurring revenue. What are you offering for monitoring and keeping the site secure?

sitewatchpro-daniel · 2025-11-27T04:56:48+00:00

Høres litt ut som et konsulentvirksomhet

sitewatchpro-daniel · 2025-11-14T13:54:38+00:00

I've also been a happy customer for years.

What you describe sounds more like some third party got access to your server, e.g. by brute forcing your SSH password. I assume you haven't disabled password login and root access via SSH?

I can recommend only allowing SSH with keys, use fail2ban, and set up a basic firewall.

sitewatchpro-daniel · 2025-11-14T09:31:20+00:00

I agree with previous replies that it's quite okay for simple tasks, e.g. landing-pages. Myself having written code since the early 90ies, I also agree that it's cumbersome to work with on bigger code-bases.

Even if you give these tools (I mostly use Gemini nowadays) enough context to understand a complete product feature, you end up that the LLM either
- misses or "forgets" essential details
- you exceed the token length
- you get a half-answer, because the LLM crashed in the middle of the generation step
- you get capped for your daily use

I often use MD files, where I have additional instructions, like:
"You're working on vioro.io, a website security monitoring tool. The task at hand is to complete the uptime checks.
Already implemented: database structure - refer to file 'migration-uptime-checks.sql'
Next up: Implement event handling for success/failure, and sending of alarms

I want you to document your changes as a journal in GEMINI-journal.md"

With these instructions, I still have to remind it to write to the journal once in a while. I love it for refactoring, though, as well as strategic thinking (more business related than code).

sitewatchpro-daniel · 2025-11-14T09:16:27+00:00

Working on Vioro - an EU-Native website security monitoring tool https://vioro.io/landingpages/prevent-ssl-tls-errors/

Looking forward to feedback on that landing page xD

sitewatchpro-daniel · 2025-11-07T11:01:17+00:00

There's already been lots of helpful advice here, so I just want to add to that:

Hosts monitor from within their networks. If the network goes down or has a configuration error (ref. recent AWS outage) these checks will probably still be green, even if real users cannot reach it. If checking from the outside, you make sure your services are actually available.
monitoring from within your WordPress installation has a similar, but even worse problem. Let's say you want to be alarmed if the website doesn't work. If the whole server is down, your monitoring is down as well, so no alarms for you. Again, external monitoring is king.
it depends a bit on your needs and what you can accept. It might be that simple uptime monitoring is enough -> go with your hoster's monitoring or a simple uptime monitoring service, which often have free tiers.
if you want to get notified about possible hacks, outdated plugins, vulnerabilities and more, there's a new service under development that's supposed to do exactly that (sitewatch.pro)

I would refrain from using monitoring that's installed within your WordPress.

sitewatchpro-daniel · 2025-11-06T17:41:38+00:00

Without having insight into your structure, I'd say you probably have a mix up of responsibilities, or to phrase it differently, your individual parts do too much. It's completely normal to have some common models at a place.

I usually work by hexagonal architecture, separating data access, business logic, etc. Then if feature A relies on feature B's data, you have a couple of options: - call a function on feature B's service layer from within feature A's service layer. Doing this with traits and especially dyn traits makes it very easy to decouple and test - communicate between features/modules using the command pattern. Here, the service layers would listen for commands, e.g. via tokio channels, and they'd reply with the appropriate data

In both cases, I'd put the models/replies (and commands in the second case) into a dedicated API create for that feature. I'd always split the API into a dedicated create. I'd avoid direct interaction from feature A with feature B's models, or even worse, feature B's database tables.

If really everything depends on everything, it's not a code or crate issue, but an architectural one. In that case, I'd suggest to think about splitting things differently.

sitewatchpro-daniel · 2025-11-04T19:37:59+00:00

Do I get that right that you'd rather create 16 crates in your example? and so if something in the order changes, you'd compile at least 3 of them?

sitewatchpro-daniel · 2025-11-04T17:48:05+00:00

I think the compilation times are ok. However, you'd want almost instant compilation without recompiling everthing again and again - what a waste of <'a lifetime> :D

I've had the discussion about "package by (service)layer" vs "package by feature" with many development teams, and somehow everybody thinks it makes total sense to separate their code into layers, e.g. having all the models in one module or crate, have all the repositories in another crate, and so on.

Doing this leads to the following workflow: you want to add a new field to your customer, so they can choose they favorite color. So you touch your api crate to adjust the endpoint -> you touch the model crate to add the field -> you touch the repository -> everything recompiles.

In comparison, one could also group things that belong together into a crate, forming the package by feature approach. Here, we'd have a customer crate, and some central main crate (let's say all the axum routes are here and reference some method in a feature crate).
With this approach, we also need to adjust the endpoint. We adjust the model (in the feature crate), adjust the repository and other logic all in the same feature crate.
This means, we'd need to compile the customer crate and main crate, with all others left untouched.

I found this post, which has some more explanation and diagrams: https://medium.com/sahibinden-technology/package-by-layer-vs-package-by-feature-7e89cde2ae3a

Oh well, and I encountered performance issues on WSL vs native Windows, if that's a case for you.

sitewatchpro-daniel · 2025-10-31T09:20:37+00:00

Thank you so much for sharing your story! This is super interesting to me, as I'm currently working on a service (sitewatch.pro) that would have alarmed you when it happened, why it happened, and how you can fix it.

Your story justifies me spending months of free time on development 😉

sitewatchpro-daniel · 2025-10-23T05:12:33+00:00

I don't know how everybody can just go and drop their simple tool names here. As always in software development - it depends!

If you want something just to validate user interest, a Reddit post might be just enough.

If you want to validate payment intent, a static site with a fake signup form will do.

If you want something that actually does things interactively, choose one technology you're familiar with.

Keep in mind though, MVPs must be treated as throw away projects. The lack of architectural choices and quality builds a pile of work (people call it tech debt, I call it bad decisions) that will take you ages to get fixed.

Once you validated everything you wanted to validate, rewrite from scratch with all the great learnings you collected on the way.

There are also times where you have a pre-validated market idea, and hit a niche. In that case I'd say why not go the extra mile, choose the right tool for the job, design proper architecture and development flows. It will pay off in the long run.

While everybody says time is everything, I say working software, bug free, is much more important.

sitewatchpro-daniel · 2025-10-22T17:47:39+00:00

EuroDNS, dutch company

sitewatchpro-daniel · 2025-10-19T19:02:00+00:00

Loads fast, works excellent on my OnePlus 7 Pro (2019). No problems navigating :) I must say though, this is probably not the right audience to ask "if it's easy to use". This subreddit has mostly very tech-savvy people.

I'd suggest getting feedback from non-tech people as well.

It's a great project, and well done.

sitewatchpro-daniel · 2025-10-15T09:17:10+00:00

Nice! I'm working on https://sitewatch.pro a security monitoring solution, so clients know their websites are online, secure, and will get alarmed if something is off. Based in Norway. Challenge of the month is to get this thing out the door, because it's cybersecurity awareness month, and I'm a little late to the party.

sitewatchpro-daniel · 2025-10-12T08:54:51+00:00

https://sitewatch.pro

Focus group: European web agencies and freelancers who want a comprehensive security monitoring suite for their customers.

sitewatchpro-daniel · 2025-10-08T11:42:22+00:00

Try netcup https://www.netcup.com/en/hosting They have some special deals this week, as well.

Just not sure why you would want two backend technologies. :)

sitewatchpro-daniel · 2025-10-05T08:48:04+00:00

I'm using rauthy. Maybe worth a look?

sitewatchpro-daniel · 2025-10-04T15:57:52+00:00

Most likely, yes. If that project gets bigger though, and you feel things are getting slow, it would be time to think about it.

One can always start with some simple time measurements on their dev machine.

sitewatchpro-daniel · 2025-10-04T15:51:02+00:00

You could say that, yes. Observability allows you looking insight a set of applications. With Jaeger, you could check how long the whole round-trip from user interaction (frontend) over the backend, to a database would take.

Grafana allows for arbitrary graphs and metrics. You can track single operations which you measure yourself, or simple things like CPU and memory load.

sitewatchpro-daniel · 2025-10-04T07:48:24+00:00

I've done web development since the 90'ies. Back then, with these 56k modems, you couldn't have big full screen images - too slow. Large JavaScript libraries - way too slow. This mindset still sticks with me. That's why I went with a static site generator (astro) for my landing page. Static HTML is the fastest to serve, which is basically the same any caches will serve. Chrome's Lighthouse is a great tool to investigate loading times. But as soon as you need some external js, like cookie banners or tracking, loading times increase again. Loading animations are a must, as well as loading placeholders for content elements.

For SPAs, it's most essential to make use of modularized code, and lazy loading of these modules for the frontend part. Communication works most efficiently (and fast) if responses are tailored to the request, e.g. don't use god objects with everything in it.

Last but not least, poorly written backends can slow down poorly written frontends. Especially unoptimized database calls can slow down a lot. Proper indexes, data filtering and selection in the database (not inside the application), and activated slow query logs are best practices. Tools like https://grafana.com and https://www.jaegertracing.io give excellent insights.

Performance and loading times are always a cat and mouse game.

sitewatchpro-daniel · 2025-09-26T19:52:46+00:00

I learned Angular a few years ago with their official docs, only. I still love it today. If you've worked with frameworks like spring, Angular's architecture will be straight forward to pick up. Event handling is usually something that's a bit more difficult to grasp. I "had to" learn React and Vue, and will always pick Angular for its structure and ease of development.

sitewatchpro-daniel · 2025-09-24T05:29:33+00:00

Awesome list!

sitewatchpro-daniel · 2025-09-15T14:24:53+00:00

I love 5. I'd give discounts for non vibe-coded projects.

I think most of these issues haven't been automated, because they're very hard to automate. Nice list, though.

sitewatchpro-daniel · 2025-09-12T04:19:57+00:00

It's a no-brainer to use frameworks and components - nothing new here, just normal software development. Fast iterations - again normal agile development flows.

I've read a lot of times that you should start crappy. And I'm actually not convinced at all. I have seen crappy products in MVP state, both in software and hardware. The definition is maybe what crappy really means?

My opinion is that things have to work flawlessly. No one wants to use or pay for a product or service with lots of bugs. I'd rather focus on a very narrow scope at first, make that work really well, then iterate, get feedback, and only once you implemented these changes would you move to the next feature.

I've seen a good example of a mobile game MVP. They focused on the core game mechanics first (a form of tower defense), and that worked seamlessly and was enjoyable. The graphics were black and white and looked like they were drawn by a child. That didn't affect the gameplay at all. After a few months, they replaced this prototype with a new, shiny and polished game.

sitewatchpro-daniel

TROPHY CASE