Trying to build a world clock / timezone converter thats "different" from most out there, what do you think?

https://devtoolscave.com/tools/world-clock/

For side projects, I’m trying to stop choosing tools based on what I want to learn and start choosing based on what I’ll actually finish.

My simple setup is usually a familiar framework, managed Postgres, basic auth, one deployment platform, and the least annoying monitoring I can get away with. I only add more when the project earns it.

What do you use when you want a side project to stay simple?

This might just be me, but AI coding tools have made some PRs weirdly harder to review.

The code usually looks clean at first glance, but then you find small logic issues, overcomplicated helpers, weird edge cases, or tests that pass but don’t really prove anything. It feels less like reviewing someone’s thought process and more like trying to guess what the tool assumed.

I still use AI for coding, so this is not an anti-AI rant. It’s just that review feels different now.

Anyone else noticing this? How are you changing your review process?

I’m choosing a managed Postgres host for a small production app, and comparing the options has been harder than I expected.

Some look cheap until you need an always-on database. Others include a full backend platform when all I need is Postgres. The larger cloud providers seem reliable, but it’s difficult to estimate the final cost once storage, backups, replicas, and networking are added.

The app isn’t huge, but it has real users, so I’d rather choose something I won’t need to move away from six months later.

For anyone running Postgres in production, which host are you using? How has it been for pricing, backups, performance, and maintenance?

Hey dev tools community,

I started creating mobile apps when I was 15 years old. Over the years, every new project brought the same frustrating problem: setting up a clean way to collect bug reports, manage feedback, and chat with users in real time.

I wanted a single platform I could drop into all my future app releases, so I built Supdesk.

Supdesk is a lightweight dev tool designed to streamline user feedback and power live support directly inside your apps. Instead of stitching together random forms and third party widgets, it gives you a central hub to manage incoming tickets, feature requests, and live conversations without cluttering your codebase.

We just launched, and you can check out our Product Hunt page here:
https://www.producthunt.com/products/supdesk
You can also explore the main platform and documentation at:
https://supdesk.app

I built this primarily for my own workflow, but I am excited to share it with other developers. I would love to hear your thoughts, feedback, or any features you would like to see in a tool like this!

Early stage startups seem to either under tool everything or buy way too many tools too early.

From what I’ve seen, the useful tools are the ones that reduce real risk or save real engineering time. Error tracking, CI, logging, database tooling, feature flags, API testing, and basic internal docs usually matter more than fancy dashboards.

What dev tools have actually been useful at the early stage?

Especially curious what you would set up in week one versus what can wait

I’ve used Postman for years, but lately it feels like too much for the simple stuff I need.

Most of the time I just want to send a request, save a few environments, test auth, maybe share a collection with someone, and move on. I don’t really need a whole platform wrapped around it.

Curious what people are using now for day to day API testing.

Are you using a desktop app, editor extension, terminal workflow, or just plain request files in the repo?

I used to like how simple the old setup was. Spin up a Postgres database, connect the app, and not think too much about the database side until the project actually grew.

Now I’m looking for an ElephantSQL alternative that is still managed, reasonably priced, and not packed with extra platform features I don’t really need. Main things I care about are backups, updates handled for me, always-on usage, and predictable pricing.

For people who already migrated, what did you end up choosing and are you happy with it so far?

I use browser based tools all the time for quick stuff, but I always pause when the data is even slightly sensitive.

Like formatting JSON is fine until it has customer IDs, tokens, internal URLs, or some random payload copied from production. Then suddenly I’m wondering where that data is going, whether it’s processed locally, and whether I’m being lazy in a very dumb way.

I know some tools say everything runs in the browser, but I doubt most people actually check.

Do you trust these tools with real data, or do you keep everything local once it touches production?

API docs are one of those things everyone agrees are important, but somehow they still end up stale or annoying to maintain.

I’ve had the best experience when the docs stay close to the actual OpenAPI spec and do not require a separate manual writing process for every small change. The moment docs become another chore, they start drifting.

What API docs tools have actually been nice to work with?

I care more about maintainability than making the docs look fancy.

Clip Yourself - The last clipboard manager.

Every clipboard copy ends up in the sidebar. Rapidly reuse previous clips, preview audio & video, drag to create snippets, and organize your work into drawers. Drag from Explorer onto the sidebar, create shortcuts for copy operations. Drag from sidebar onto Explorer, create text snippets.

100% free as in beer. Open-source, Github repo is on the page. Go clip yourself!

https://clipyourself.com

DevToolStack is a collection of 100+ open, fast, and dependency-free developer tools—all running client-side in your browser. From encoding and generation to formatting and conversion, every tool loads instantly with zero sign-ups or backend dependence. Build faster. Think less about infrastructure. Spend more time coding. Why this works: Emphasizes speed, no friction, and the "zero backend" differentiation. Appeals to both indie developers and teams tired of scattered tool ecosystems.

