[QuadrupleA]

Writing your own little personal-use web apps can be really nice - not sure how common this is, but I highly recommend it. I did it for tasks, time tracking, invoicing, and personal finances, partly because Google and others kept "upgrading" and screwing up the UI & performance of the tools I was relying on.

Each took about a day to write, and is customized exactly the way I like it; if I need a shortcut key, a weird little feature, etc. I can do it. I'm kind of an optimization / performance nut too, so they all run uber-fast, no perceptible delay from click to page / screen loaded (Sqlite is great for these kinds of things). Data is totally private and under your control. It's really nice.

However, calendar was complicated enough that I just use Google's. Might be time to rethink..

[bob1029]

I totally concur with the approach of building your own internal tools like this. There is a lot of technical value (and also some unique risks) with DIY tooling that is not usually apparent to the business owner. Being able to expose new APIs and interface things together with other parts of your business in new and open ways is a very powerful and compelling capability. Just knowing that you can do these things in the future is a powerful tool, as it keeps developers' minds more open to consider new integration and automation possibilities. Sure, most turn-key solutions offer some degree of an API and integration options, but if you control the source and CI/CD pipeline of your tools, it's a completely different ball game. I am sure most of us are acutely aware of the downsides of relying on 3rd party APIs at this point.

Also, Sqlite is a database engine to be seriously reckoned with if you know how to run a few magic PRAGMAs on your initial connection. I am still in awe of what can be achieved in terms of throughput and latency by a single connection on a WAL-journaled Sqlite db. If you don't need your app or service to scale beyond a single process per logical deployment, I cannot see any justification for using another engine.

[platz]

I wrote my own bookmarking app last year https://github.com/jonschoning/espial ), and pretty sure I re-couped the value I get out of using it every day, being a somewhat obsessive bookmarker/archiver.

[MattSayar]

That's a cool project, and it's a cool trick to avoid a dependency on a large company's app. Buuut There's always going to be a dependency on your ISP, your web hosting provider's internet access and their hardware uptime/backup schedule, your neighborhood's telephone poles and wires, your utility company, your hosting company's utility company, etc. etc. etc.

We all stand on the shoulders of giants, and I try not to think about how fragile it all really is all the time.

[333c]

To circumvent this, you could host something on your LAN using, for example, a Raspberry Pi. To get access from outside that network, you could use some sort of VPN/proxy/tunneling, or you could host another instance with a hosting provider and sync the two.

[faissaloo]

My calendar app looks like this (granted I have a continuous write patch for nano but that's it): alias note="nano ~/notes.txt"

[proaralyst]

What tools did you use to write the apps? I assume you had access to a good web toolkit?

[QuadrupleA]

I used Python / Flask / Apache for server stuff, MySQL & Sqlite for storage, and jQuery & vanilla Javascript for frontend. But I'm sure any web stack would work.