- An internal apps platform built with bun, pg-boss, and railway

- A smart music setlist manager that downloads chord charts, creates spotify playlists, and automatically drafts emails with attachments and practice schedules

- A recruiting intelligence platform called Spotter that I built in a weekend[0]

- A voice-agent for a client in the banking sector, implementing deterministic workflows using openai realtime voice + finite state machines[1]

[0] https://www.youtube.com/watch?v=AOedMSddGDg

[1] https://blog.davemo.com/posts/2026-02-14-deterministic-core-...

A good interview on his background: https://www.youtube.com/watch?v=py4T1qv9bnQ

Immutability in OS updates is also something I didn't know I needed until I experienced it on Bazzite; pretty advantageous as a gamer using Linux with nVidia hardware these days.

This is my second go around on Bazzite, YMMV but I opted for Gnome over KDE this time and have had zero issues running the games I am into (WoW, PoE2) and no funky window management issues that I seemed to run into with KDE.

I'm considering a move to a Framework machine in the very near future, and still need to settle on a distro for dev; most of that is done on an M3 Max Macbook these days.

- [0] https://blog.davemo.com/posts/2009-04-06-yahoo-pipes-at-vend...

- [1] https://en.wikipedia.org/wiki/Delicious_(website)

DHH recently described[0] the approach they've taken at BaseCamp, reducing ~180 comprehensive-yet-brittle system tests down to 10 good-enough smoke tests, and it feels much more in spirit with where I would recommend folks invest effort: teams have way more tests than they need for an adequate level of confidence. Code and tests are a liability, and, to paraphrase Kent Beck[1], we should strive to write the minimal amount of tests and code to gain the maximal amount of confidence.

The other wrinkle here is that we're often paying through the nose in costs (complexity, actual dollars spent on CI services) by choosing to run all the tests all the time. It's a noble and worthy goal to figure out how not to do that, _but_, I think the conclusion shouldn't be to throw more $$$ into that money-pit, but rather just use all the power we have in our local dev workstations + trust to verify something is in a shippable state, another idea DHH covers[2] in the Rails World 2025 keynote; the whole thing is worth watching IMO.

[0] - https://youtu.be/gcwzWzC7gUA?si=buSEYBvxcxNkY6I6&t=1752

[1] - https://stackoverflow.com/questions/153234/how-deep-are-your...

[2] - https://youtu.be/gcwzWzC7gUA?si=9zL-xWG4FUxYZMC5&t=1977

Comments URL: https://news.ycombinator.com/item?id=44309563

Points: 8

# Comments: 0

Here's the pitch and some details, in case anyone else is interested in the idea:

> Supportal uses AI to generate internal tooling for startups that enables founders to scale customer-support without having to rely on engineering resources.

> Given some simple input context like tech-stack and a database schema, Supportal uses AI to auto-generate internal tools which allow customer-support to easily answer questions about and take action on customer-data without needing help from an engineer.

> Supportal offers founders a fully-featured self or cloud-hosted web UI.

Retool (https://retool.com), Zapier (https://zapier.com), Airtable (https://www.airtable.com), Superblocks (https://www.superblocks.com), and Google AppSheet (https://about.appsheet.com) would likely be primary competitors, although their products require heavy user interaction to build internal tools either through composition in a WYSIWYG editor, low/no-code solutions, or integrations expertise using a full programming language.

Although I'm no longer there, we actually evaluated and/or used all of these tools at Pulley, so I've had first-hand experience with their friction and where the gaps exist that Supportal would fill.

These tools are also all targeted at integrations-experts who have the technical knowledge to write code and spend time building the tool they want.

Supportal aims to generate the tooling you need intelligently via AI introspection and get you up and running with useful command and query tools to help your customer-support team take action and gain insights without help from engineering right out of the box.

My most recent experience comes building internal tools for Pulley; I built the initial version of the internal tools in ~3 weeks and added features to it within Pulley over ~2 years. Roughly ~2-3 months of full-time work spread over that time period.

Features were added as we identified gaps in our support agents ability to answer questions and take action, which often required dedicated engineering resources to help with, leading to a productivity loss for both groups.

That said, I haven't actually built out anything that would _generate_ tools like this yet, but I've done enough adjacent work in the codegen/AI space in the last couple years that I feel confident I could put the pieces together.

As an added benefit it also collapses all contained dependencies license files into a single licenses.txt file too!

- [1] https://github.com/vercel/ncc

There are times for both speaking and listening in our careers; as I've progressed further in my career I have felt it is often more valuable to exercise active listening.

Here are a few of my recent tracks that I think turned out ok:

- Rush-inspired synthwave: https://soundcloud.com/dmosher/rushing-in

- Lo-fi jazz/hip-hop: https://soundcloud.com/dmosher/the-soggy-sunday-swing

I’ve got some more experimental stuff up on Bandcamp as well: https://davemo.bandcamp.com/

I’d classify my style as synth wave meets 80s arena rock for the current track I’ve been working on :)

My learning path is here [0] and I’ve also been uploading works in progress to my soundcloud [1]

[0] https://learnmonthly.com/u/dave-mosher-e2bc26/andrew-huang-m...

[1] https://m.soundcloud.com/dmosher

Comments URL: https://news.ycombinator.com/item?id=16282670

Points: 1

# Comments: 0

"We later learned that Google’s gRPC Team was working on a gRPC-Web spec internally. Their approach was eerily similar to ours, and we decided to contribute our experiences to the upstream gRPC-Web spec (currently in early access mode, still subject to change)."

I suspect anyone attempting to adopt this implementation is going to hit similar issues until a release is finalized.

Comments URL: https://news.ycombinator.com/item?id=13278664

Points: 242

# Comments: 77

It seems the author is advising against forsaking other relationships and placing the entirety of the burden to supply all of our friendship needs on our significant other. I think there's wisdom in diversifying our relationship portfolio the same way we do with investments.

Comments URL: https://news.ycombinator.com/item?id=10308601

Points: 1

# Comments: 0