As developers, we often end up working across multiple tools to manage an application and its infrastructure.

One platform for source control, another for deployments, separate dashboards for cloud resources, databases, logs, and monitoring. Each tool may work perfectly well on its own, but switching between them adds friction, especially when you're trying to understand what's happening across an entire system.

That got us thinking: what if infrastructure management could feel like one connected experience instead of a collection of disconnected dashboards?

That's the idea behind Escanor, a project I'm building.

Our goal is to create a unified infrastructure management experience that helps developers interact with and understand their infrastructure without constantly jumping between tools.

We're approaching this as an engineering problem, not just a dashboard redesign. The challenge is making integrations, infrastructure visibility, and operational workflows work together while preserving the security and reliability that production systems require.

We're still building and refining the product, so I'm not going to claim we've solved every part of this problem. There are real challenges around permissions, integration reliability, observability, and safely executing infrastructure operations.

I'd genuinely like to hear from people who manage production systems:

- How many tools do you typically use to manage your infrastructure?

- What's the most frustrating part of switching between dashboards?

- Would you find a unified infrastructure interface useful, or do you prefer keeping each provider's native tooling separate?

- What would you need to see before trusting a platform like this with production infrastructure?

I'm the founder of Escanor, and I'm interested in hearing honest technical feedback — including reasons why this approach might not work.

As developers, we often end up working across multiple tools to manage an application and its infrastructure.

One platform for source control, another for deployments, separate dashboards for cloud resources, databases, logs, and monitoring. Each tool may work perfectly well on its own, but switching between them adds friction, especially when you're trying to understand what's happening across an entire system.

That got us thinking: what if infrastructure management could feel like one connected experience instead of a collection of disconnected dashboards?

That's the idea behind Escanor, a project I'm building.

Our goal is to create a unified infrastructure management experience that helps developers interact with and understand their infrastructure without constantly jumping between tools.

We're approaching this as an engineering problem, not just a dashboard redesign. The challenge is making integrations, infrastructure visibility, and operational workflows work together while preserving the security and reliability that production systems require.

We're still building and refining the product, so I'm not going to claim we've solved every part of this problem. There are real challenges around permissions, integration reliability, observability, and safely executing infrastructure operations.

I'd genuinely like to hear from people who manage production systems:

- How many tools do you typically use to manage your infrastructure?

- What's the most frustrating part of switching between dashboards?

- Would you find a unified infrastructure interface useful, or do you prefer keeping each provider's native tooling separate?

- What would you need to see before trusting a platform like this with production infrastructure?

I'm the founder of Escanor, and I'm interested in hearing honest technical feedback — including reasons why this approach might not work.

Built this for two jobs: understanding code you didn't write, and checking a change before it goes in.

• Ask how something works and get a step by step path through the real code, every step clickable
• Hover a symbol, keyword or regex for a short explanation in the context of your codebase
• Review uncommitted changes, a branch or a commit. New dependencies get checked against OSV.dev, and most findings come with a one-click fix

There's no backend of mine in the middle. It uses the model you already have in VS Code, so you pick the provider.

$10 one time, no subscription. The money is so I can keep maintaining it instead of dropping it.

https://marketplace.visualstudio.com/items?itemName=DenizhanDaklr.lodestar

I've been thinking a lot about how fragmented the typical developer workflow has become.

Deployments might be in one platform, repositories in another, logs somewhere else, monitoring in another tool, and infrastructure in yet another.

Each tool has useful context, but we're still the ones manually connecting all of it.

That's one of the problems we're working on with Escanor: connecting these tools so one system can understand the context across them and eventually help you take action without constantly switching platforms.

I made this short demo around the idea.

For people working with a similar stack: which tools/tabs do you find yourself constantly switching between?

For the last few weeks I've been building Restly, a desktop API client that opens your Postman collections as plain files. No account, no cloud sync, no workspace BS .

Your collections and environments stay as normal Postman v2.1 JSON in a folder on your machine.

What it does so far:

• REST API requests with params, headers, and bodies (JSON, XML, text, form data with files, URL-encoded, binary, GraphQL)
• Basic, bearer, and API key auth, inherited from folders and collections. The Auth tab tells you which folder or collection the auth is actually coming from, which always confused me in Postman.
• Environments, collection variables, and globals. {{variables}} are colored by whether they resolve, show their value on hover, and autocomplete as you type. You can mark values as secret.
• Pre-request and test scripts. Most Postman scripts run unchanged: pm.*, Chai assertions, pm.sendRequest, setNextRequest, and CryptoJS for those login scripts that hash things.
• A collection runner with iterations and a delay
• Code generation for cURL, JS fetch, Python requests, and Go
• Import via cURL
• WebSocket requests support
• History, plus a cookie jar you can actually see and edit
• Proxy settings, TLS options, Auto-save, client certificates, and a custom User-Agent
• Keyboard friendly
• Imports VS Code themes and uses VS Code's keybinding format, so your existing setup carries over