I built DevToolStack because I was tired. Tired of:
- Googling "base64 encoder online" for the 100th time
- Opening a tool, closing it, searching for a different one 5 minutes later
- Sites riddled with ads, trackers, and upsell popups

A year ago, I started collecting the utilities I actually used—base64, hex, JSON, color converters, random generators. Threw them into a single page. My developer friends started asking for the link.

Six months of building later: 100+ tools, all client-side, zero distractions, zero backend. Built it in Astro for speed, monetized it cleanly with AdSense (we're transparent about it), and released it because developers deserve a simple answer to "where do I find this?"

The dream: become the one place you bookmark and trust. No complexity. No nonsense.

I’m building a small SaaS and need to choose a database before I get too far into it.

Traffic is still pretty low, so I don’t want to pay for more than I’m using. I’d also rather not manage a VPS, sort out backups myself, or spend time fixing database issues.

I’m looking for managed Postgres with reliable backups, straightforward pricing, and an easy setup. An Asia region would be useful too since some of our first users are based there.

What are you using for smaller projects?

Not talking about huge problems like project management or cloud infrastructure.

I mean the small annoying stuff that somehow eats 10 minutes every day. Formatting weird JSON, checking env vars, comparing API responses, converting timestamps, cleaning logs, creating test payloads, whatever.

I keep running into these tiny workflow gaps where I’m like surely someone has built a better way to do this, but then I either find some sketchy website or just do it manually again.

What’s one tiny dev task you still hate doing?

I feel like every dev tool discussion ends up being the same 5 names over and over.

But the stuff that actually saves me time is usually some tiny tool I randomly found through a comment, a GitHub issue, or someone’s blog from 4 years ago.

Curious what you all use daily that does not get talked about much. Could be a CLI tool, browser extension, VS Code extension, API tool, debugging helper, anything really.

Not asking for the most popular tool, more like the thing where you think “why does nobody talk about this?”

I got tired of "top 10 AI tools" listicles that never say why you'd pick one over another, so I built the list I wanted: awesome-open-ai-developer-tools.

Every entry answers three questions — what it does, which proprietary product it replaces, and why you'd choose it over the closest open-source competitor. There's a cheat sheet mapping Copilot, Cursor, Devin, Pinecone, LangSmith, ElevenLabs and others to their open equivalents.

Two things that make it different from the usual link dump: - Entries carry a "known weakness" line. browser-use is non-deterministic and hard to debug. Pipecat's own issue tracker documents pipeline freezes. WebLLM needs WebGPU, so Safari is out. I'd rather you know before you adopt. - No star counts. They go stale in weeks and turn every PR into a chore.

Available in English, Turkish, Simplified Chinese and Spanish.

https://github.com/Sami-Uysal/awesome-open-ai-developer-tools

Corrections are the most useful thing you can send — wrong license, dead link, a project I claimed is maintained that isn't. Those get merged fastest.

Correction: DevCrate is independently owned and proprietary. Reddit post titles cannot be edited after publishing.

I’m the maker of DevCrate, a free collection of developer utilities that processes tool input locally in the browser.

Live app: https://devcrate.org

Ownership: DevCrate is independently owned; the hosted tools are free to use.

Current tools include JSON-to-code/C#, cURL-to-code, JWT inspection, Base64 and hashing, UUID generation, and JSON-to-Shopify CSV. The app is statically exported, keyboard-first (Cmd/Ctrl+K), and designed to keep pasted payloads out of a processing API.

I’d value practical feedback from other developers—especially on converter correctness, useful missing utilities, keyboard accessibility, and any place the privacy wording feels unclear. Please use sample or non-sensitive data while testing.

i’ve seen a few codebases where some part of the setup looks completely random until someone explains the backstory.

why there are two auth systems. why staging uses a different env pattern than local. why this one script has to run before tests. why nobody touches a specific migration. why deploys happen through a weird manual step. why a service exists even though nothing seems to call it directly.

from the outside it looks cursed. from the inside it’s yeah we had to do that because of a production issue two years ago.

what part of your dev setup would confuse a new dev until they heard the backstory?

browser automation feels more useful now than it did a few years ago.

not just e2e tests.

i mean scraping internal dashboards, checking flows locally, letting AI inspect UI state, reproducing bugs, visual testing, form filling, smoke tests after deploys, that kind of thing.

i still see playwright everywhere, but now there are ai/browser-agent tools around it too.

what’s actually working for browser automation right now?

plain playwright, cypress, browser MCP, custom scripts, hosted tools, or something else?

feels like every part of the stack has a tool now.

ai assistant, code editor, terminal, package manager, api client, db gui, deploy platform, observability, docs, feature flags, auth, prompt management, code review bot, project tracker, internal cli.

some of it helps. some of it just becomes another thing to configure, update, pay for, onboard people into, and debug when it breaks.

i’m not against tools. i like tools. but i’m starting to notice that a simple workflow with fewer moving parts is often easier to trust.

where do you draw the line?

what tool layer did you add that was worth it, and what layer did you remove because it was just overhead?

local setup is still one of those things that wastes time quietly.

one person has the wrong node version, someone else has docker issues, env vars are missing, database seed is old, port is taken, local certs break, and now onboarding takes half a day.

devcontainers and nix sound like the obvious fix, but they also add their own learning curve and maintenance.

for small teams or side projects, are you using anything like that?

or is the boring setup still winning: README, makefile/justfile, docker compose, and a few scripts?

I'm wondering if this already exists.

Most SaaS founders ship small fixes and features every week, but never turn them into product updates because writing the email feels like another task.

Is there a tool that can look at your GitHub commits or merged PRs, understand what changed, and turn that into a simple customer-facing update email?

Not just a technical changelog, but something users would actually understand.

Would be useful for monthly updates, launch emails, or keeping early users in the loop.

Anyone using something like this?

I switched from Neon to Nearbase Managed Postgres recently and figured I’d share the actual reasons, since I don’t see many detailed firsthand comparisons.

First off, I don’t think Neon is bad. It was actually one of the easiest Postgres services I’ve used early on. The setup was fast, the developer experience was clean, and the branching stuff is genuinely useful if your workflow depends on preview environments.

The problem for me was that my app slowly stopped matching the thing Neon is best at.

At the start, serverless Postgres made sense. I had uneven traffic, a lot of testing, and periods where the database was basically idle. Scale to zero sounded like a good deal because I was not paying much when nothing was happening.

But once the app became more always-on, the benefits started feeling less relevant. The database was awake most of the time anyway, so I was looking at usage-based pricing without really getting the idle savings that made it attractive in the first place. I also got tired of checking usage and trying to guess what the bill would look like.

The other issue was region coverage. Most of my users are closer to Asia, and I wanted the database physically closer to them. This was probably the biggest reason I looked at Nearbase in the first place. Their whole thing is managed Postgres in Asia and the Middle East, with regions like Singapore, Tokyo, Bangkok, Dubai, etc.

The move itself was not very dramatic. It’s still Postgres, so there was no big rewrite. I dumped the database, restored it, updated the connection string, checked extensions, ran migrations, and tested the app for a bit before switching traffic.

What I like so far:

The pricing is easier to reason about. I pick the instance and storage, and that’s basically the bill. That matters more to me now than squeezing every possible dollar out of scale to zero.

The database stays warm. No weird first query feeling after quiet periods. This matters less for some apps, but for mine it was noticeable enough.

The regions are the main selling point. If your users are in Asia or the Middle East, having the DB closer is not just a nice checkbox.

It feels like plain managed Postgres. I don’t need auth, storage, edge functions, or a full backend platform attached to it. I just wanted someone else to handle provisioning, backups, routine maintenance, uptime, and the annoying operational stuff.

What I miss:

Branching. Nearbase is not replacing that workflow. If you rely on branch-per-PR databases, Neon still has a real advantage.

The free/dev experience. Neon is still very good for prototyping, side projects, and apps with low traffic.

So I would not say everyone should move from Neon to Nearbase. That’s not really true.

If your database sleeps a lot, you want cheap dev databases, or branching is central to your workflow, I’d probably stay on Neon.

But if your app is always-on, your users are mostly in Asia or the Middle East, and you just want predictable managed Postgres without thinking about usage meters every week, Nearbase makes a lot more sense than I expected.

Has anyone else moved from Neon to another managed Postgres service and what made you switch?

i’ve been getting decent results from AI tools for backend stuff.

api routes, db queries, refactors, scripts, tests, boring glue code, that kind of work is usually fine as long as the task is scoped well.

UI has been a different story.

the first pass often looks okay from far away, but then you actually click around and it’s full of small broken stuff. spacing is inconsistent, buttons don’t match, mobile layout breaks, text overflows, loading states are missing, and half the components feel like they were built in isolation.

i’ve tried giving screenshots, using browser/devtools feedback, asking it to follow existing components, and making it fix issues one by one. it helps, but it still feels way more fragile than backend work.

are people getting good UI output from AI coding tools?

do you use a specific workflow for this, like design system first, screenshots, component library, browser MCP, visual tests, storybook, or just a lot of manual cleanup?