CompassPad — Find what was just built.

Open WebUI is a chat front end that runs on your own machine or server and connects to local runtimes such as Ollama and to hosted model APIs. It provides the interface a hosted chat product provides, without the conversation leaving your infrastructure. The feature set covers what a team expects from a chat interface: multiple conversations with history, model switching, prompt presets, document upload for retrieval, and web search integration. Multi-user support adds accounts and roles, so a small team can share one deployment with separate conversations and access to different models. It is a front end rather than a model runtime, so it needs something to talk to. The project is open source and self-hostable, and the tradeoff is operational: running it means running a container, a database, and whichever model backend it is pointed at.

Resend is a transactional email service aimed at developers. The API is a single POST with an API key, and the platform's distinguishing feature is that templates can be written as React components rather than as HTML strings or a hosted drag-and-drop editor. The product covers the parts of email that are easy to get wrong: domain authentication with SPF, DKIM, and DMARC records; a broadcast product for marketing sends kept separate from transactional traffic; and webhooks for delivery, bounce, and complaint events. Sending is tracked per message so a support question about a specific email can be answered from the dashboard. Developers adopt it for the API ergonomics and the React template story. Teams with an existing marketing automation suite sometimes keep that for campaigns and use Resend only for the transactional path, since the two have different deliverability expectations and different unsubscribe rules.

Dify is a platform for building applications on language models. The core surface is a visual workflow editor where a pipeline is assembled from nodes: a model call, a retrieval step, a conditional branch, a code node, and an output. The same project can be exposed as a chat application, an API, or an embedded widget. The retrieval layer is built in. Documents are uploaded, chunked, embedded, and indexed, and a knowledge base can be attached to a node so a pipeline answers from your own material. Prompt templates, variables, and model configuration are part of the workflow rather than scattered through application code. The platform is open source and can be self-hosted, which is why some teams adopt it over a hosted orchestration service. The tradeoff is that a visual pipeline is harder to review and version than code, so teams building something complex often move the final implementation into their own codebase once the shape is settled.

Neon is a managed Postgres service built on a storage layer that separates compute from data. Because the data layer is copy-on-write, the service can create a full database branch in seconds, and that branch starts as a pointer into the parent's history rather than a physical copy. The practical result is a database workflow that resembles Git. A team can branch production for a preview environment, run migrations against the branch, and throw it away without touching the parent. Point-in-time restore uses the same mechanism, so recovering to a moment before a bad migration does not require replaying a backup. Compute scales to zero when idle, which suits development and preview environments that sit unused most of the day. The tradeoff is cold-start latency on the first query after a suspend, and a connection model that expects a pooler for serverless clients.

Slack is a messaging platform for organisations, organised around channels. A channel is a named conversation that can be public, private, or shared with an external organisation, and membership is a deliberate act rather than an accident of a contact list. The structure is what distinguishes it from a group chat. Threads keep a reply attached to its parent, so a channel is not consumed by a side conversation. Search covers message history and files, and a shared channel lets two organisations work in the same space without exchanging accounts. The platform's second half is the app directory and workflow builder. Incoming webhooks, slash commands, and bots let an external system post into a channel or accept a command from one, which is how alerts and approvals end up where a team already is. The cost is per-seat pricing and the fact that an organisation's conversation history lives in a vendor account.

Astro is a web framework built around content. Pages are authored as components with an HTML-first template syntax, and by default the framework ships no client-side JavaScript for them. Interactive pieces are declared individually and hydrated on their own. The island model is the core idea: a page is mostly static HTML, and any component that needs interactivity is marked as an island with a hydration directive. That island can be written in React, Vue, Svelte, Solid, or plain JavaScript, and different islands on the same page can use different frameworks. The framework also ships a content collections API that validates front-matter against a schema at build time. Astro suits marketing sites, documentation, blogs, and content-heavy storefronts where interaction is limited to a few widgets. It is a poorer fit for applications where most of the interface is stateful and interactive, because the island boundaries then multiply and the static-first advantage shrinks.

Continue is an AI coding assistant that installs into VS Code and JetBrains IDEs. Unlike assistants tied to one vendor's model, it is configured with a model provider, so it can point at a hosted API, a local runtime, or an internal endpoint. The feature set covers the common assistant interactions: inline autocomplete as you type, a chat panel that can see the open file, and edit commands that apply a change across a selection. Context providers decide what the model sees, which is how a question can include the current file, an open diff, or a documentation source. The project is open source, and configuration lives in a file in the repository, so a team can share a setup. The tradeoff is that the assistant is only as good as the model behind it: a local model avoids sending code away but performs below a frontier hosted model, and the team has to make that trade explicitly.

Cal.com is a scheduling tool in the category that Calendly defined: a bookable link that reads a calendar's availability and writes an event when someone books. It is open source, which is the main difference, and it can be self-hosted so booking data stays on your own infrastructure. The product supports the expected scheduling features: multiple event types, buffers, minimum notice, round-robin distribution across a team, and routing forms that send a booker to the right event based on their answers. It connects to Google, Microsoft, and Apple calendars for availability and to conferencing tools for meeting links. Self-hosting is the reason many teams choose it, and also the main cost. Running the platform means operating a Postgres database, the application, and its background jobs, plus keeping up with releases. Teams that want scheduling to be someone else's operational problem use the hosted plan instead.

Drizzle is a TypeScript ORM built around the idea that the query layer should not hide SQL. Schema is declared in TypeScript, queries are written with a chainable API that maps closely to SQL clauses, and the generated types flow from the schema definition rather than from a separate code generator pass. Migrations are produced by diffing the declared schema against the previous state. The tool emits plain SQL files, which means a migration can be read and edited before it runs. That is a deliberate contrast with ORMs that generate opaque migration steps, and it makes review of schema changes part of the normal pull request. The library supports Postgres, MySQL, SQLite, and the serverless variants of each, and it runs in edge runtimes because it has no dependency on Node-specific APIs. Teams that want an ORM but dislike losing the ability to reason about the emitted SQL tend to land here; teams that want a fully abstracted data layer with a large ecosystem of plugins may prefer a heavier framework.