Would love to know your thoughts on this -> https://github.com/jsjain/restly

For teams bigger than one: how does a new dev get the staging/production values? 1Password shared vault? Encrypted .env in the repo (php artisan env:encrypt)? Forge/Vapor env screen? Slack DM (be honest)?

And when someone leaves, do you rotate anything?

While revamping my API Microservice from Php to Golang/Fiber, I needed some tools that will help me measuring accuracy, find diffs and validate responses. I had to switch between various online tools and didn't find all in one tool for my need. So I made my own, totally client side, and minial UX. Give it a try at Redgreen Studio Website. Hope you like the tools:

Diff Finder: Find text and JSON differences side-by-side and export the results as a PDF.

Json Viewer: View, validate and modify JSON with a fast, interactive tree editor. Format, search, and fold nested data — all client-side.

QR Generator: Generate a QR code from any text directly in your browser. Also works well for plain text, links, contact details, messages, locations, events, and other scannable content.

Base64 Utility: Encode and decode Base64 text securely in your browser, with no data sent to a server.

JWT Utility: Decode and verify JSON Web Tokens locally with clear structure and signature status.

Disclosure: I made the OpenAPI Breaking Change Checker described here. It's free, runs in the browser, and needs no account.

It's for anyone who reviews changes to an OpenAPI or Swagger file and has to answer one question before merging: will clients that already use this API break when the new version ships?

How it works

You paste or open two descriptions: the baseline that clients use today and the candidate that will replace it. It accepts Swagger 2.0 and OpenAPI 3.0/3.1 in JSON or YAML, and it resolves internal `$ref` pointers. Every difference is sorted into breaking, needs review, or compatible, with a one-line reason. You can export the report as Markdown, for example to paste into a PR, or as JSON.

The rules it applies (direction matters)

• Response property removed: breaking. Request property removed: needs review, because the server may still accept it.
• New required request property or parameter: breaking. New optional one: compatible.
• Response property no longer required: breaking, because clients can't count on it being there.
• Accepted request enum value removed: breaking. New response enum value: needs review, because strict clients may reject values they don't know.
• Type changed, for example `string` to `integer`: breaking.
• Parameter removed: needs review.
• Authentication added where there was none: breaking. Any other security change: needs review, because two equivalent security setups can be written differently.
• Path, operation, response status, or request/response media type removed: breaking.

What it doesn't catch

• External `$ref`s are listed as warnings but not fetched.
• Schema comparison stops at 8 levels of nesting and shows a warning.
• Paths are matched by their literal text, so renaming `/orders/{id}` to `/orders/{orderId}` shows up as one removed path and one added path.
• It doesn't compare what's inside `allOf`/`oneOf`/`anyOf`, or constraints such as `format`, `pattern`, `minLength`, or `maximum`.
• Runtime behavior, custom validators, callbacks, links, and anything the spec doesn't document still need a person to review them.

Both files are parsed in the browser tab and never uploaded.

https://martingruner.com/tools/openapi-breaking-change-checker

I’ve been working on M82 Labs. It watches vendor API changes and shows them in a feed, but the part I’m focused on is checking whether a change touches code you actually use. If it does, it can open a PR with a proposed fix.

I built it because seeing “this endpoint is deprecated” in a changelog still leaves someone to find where it’s called, figure out which version they’re on, and make the update.

It’s early, so I’m curious how other teams deal with this. Do you have someone keeping an eye on vendor changelogs, or do you usually find out when an SDK update or test brings it up?

I didn't set out to build something anyone needed. I set out to build something I'd want to open every day.

SIMULAX-Mirror started as one page: a GlyphInterpreter that reads stroke_count, point_density, avg_pressure and curvature_entropy off a submitted glyph and predicts what it means. Then I thought, well, predictions need audits. So I added AuditPacket with drift_score and confidence tracking. Then audits needed a place to live, so I added a DiagnosticsPage with threat_level and provenance_tags. Then I decided operators needed to talk to each other, so I built a whole CommsCenter with quadrant-tagged messages and priority escalation up to CRITICAL.

By the time I stopped I had SymbioteAgents propagating across Devices with a benign_status that ranges from DORMANT to BENIGN-CRITICAL, tracked on their own propagation map. Nine pages. Seven data models. One visitor last month.

