Tools

A shared canvas makes interface decisions easier to discuss. Components, variants, and prototypes let me work through the details while keeping the broader system in view.

Useful for turning an idea into something I can react to. Bringing existing components and visual rules into a prototype makes it easier to explore a direction before investing in the full build.

Working directly in a repository keeps the conversation close to the code. It is useful for tracing a problem across files, making a concrete change, and running the checks needed to review it.

The useful part is the loop between intent, implementation, and verification. I can work through an interface, inspect the result in a browser, and review the changes together.

Useful for exploring how agents approach a task and checking the work they produce. Keeping the editor, terminal, and browser close together helps make the result easier to inspect.

Routing, server rendering, and application code can live in one project. That makes it practical to grow a small working idea into a complete web product without stitching together every layer from scratch.

A familiar React workflow with access to native capabilities. Expo makes the build and device-testing loop more approachable, leaving more attention for how the app feels in someone’s hand.

Types make assumptions visible. Shared contracts help the interface and the services behind it agree on the shape of data, and make changes easier to follow across a codebase.

Keeping styling close to the markup makes small visual iterations quick. A common spacing and color vocabulary helps those changes stay consistent across screen sizes.

The components live in the project, so I can understand how they work and compose them for the product. It is a useful starting point for common controls while leaving room for a distinct visual language.

Pull requests give a change a clear boundary: what changed, why, and how it was checked. The history becomes a record I can return to when a design or engineering decision needs context.

A useful place to turn a broad idea into work small enough to finish. Issues and projects keep the next step, its context, and the remaining decisions in one place.

A preview URL makes the work tangible before it reaches production. Reviewing an actual page on different screens is more useful than trying to settle every detail from a static capture.

Postgres and authentication sit close together, with access rules that can be expressed at the database layer. That makes it easier to reason about who should be able to read or change a record.

A managed Postgres database is a good fit when a small feature needs real persistence. It keeps the data model familiar without adding database-server maintenance to the project.

Events and funnels help connect a design decision to what people actually do. Useful for finding where a flow loses people and deciding what deserves a closer look.

A repeatable set of cases gives prompt and model changes something concrete to answer to. I can compare outputs against explicit expectations instead of relying on a few convincing examples.

Email is part of the product experience, especially at sign-in. A focused API and delivery logs make it easier to connect the application flow to what was actually sent.

The first version of my personal health tracker was a Notion database. It gave the idea enough structure to become a habit, while remaining easy to change as I learned what I wanted to track.

An iOS Shortcut connected Apple Health to that early tracking database. It is a good way to test a useful workflow with the tools already on the phone, before building a dedicated app around it.