Henry Kobutra
← All notes
Uses

A few tools I use

Tools for planning, building, shipping and understanding software, with the tradeoffs that come with them.

A few tools from my working setup. This isn't a complete dependency list, and I wouldn't use all of them for every project. The useful question is what a tool makes easier, and what you take on in return.

Linear

Linear makes it easy to move between an issue, the project around it and the work that depends on it. The interface stays out of the way. I like having a place where decisions and progress can remain attached to the work.

The tradeoff is that a tidy tracker can still contain a poorly defined project. More labels, statuses and cycles won't fix an unclear outcome. Its conventions are useful when they match the team; bending every workflow around them can become another job.

Hermes Agent

Hermes is the assistant environment I use for ongoing work. Persistent context and reusable skills help when a task depends on decisions from earlier conversations.

The cost is maintaining that context and its boundaries. A remembered decision can go stale, and access to an account doesn't make every action appropriate. Memory, permissions and checking the result need attention beyond choosing a capable model.

Granola

Granola helps turn meetings into useful notes without putting a meeting bot in the call. I like being able to pay attention to the conversation and still have something structured to return to afterward.

The tradeoff is that a polished summary can sound more definite than the conversation was. Decisions, owners and commitments still deserve a check before the notes become somebody else's instructions. What gets captured and who can access it matter as much as the summary quality.

Honcho

Honcho gives agents a way to build and retrieve context about the people they work with. It's useful when continuity needs more than repeatedly stuffing old messages into a prompt.

Remembered context is an interpretation, not a permanent truth about a person. Wrong assumptions need a correction path, and useful memory needs boundaries around retention and access. Adding a memory service also adds a dependency whose cost and response time belong in the design.

Wispr Flow

Wispr Flow makes dictation useful across everyday applications. I’ve grown fond of being able to get a thought into text by speaking it, then edit the result where I’m already working.

Speaking isn't always practical in a shared room, and technical names or precise wording can still need cleanup. The convenience also deserves a conscious choice about the speech you're sending to a service. I treat the resulting text as something to read before sending, not an exact record of what I meant.

Convex

Convex brings the database, backend functions and reactive queries into one development model. That can remove a lot of coordination code when an interface needs to stay current as data changes.

You adopt its programming model along with the convenience. It changes how you write queries and backend logic; it isn't a drop-in address for an existing SQL database. That coupling is worth understanding before the application becomes difficult to move.

Neon

Neon gives me Postgres with database branching. Separate branches are useful for trying a migration or testing a change without making the primary database the experiment.

Branches still need sensible data-handling rules and cleanup. A database copy can contain sensitive data, and keeping it separate doesn't make that data safe to expose. Managed infrastructure also leaves query design, indexes and connection behavior as application responsibilities.

Vercel

Vercel makes the path from a code change to a shareable preview short. That helps turn an abstract review into a conversation about the actual page, and keeps deployment work close to the repository.

Convenience can make platform-specific behavior easy to overlook. Caching, runtime choices and usage costs deserve deliberate review. I want to understand which parts are portable and which parts would need changing if the hosting decision changed.

WorkOS

WorkOS provides building blocks for authentication and enterprise identity, including SSO and directory synchronization. It lets application work start above some of the plumbing that enterprise customers expect.

It doesn't decide the application's authorization model. Mapping an identity to the right organization, role and allowed actions is still product and engineering work. The integration also becomes a dependency in a critical path, so failure handling and recovery need to be designed.

Biome

Biome combines formatting and linting in a fast toolchain. I like reducing the number of configurations people need to understand before they can make a routine change.

A smaller toolchain is useful only if it covers the repository. Language support and specialized rules need checking before replacing an existing setup. A successful formatting or lint run also says nothing about whether the feature behaves correctly.

PostHog

PostHog brings product analytics, session replay, feature flags and experiments into one place. It helps connect a change in the product with what people actually do after it ships.

Collecting events is easier than making them meaningful. Inconsistent naming, missing context and noisy instrumentation can produce confident-looking answers to the wrong question. Privacy, sensitive-field capture and retention need deliberate choices, especially with session replay.

Lefthook

Lefthook is a Git hooks manager. It keeps local checks in a shared configuration and can run independent jobs in parallel. Small checks close to a commit are a useful way to catch avoidable mistakes early.

Hooks run on the developer's machine and can be skipped. They are feedback, not the final enforcement boundary. Slow or surprising hooks also encourage people to bypass them, so I keep the local workload focused and leave authoritative checks in CI.

Cloudflare Workers

Cloudflare Workers is useful for HTTP services and static delivery. There is a lot you can build without making a permanently running application server part of the job.

The runtime is a constraint to design around. Dependencies, execution limits and background work need checking against the real workload. A package being available on npm doesn't establish that it behaves the same way inside a Worker.


These are selected tools in use, not a ranking or a claim that one setup is right for everyone. For a way to assess a tool in your own project, see Before you add another dependency.

A conversation starts somewhere

What are you
working on?

If something here connects with what you're working on, email me.

henry@kobutra.com