The Work Takes the Shape of the Tools I Have Access To

“The medium is the message.” — Marshall McLuhan

I used to think the work began with an idea. First, I would decide what I wanted to make. Then I would choose the right tools and use them to execute it. The idea came first. The tools followed.

I no longer think that is how it works.

Give someone a camera and they begin seeing shots. Give them Figma and they begin seeing interfaces. Give them a database and they begin noticing categories, relationships, permissions, and missing fields. Give an AI agent access to a repository and the work starts reorganising itself into instructions the agent can understand.

The tools do more than help me produce the work. They influence which work I can imagine. The work takes the shape of the tools I have access to.

I recently looked through my GitHub, inbox, Google Drive, and Slack to see which tools I had actually been using. I wanted evidence rather than a list assembled from memory. The result was less a collection of software and more an operating system behind HAAM.

My projects cover food, dating, health, travel, fashion, music, films, swimming, breaking, sustainability, public Wi-Fi, company intelligence, and experimental publishing. On the surface, these are different subjects. Underneath, many of them have started becoming the same thing.

They become Next.js projects. They use React. They acquire a database, authentication, analytics, an admin interface, and some kind of AI layer. When they need to become mobile applications, they often move into Expo and React Native. When they need to become desktop applications, Electron appears.

Different ideas enter the workshop and come out wearing similar technical clothes.

WiFi.ee now exists across the web, mobile, Apple Watch, macOS, a Chrome extension, and experiments involving physical beacons. HAAM has web and iOS applications inside the same workspace. Raw Drafts has grown from a place for publishing articles into a programmable environment with a design system, AI agents, company-registry data, interactive visualisations, and workflows that can turn research into software.

This is useful. Familiar tools let me move quickly. I can reuse patterns, components, deployment paths, and decisions. Every idea does not need to begin from an empty folder.

It also means React has become part of how I think.

When I see a problem, I increasingly imagine a route, a component, a database table, and an onboarding flow. The tool begins suggesting the shape of the answer before I have fully understood the question. That influence can be productive, but I need to notice it.

The most significant change has not been another framework. It has been the arrival of AI agents inside the development process.

My repositories now contain files written specifically for Cursor, Claude, GitHub Copilot, Codex, and other coding agents. These files explain the architecture, define boundaries, record decisions, and warn agents about things they must preserve. One rule explains which routes belong to the current HAAM site, which private pages must remain reachable but hidden, which languages must survive a restructure, and which parts of an older product must stay outside the public interface.

Another file warns the agent that the version of Next.js in use has breaking changes and instructs it to read the local documentation before writing code.

This is a strange new kind of design document. It is documentation, policy, memory, and management at the same time. I am designing the product, but I am also designing the environment in which machines are allowed to change the product.

The repository has started behaving like an organisation. It contains workers with different capabilities. It contains rules about responsibility. It contains shared memory, automated checks, approval processes, and consequences when something breaks. The interface is one output of that organisation.

Expo and React Native have also changed my sense of what a project can become. A web idea no longer has to remain a web idea. The same product can move toward iPhone, Android, App Clips, notifications, maps, local storage, haptics, location awareness, and desktop software.

HAAM’s own iOS workspace can be built and submitted to TestFlight through commands inside the repository. That changes the scale at which I begin imagining ideas. A project can become something installed, carried, tapped, opened from a notification, or triggered in a particular place.

The boundaries between website, application, service, publication, and operating system become less stable. The work follows the available deployment paths.

Supabase has become one of the most central tools across my projects. It appears inside WiFi.ee, HAAM, and Raw Drafts. Directus sits beside it in parts of the WiFi.ee infrastructure, providing a human-facing way to manage content and operational data. Clerk handles identity across several products, including shared authentication between HAAM and Raw Drafts.

These might sound like backend choices, but they shape the experience as directly as typography or navigation. A database determines what can be remembered. Authentication determines who the product believes the user is. Permissions determine who can see, edit, or own something. A content-management system determines which parts of the product can change without changing the code.

Once these tools are available, I begin designing products with memory. I imagine accounts, histories, saved items, permissions, relationships, and ongoing interactions. The product stops being a surface and starts becoming a system that remembers what happened.