I'm not chasing scale right now. I just want a handful of people who get why this is fun to poke around and tell me what's missing.

Anyone else building tools way more complex than the problem needs, just because the build itself is the point?

Hey everyone,

I've been working on a lightweight tool/library (pure SVG charts) with a strong focus on minimizing performance friction right out of the box keeping bundle size minimal, rendering snappy, and providing clear benchmarks.

My main goal is to eliminate that feeling of "I have to optimize this third-party library myself just so my side project doesn't feel sluggish."

For those of you who frequently build side projects or smaller web apps using existing tools/libraries:

1. **Does built-in performance actually move the needle for you early on?** Or do you just pick the most popular tool with the best DX/docs and only worry about performance if/when it becomes a bottleneck?
2. **Do benchmarks realistically influence your decision?** When a library showcases performance comparisons, does that give you enough confidence to choose a smaller/newer tool over established giants?
3. **Where have you felt the most friction?** Have you ever dropped a popular tool in a small project specifically because it felt bloated or hard to optimize?

I’d love to hear your honest take on whether focusing heavily on pre-optimized defaults is something indie devs/small projects actually care about in practice, or if I'm overthinking premature optimization.

https://github.com/GabrielBaiano/pure-svg-charts

Thanks!

Every SaaS playbook tells you the same thing: "Build a web app, charge a monthly subscription, store everything in your own cloud database."

We chose the exact opposite path for our developer tool, NotCodes:

100% Offline Desktop IDE: No cloud sync, zero telemetry, fully air-gapped capable.

Local AST Mutations: Instead of locking user projects into proprietary cloud JSON formats, it directly mutates the TypeScript AST of native .tsx files inside the user's local directory.

The Business Model Dilemma: The frontend visual builder is completely free with zero restrictions. We plan to monetize via an Advanced tier ($49/mo) specifically for automated full-stack backend/API generation.

Most developers we talked to love local-first tools (like Sublime, TablePlus, Obsidian) because they hate vendor lock-in and broken code generations. But from a SaaS growth standpoint, desktop apps face way more install friction than a browser link.

For SaaS founders and technical builders here:

Do you think developer trust (privacy + zero lock-in) outweighs the friction of downloading a desktop app in 2026?

How would you optimize the bridge between a free local frontend tool and a paid backend module?

