What's the size of the team working on this?

I'm guessing you're OK with the tradeoff of your machine going down sometimes?

4 people but sometimes 10 with contractors.

Sure, there's downtime when the VPS provider is down. That's no different than "managed" services.

So you just have the dns record pointing to your machine's IP?

Do you have some kind of monitoring? What about logging?

That's correct. We used to use CloudFlare, but it added too much time to each request (speed is important to us). So now it's just pointed directly at the VPS.

Crashes are logged but I don't think anybody has ever looked at the logs. I'm not sure a crash has ever happened (the app is written in Haskell). Unexpected errors are saved to the database and can be viewed using the web. If we needed logs people could tail them from the VPS (ssh -t $WEB_HOST 'tail -f webserver.error.log'). I know, I know, that's crazy. I'm told real software companies are supposed to ship them to someone else, and then pay them to view the logs using a crappy web interface.

No monitoring. If the site is down customers will let us know, which has happened a few times. Monitoring wouldn't help much with shipping bugs anyway.

One can easily set up prometheus/grafana or ELK or sentry when you're that small on another VM.

I would like to have some insights about this as well

> In my previous place we had the monolith on cloud run.

How was managed a new deployment ? Could anyone push a new version ? Did it go through CI/CD ?

And about CI/CD, did you have something vaguely resembling it ? Was it all hosted ?

> Anything more complex than the above would to me be a bad smell - unless there were some very good reasons.

Yes, you would probably not need something more complex in that case, but then again, some companies with 5 devs start with microservices

All through CI/CD running on GitHub actions. There's really no excuse nowadays for not having good CI/CD processes.

We could have used googles cloud build, but the team knew GitHub actions well.

> If you know what the task is, hear the reminder to get back on task and still don't get back on task, you need emotional tools. This is beyond a single post, but look for a therapist who can help you with the emotional side of ADHD.

What do you mean by emotional tools ?

Anything that deals with changing your emotions to improve your ability to get tasks done, rather than just organizational tools (calendars, planners, todo lists, apps).

This includes but isn't limited to, CBT, mantras, positive self-talk, body doubling, breathing techniques.

At the end of the day, no calendar, todo list or app can make you do a task. If you're getting the reminder, in the right place with the right tools and enough time to do the task but you still don't do it then the problem lies elsewhere. Maybe you feel too anxious or overwhelmed. You need tools to address those problems, not just remind you what you need to do.

> I don't think there has to or should be a long wait. Most infrastructure builds, CI/CD etc are bloated, unoptimized and take too long for no reason.

I completely agree with you on that. However, the wait time is usually not enough for me to really switch tasks for an other "productive" one, because when my pipeline is done, I would just need to switch back, and it really would make it painful.

The option I see about that however, is jotting down ideas for testing later. But then you need to get the time for this optimization, and the optimization will also require you to wait while you test if the result is better.

I know that there is not silver bullet, I'm just trying to make the situation better for me and others in the team

Thanks for the answer !

It does not seem to do more than something like PagerDuty or OpsGenie, in that there is no integrated way to run specific actions on rotation.

But I did not know that GitLab did that, thanks for the link !

I did not know about them, thanks for sharing !

Do you know of any other small companies blog ?

Are there any issues you've encountered with this process at your scale ?

It was difficult to get some folks onboard. Writing RFCs is not always fun work. I used the Swift lang repo as a source of inspiration.

It's also tougher to think about all edge cases, and details upfront. But, it's best to pay the price early than having to rebuild something that's already done (wrong).