2026-07-14 · 9 min read · Raw Drafts / Software / AI
Executable Drafts
AI has made software cheap enough to become a draft: a working question, experiment, or argument that can encounter reality before it becomes a product.
For a long time, software was too expensive to be casual. You could sketch an interface, write an essay, draw a diagram, or build a presentation around an idea, but turning that idea into working software required a different level of commitment. You needed developers, infrastructure, time, money, and a reasonably clear sense that the result would be worth building. Software therefore tended to feel final before it even existed. You did not build an application merely to explore a question. You built it because you had already decided that the question deserved a company, a product roadmap, or at least several months of work.
AI changes this. It is now possible to take an idea that would once have remained a paragraph and turn it into a functioning interface within days, sometimes hours. The result may be rough, narrow, fragile, or incomplete, but it can still be used. Someone can click it, misunderstand it, reject it, return to it, or do something with it that you did not expect. The draft can now execute.
Most ideas begin in a vague state. They are mixtures of observation, intuition, irritation, and possibility. You notice that something does not work well. You imagine a different structure. You connect two unrelated fields. You wonder whether one group of people could play a new role in a system. At this stage, writing is useful because it forces the idea to take shape. Sketching is useful because a sketch reveals relationships that were not visible in language. Yet both remain indirect.
You can write about a marketplace, but the experience of entering a marketplace may expose problems that the essay never reveals. You can sketch a dashboard, but a working dashboard may show that the data itself is meaningless. You can describe an AI assistant, but using even a primitive version may reveal that the assistant is annoying, unclear, or solving the wrong problem. Historically, this feedback arrived late because the software arrived late. By the time a system became usable, a team may already have spent months defending the original idea. The product was no longer a question. It had become an investment that needed to be justified.
AI lowers the cost of reaching the point where reality can answer back.
The executable draft
An executable draft is an idea expressed as working software before it becomes a finished product. It is not necessarily a startup. It does not need a polished brand, scalable architecture, or long-term business model. It may exist only to make a question tangible.
An executable draft might be a map that reveals a pattern in a city, a marketplace with five real participants, a personal health tool used by one person, a simulation of a public policy, a visual canvas for evaluating accessibility, a prototype that turns a screenplay into a production plan, or an AI agent that tests whether a workflow should exist at all. The important part is not that the software works perfectly. The important part is that the idea has crossed from explanation into experience.
A written draft asks whether an argument makes sense. An executable draft asks what happens when someone tries to use it. Those are different questions. One tests coherence. The other tests contact with reality.
We usually describe software as a product, tool, service, platform, or infrastructure. We rarely describe it as a medium for thinking. Yet software can reveal ideas in ways that language cannot. A map can make spatial relationships visible. A simulation can reveal consequences. A marketplace can test whether participants will actually coordinate. A recommendation engine can expose the assumptions hidden inside a theory of relevance. A form can reveal which information a system considers important.
Software does not merely represent an idea. It enforces it. Every interface contains decisions about what exists, what can happen, what must happen first, what is visible, who has power, and which outcomes count as success. That makes building software a way of examining your own thinking. A rough application can show that your categories are wrong. It can reveal that an imagined user does not exist. It can expose a contradiction between what you say you value and what the interface actually rewards.
This is why the process of building often produces the real idea. The initial concept may only be an excuse to begin.
Discovery through making
There is a common expectation that a project should begin with clarity. First, identify the problem. Then define the user. Then validate the market. Then design the solution. Then build. This sequence makes sense when the goal is efficient execution. It is less useful when the goal is discovery.
Sometimes you do not yet know which problem matters. You may only have a territory of interest such as accessibility, health, film, cities, architecture, education, finance, or personal data. Building inside that territory can produce knowledge that research alone does not. You may begin with an accessibility scoring tool and discover that companies do not need another score. They need help deciding what to fix first. You may begin with a personal health dashboard and discover that the useful part is not measurement but reflection. You may begin with a visual research board and discover that people care less about organizing information than about finding unexpected connections between projects.
The software does not confirm the original idea. It gives the idea somewhere to mutate. This is the difference between building to prove and building to discover.
Because software used to be expensive, it inherited a culture of seriousness. Every application needed a roadmap. Every prototype hinted at a future company. Every experiment needed to justify engineering time. Writing never carried the same burden. You can write a strange essay without intending to build a media empire around it. You can draw a speculative building without intending to construct it. You can make a short film without planning a franchise.
Software is beginning to gain the same freedom. A tool can be temporary. An interface can be personal. A system can be speculative. A program can be made for fifty people, five people, or one afternoon. This does not make software less meaningful. It means software can participate in culture before it becomes infrastructure. It can function as criticism, fiction, research, performance, or provocation. A working application can ask a question in public.
The problem with calling everything a startup
The moment a small piece of software appears, people often ask about scale. Who is the customer? What is the market? What is the revenue model? Can this become a company? These are useful questions, but asking them too early can shrink the idea. Some experiments need to remain open long enough to reveal what they are.
A project may begin as a tool and become an article. It may begin as an article and become a service. It may attract collaborators rather than customers. It may solve a small internal problem and later reveal a much larger one. The pressure to define the business too early encourages clean stories before there is enough evidence to tell them.
Raw Drafts should preserve the period before the story becomes clean. That is the most interesting period. It is where assumptions fail, categories change, and unexpected uses appear.
Most public product stories are written backwards. Once something succeeds, the process is rewritten as a sequence of intelligent decisions. The early confusion disappears. Accidents become strategy. Failed versions are removed from the narrative. Executable drafts make it possible to publish the process while the outcome is still unknown.
A project might begin with the observation that automated accessibility tools can detect technical failures but cannot fully describe what using a product feels like. That observation becomes a question: could people with disabilities become paid product experts who validate digital experiences? The question then becomes a written draft, followed by a working draft containing a basic marketplace, an evaluation canvas, and a method for collecting evidence.
Once people begin using it, reality starts to respond. Companies may not trust the certification model. Evaluators may want a different payment structure. The marketplace may turn out to be unnecessary, while the prioritization tool becomes valuable. The most important feature may be one that barely appeared in the original concept. Each change becomes part of the work. The product is not presented as the answer. It is presented as the latest state of the question.
A different kind of studio
This suggests a different model for Raw Drafts. It does not need to be a publication that happens to contain occasional experiments, nor a startup studio that treats every idea as a potential company. It can be a studio for unfinished ideas. Some ideas become essays. Others become interfaces, maps, films, datasets, tools, or small communities. Each project can move from observation to written draft, from written draft to executable draft, and from executable draft into contact with reality. From there, it may mutate, grow, or be archived.
The archive matters. A failed application may still reveal a useful pattern. A tool nobody adopts may produce a better research question. An abandoned prototype may contain one interaction worth reusing elsewhere. In a conventional product culture, these are failed projects. In a drafting culture, they are material.
As software becomes easier to produce, code itself becomes less distinctive. The scarce parts move elsewhere. Judgment becomes scarce because knowing which idea deserves to become interactive is valuable. Taste becomes scarce because knowing what to remove, what to simplify, and what should remain unresolved is valuable. Access becomes scarce because contact with real people, organizations, constraints, and problems is valuable. Trust becomes scarce because people may be surrounded by generated products, but they will still choose systems they understand and creators they believe. Attention becomes scarce because the ability to make someone care about an experiment matters more when experiments are abundant.
The code may be generated quickly. The meaning cannot be.
An idea can become real before it becomes certain
The most liberating part of this shift is that an idea can become real before it becomes certain. You can build without claiming that you have found a startup. You can publish without pretending the work is complete. You can invite people into the project before you know what the final version should be.
An executable draft is not a lesser product. It is a different object. It is software whose primary purpose is not yet efficiency, scale, or permanence. Its purpose is to help an idea encounter reality.
Some of these drafts will grow into products. Some will become companies. Some will become services, research projects, or collaborations. Others will remain small, useful artifacts. Most will change.
That is the point. The purpose is not to finish every idea. The purpose is to discover which ideas become more interesting when they are made real.
AI authorship note
This essay grew from Kris Haamer's questions about software that once required unusually ambitious engineering but can now be assembled quickly with AI, and about what happens when the ability to build stops being the scarce part. AI supported the research, drafting, editing, and implementation. Kris directed the argument toward Raw Drafts, software as a medium for thinking, discovery through making, and the idea of an executable draft.