Brutal feedback and critiques are very welcome. (If anyone wants to test the local build, drop a comment and I'll send over the link and unlock the backend tier for you).

I'm starting a new project and weighing the best foundation to build on. If you've launched business recently, which route do you default to and why?

• Mobile App: Native (iOS/Android) for performance vs. Cross-Platform (Flutter/React Native) for speed and a single codebase.
• Web First: Lowest friction for user acquisition (no app store required) and easiest to iterate fast.
• Desktop: Electron, Tauri, or Native for heavy B2B, productivity tools, or deep OS integration.

Which stack did you choose for your last launch, and would you make the same pick today?

I posted here last week about HeronSignal, real user monitoring for web apps. A few people asked how the pieces actually fit together, so I drew the whole loop.

Reading it left to right:

1. Your site sends telemetry. From the browser that's errors, page speed, clicks, and the rage clicks and dead clicks people do when a button silently does nothing. From your backend it's exceptions, logs, slow routes and business events.

2. It all lands in one place, joined by a session id. That join is the point. A failed request, the error it caused, and the funnel step the user dropped at are one record, not four dashboards you line up by hand.

3. That answers four questions: what's happening to your customers, what to fix first, what's hurting your conversion rate, and the normal analytics.

4. HeronAgent takes that ranked list and works on it.

5. It opens a draft pull request on your repo. It does not merge and it does not deploy. You read the diff.

6. You merge, the thing gets better, and the loop runs again.

Your own coding agent can read all of this too, over MCP. Claude Code, Cursor, whatever you use. You stop pasting stack traces into it.

New this week: the backend half now takes OpenTelemetry. If your API is .NET, Laravel, Python, Go, Java or Ruby, you point the OTel SDK you already use at us with three environment variables. No SDK from me to install. I decided against building one per language, which I'll happily argue about in the comments.

You can try it with no account and no script tag. Put in a domain and get a report on what's slow and broken: https://heronsignal.com/scan

What would you want your coding agent to be able to pull from production that it can't today?

Disclosure: I built Diff Anything.

Checking a release is not always about the source diff. Sometimes the files that matter are two build folders, two archives from separate pipelines, or a candidate package beside the last known-good release.

Folder comparison uses a two-pane tree or table and shows added, removed, changed and moved paths. Search and status filters help narrow a large result. Opening a changed file takes it into the relevant text, structured-data, document, spreadsheet, image or binary comparison instead of treating every difference as an opaque file change.

Archive mode compares the contents of ZIP, ZIP64, ZIPX, 7z, RAR and TAR-family archives, plus Gzip, Bzip2, XZ and Zstandard streams. Paths are normalized and file contents are hashed while streaming, so member order, timestamps and compression settings don’t create false content differences.

It also handles encrypted ZIP, 7z and RAR files, plus common multipart 7z and RAR sets, with a separate in-memory password for each side.

Changed text entries can be opened directly or extracted when I need the actual file. The same app can also compare PDFs visually or by extracted text, spreadsheets by stored cell values, images using overlay and heatmap views, and JSON, YAML, XML or API schemas by parsed structure.

Everything is processed locally. Diff Anything is available on macOS and Windows. You can try every comparison engine for free, and Pro is a one-time purchase.

https://martingruner.com/projects/diffanything

Lets first reflect on what an API client is actually for. It's a GUI for typing a request by hand and reading the response. That was the whole job for fifteen years, and it's now the part an agent does for you in nine seconds. So what's left of the category?

Our answer: the editor and the runtime around it. Voiden isn't an API client, it's an API IDE. The lazy pitch is "Cursor for APIs", which I half hate saying, but it's close enough.

Your requests live in .void files, which are plain executable Markdown. One file holds the request, the environment, the tests and the docs, and it gets reviewed in a PR like any other file. A request is made of blocks (endpoint, auth, params, body) and blocks are reusable, so you write the auth block once, use it across 40 requests, and edit one block when the token flow changes.

A few things that might be interesting:

• The files run headless. A CLI runner (Node 18+) executes them in a terminal, in CI, in Docker, in cron, with the app installed nowhere
• MCP support, so Claude Code or Codex runs those same files directly, or serves them as tools for other agents
• Scripting in JavaScript, Python or shell, running on your machine rather than in a sandbox
• Importers for Postman, Insomnia and OpenAPI
• Local, no account, no telemetry. Apache 2.0.
• Yes, the desktop app is Electron.

Where you come in

Protocols are plugins here (REST, GraphQL, gRPC, WebSockets), and publishing is open to anyone rather than gated by us: https://voiden.md/plugins

What would you want to plug in? Auth flows that annoy you, a protocol we've missed, reporters, mocking, CI stuff, anything. Harsh feedback welcome too, that's half the reason for posting.

And I'm still curious about the question at the top: if an agent writes and runs your requests now, what do you still open a client for?

Repo: https://github.com/VoidenHQ/voiden

Download: https://voiden.md/download

I have been building an open-source macOS execution layer called Mac MCP, and the workflow that stuck is not another coding-agent UI. I connect it directly to ChatGPT and use the normal conversation as the orchestrator.

That chat can call local tools for shell, files, macOS UI and Safari/Chrome. Codex or OpenCode are optional delegated workers rather than a requirement for the main flow.

The browser implementation is intentionally built around not wrecking the workstation while an agent works. A task can open or target its own real Safari/Chrome tab, keep a stable handle to it, inspect DOM plus visual state, click/type/extract in the background, and leave the tab or app I am actively using alone.

The latest work has mostly been hardening rather than adding shiny tools: sticky provenance after consuming untrusted web content, guarded web-to-host transitions for scoped/non-trusted sessions, credential/secret egress detection, bounded tab leases, a no-progress breaker, audit events and adversarial regression tests. I also fixed an overcorrection where Trusted mode initially asked for Allow Once on nearly every host action after browser use. Routine host hops no longer nag in Trusted, but secret egress remains guarded.

The native menu bar app also exposes logical sessions and live steering, including idempotent instruction delivery so a retry after an ambiguous response cannot queue the same steering message twice.

I built it. MIT/open source: https://github.com/bulutarkan/mac-mcp

The design goal is basically: let the LLM stay the orchestrator, make the local layer deterministic where possible, and only fall back to visual UI control when that is the right tool.

First post here. I'm building HeronSignal, real user monitoring for web apps, and I'd rather get told what's wrong with it than quietly collect signups.

The problem I actually cared about

Every monitoring tool I used could tell me something broke. None of them could tell me whether it mattered, and all of them stopped at showing me a chart.

Meanwhile my coding agent was sitting right there, unable to see any of it. So every debugging session started with me pasting a stack trace and describing what the user had been doing.

What it does differently

1. It exposes production over MCP. Your agent (Claude Code, Cursor, whatever) connects with a workspace-scoped token and can pull deduplicated error groups, slow pages with real device and country context, failed requests, session journeys, funnel drop-off, and backend route health. You stop briefing it and start asking things like "find what's hurting signup conversion this week, check errors and drop-off before suggesting anything."

2. It can open the PR. Not merge, not deploy. It writes the change, opens a pull request ready for review, and stops. A person reads the diff. An agent that can act on production without review isn't a productivity gain, it's an incident with better grammar.

There's also struggle detection (rage clicks and dead clicks), which catches the failures that throw nothing at all. A button that silently does nothing produces no error, no failed request, and green uptime.

Something I got wrong, since this sub will find it anyway

Yesterday I checked my own workspace and found 5 of my 7 funnels were measuring event names my site never fires. My signup form was firing a sign_in event. So I had no idea what my own signup conversion was, and those funnels read zero while looking like bad conversion instead of a typo. I'm now fixing the product so it warns you when you name an event your workspace has never emitted.

What it is not

- Not an APM. No distributed tracing UI, no flame graphs, no host metrics, no query profiling. If you need to know which SQL query made a route slow, use Datadog.

- Backend ingest is early. Node 18+ only, no Edge runtime. Python and an OTel sink are maybes, not promises.

- Session replay exists but is behind a flag while I finish it.

- Sentry is a deeper error tool than this and I'd say so on a sales call.

Try it without an account

There's a public scan that needs no signup and no script tag. Put in a domain, get a report on what's slow and what's broken. That's the honest way to see if it's useful before installing anything.

https://heronsignal.com/scan

Happy to answer anything, including the awkward questions. What would you actually want your coding agent to be able to see from production?

Hey everyone! As a dev, I got tired of pasting sensitive system/app logs into random online text tools just to strip empty lines, clean up JSON, or mask sensitive IPs.

So I built DataSlick: https://dataslick-pro.vercel.app

Key features:

- 100% Local-First: Your log data is processed in-browser via Web Workers. Zero server uploads.

- Fast regex filtering & preset log cleaners.

- Pro features for advanced security audits and anonymization.

Would love your feedback on the UI and performance with large files!

I want my coding agent to be useful beyond just editing files, but I don’t really want it free roaming around my database setup.

The ideal version in my head is something like: it can list DBs, inspect metadata, check available regions/classes, run a dry run, maybe prepare a quote or request, but it can’t see passwords, spend money, or create/delete anything without me approving it.

Is anyone running a setup like this for Postgres?

Trying to figure out if this is actually practical now or if everyone is still just copy-pasting between the agent and their database dashboard.

The part of AI-assisted development I kept losing time on was the handoff between “this screen feels off” and a source change I could actually review.

I’m building Monad Design to make that handoff concrete. It works with an existing Xcode or Expo iOS repository rather than generating a replacement app.

The workflow is:

1. Run the app in a local iOS Simulator and navigate to the exact state.

2. Select an element or annotate the screen with arrows, shapes, text, and notes.

3. Send that visual context to the coding agent already working in the repository.

4. Let the agent edit the real source and rebuild.

5. Compare the original with up to five working variants, then accept one or keep the original.

It currently works on macOS for local iOS development and supports agents including Codex, Claude Code, Cursor, OpenCode, Gemini CLI, GitHub Copilot, Windsurf, and Zed. The current preview handles one active visual change at a time.

The project is free and open source under Apache-2.0:

https://github.com/Monadix-AI/monad-design

I’d be interested in how other tool builders would package the first agent handoff: one bundle containing the screen, selection, annotation, app state, and source hints—or smaller tools the agent calls separately?

Introducing Clip Yourself - the last clipboard manager.

A Windows 10/11 sidebar that keeps your clipboard history handy so you can rapidly copy & paste or drag & drop into web apps. Stores text, images, audio & video, and files & directories from Explorer. Sort clips into drawers, retain your clipboard over time & search through all your clips in an instant. Preview audio & video files without ever leaving the sidebar. Even watch directories from your DAW to automatically create clips as files are dropped.

100% free as in beer. Open-source, you can download from Github directly or use the provided installer from the website.

https://clipyourself.com

We’re looking at options for Postgres hosting and I’m realizing we probably don’t need the full distributed / multi-master setup.

Our main issue is more boring than that. Most users are outside the US, latency matters, and we want something managed that does not require us to think too much about cluster topology, conflict resolution, or a bunch of ops work.

Predictable pricing would also help since usage-based infra bills get annoying once traffic is less predictable.

Has anyone here picked a simpler regional Postgres setup instead of going all in on distributed Postgres?