Raw Drafts began as a publishing space. It now contains tools for syncing Estonian company-registry information, importing company data, gathering financial information, enriching records through other sources, and publishing company summaries. MotherDuck sits inside that data workflow.

The blog did not stop being a blog. It acquired another possible form. It can become a research interface. It can inspect companies, connect public records, generate analysis, and help identify where organisations may need new roles, services, or capabilities.

Without access to databases, agents, and registry data, that idea would probably have remained an article. With those tools, the article begins trying to become infrastructure.

That is the pattern I am interested in. A camera makes me want to document. A database makes me want to organise. An agent makes me want to delegate. An API makes me want to connect. A deployment system makes me want to operate something continuously.

The material suggests the work.

Every new capability also adds another thing that can fail. My inbox is full of automated reports from GitHub Actions, Supabase, Cloudflare, and other services. Builds fail. Dependencies develop security vulnerabilities. OAuth applications require approval. Analytics must respect consent. Mobile applications need crash reporting. Releases need to survive App Store submission.

WiFi.ee Mobile includes Sentry, Firebase Crashlytics, and analytics because the work continues after the application leaves my computer.

A tool gives me power, then quietly hands me maintenance. The ability to deploy a product means becoming responsible for uptime. The ability to store data means becoming responsible for security. The ability to automate decisions means becoming responsible for how those decisions are made. The ability to let an AI agent change a repository means becoming responsible for the environment, instructions, and checks around that agent.

Tools expand the work in both directions. They increase what can be created and what must be cared for.

The same thing happens with image-making. Midjourney changed the visual language I could access. It made it possible to create strange, dense, speculative worlds quickly. Adobe and Lightroom shaped years of photography and image production. Storybook now turns the design system itself into an explorable environment where components can be isolated, tested, documented, and inspected for accessibility.

Each tool changes the unit of creation. A camera produces photographs. Midjourney produces variations. Storybook produces components. ComfyUI produces pipelines. TouchDesigner produces environments. Polycam produces spatial records.

The choice of tool affects whether I am thinking in images, systems, spaces, scenes, components, or processes.

This new Raw Drafts series will document how HAAM uses tools while working on real problems. It will include obvious tools such as Cursor, Claude, Codex, Next.js, Expo, Supabase, and Midjourney. It will also include smaller tools that briefly unlock a new capability, such as exporting information from a closed platform, scanning a building, turning a phone into a sensor, or connecting a public registry to an AI agent.

These will be field notes rather than conventional software reviews. The useful questions are what the tool makes visible, what it makes possible, what habits it creates, what responsibilities it introduces, and how it changes the final form of the work.

Each article will begin with something HAAM is actually trying to do. The tool will enter the process, and the article will follow what changes. Sometimes the tool will help complete the original task. Sometimes it will redefine the task. Sometimes it will reveal that the original idea was too small.

The goal is to understand the relationship between capability and imagination. More tools can also mean more distraction, more overlapping subscriptions, and more systems that require care. A useful toolkit is not the longest list. It is an environment in which the tools reinforce one another and leave behind work that can continue.

McLuhan wrote that the medium is the message. The form through which something is communicated shapes the meaning of what is communicated.

The same is true of tools.

They contain assumptions about what work should look like. They reward certain approaches. They make some actions effortless and others nearly invisible. They determine what is cheap enough to try, what is easy enough to maintain, and what begins to feel imaginable.

The work takes the shape of the tools I have access to.

Changing the tools may be one of the most direct ways to change the work.

Connected reading

• The Coding Assistant Is Becoming the Development System
• The Data Warehouse Is Becoming an Operator
• The Prototype Has Become Too Cheap to Trust
• The Product Is Becoming an Organization
• The Internet Is a Studio Wall

AI authorship note

This essay began with Kris Haamer’s observation that the work takes the shape of the tools he has access to. AI helped inspect his connected GitHub, email, Drive, and Slack evidence, identify the recurring tool system behind HAAM, structure the argument, and generate the Y3K visual direction. Kris requested continuous paragraphs, selected the framing, and made the final publication decision.