openharness

# Who we're building Harness for

Product and marketing direction, September 20, 2026. Validate this working audience through real
projects, repeat use, contributions, and device purchases.

**We build for people who build across disciplines.** They have an engineering or coding background,
remain hands-on, and work across product, design, analysis, and marketing. They appreciate code as a
medium for making things: something expressive that they can inspect, change, reuse, and apply across
disciplines.

**Follow your curiosity. Build across disciplines.** Harness is open-source software and hardware
for people who build in more than one craft. It gives them a place to direct their agents, use domain
tools, and turn ideas into work they can inspect, change, and use.

## The ideal user

Picture an engineer or programmer who founded a company and still wants to get their hands on the
whole idea. They enjoy moving between crafts and understand how much can be expressed through code.
In one day they might prototype a feature, explore customer data, develop a physical part, prepare a
sales deck, and make a product video. Their curiosity and responsibility span the whole outcome.

**From handoff to hands-on** expresses the change they want. An idea can become a first version they
work on directly with an agent. They describe the goal, inspect the result, exercise judgment, and
steer the next iteration. Harness should shorten the distance between deciding to try something and
having useful work to review.

The strongest early fit is someone who:

- Has an engineering or coding background and understands how software and tools fit together.
- Is a founder with responsibilities across the business and curiosity across disciplines.
- Already uses coding agents for useful work and wants to give them more kinds of tasks.
- Wants to participate directly in creating and reviewing the result.
- Values access to the code and project files so they can inspect, change, version, and reuse work.
- Enjoys learning new tools and applying familiar engineering methods to a new domain.
- Has several pieces of work underway and benefits from seeing progress and responding to questions.

Multiple agents, multiple machines, and a desk device can become valuable as their work expands.
They should be able to start with one agent, one project, and the desktop app.

## The identity: how we use the word polymath

The primary audience combines three traits: technical grounding, curiosity across disciplines, and
ownership of a business outcome. A founder or CEO with an engineering background is the clearest
archetype. Their technical experience helps them appreciate the beauty and usefulness of code; their
breadth gives them reasons to apply it to CAD, design, video, analysis, and marketing.

Engineers, independent makers, studio owners, and technical creators who share that approach are
adjacent users. The founder's combination of technical ability and work across business functions
should guide the first examples and product decisions.

### The rule: describe the work, never grade the person

The [X source notes](research/2026-09-20-polymath-x-source-notes.md) include invitations to develop
breadth, praise for other people, descriptions of models, and criticism of self-applied titles.
They support an inviting tone grounded in what people want to make. This is a qualitative reading
of selected posts, not evidence that every use of the word follows one rule or that a particular
description will convert better.

Words that describe the work are safe. Words that grade the person are not.

| Use | Avoid as a label for the reader |
|---|---|
| builds across disciplines | polymath |
| works in more than one craft | renaissance man |
| multidisciplinary, cross-discipline | generalist |
| connects the dots between crafts | 10x, wizard, genius |

So:

- **Public promise:** "Follow your curiosity. Build across disciplines."
- **Audience line:** "For polymaths in the making." Keep the invitation to explore and learn;
  readers do not need to claim expertise across several fields to belong.
- **Third person only:** the brand may call users polymaths. Copy must never ask a user to claim it,
  and no interface string, tagline or product name should require them to.
- **Use in audience copy and essays:** explain the aspiration through actual work. Interface labels
  should name the action the person can take.

### The voice

Curious, inviting, and grounded in making things.

Pair every abstract sentence with something concrete, and give every concrete list a human reason.
The examples supply substance; the sentences supply a reason to care. "Monday, a feature. Tuesday,
the customer data" is the substance. "Your ideas can take you into unfamiliar crafts" is the reason.
Neither works alone.

Keep the skepticism in the analysis, where it belongs. User-facing copy is optimistic, specific, and
unhedged. Claims should be ones a reader nods at rather than ones they stop to argue with, so prefer
"the old rule said" to asserting a contested number, and describe what became accessible rather than
what happened for the first time.

**Polyengineer** is a possible community term for people building across technical disciplines.
**Polycoder** is another exploratory term, though it may suggest using many programming languages.
Keep these as vocabulary to test with users; the public promise should explain what someone can do.

## Code is the common medium

**Coding agents can build far more than software.** Code provides a common way to create and operate
across domains. The person supplies intent and judgment; the agent writes and executes code; the
harness supplies the domain's instructions, tools, checks, and viewer.

For this audience, the code itself is part of the appeal. A design can be parameterized, an animation
can be revised in source, and an analysis can be rerun with new data. They can bring familiar habits
such as reading source, versioning changes, testing, and reusing components into new kinds of work.
The artifact and the code that produces it are both useful parts of the project.

| What the person wants | What code and the domain tools produce | Examples in Harness |
|---|---|---|
| A working product feature | Application source and a running prototype | Coding engines and Web Viewer |
| A physical part or enclosure | Geometry, CAD files, and mesh exports | text-to-cad, Autonomous Workshop |
| A circuit board | Schematics, board layout, and fabrication outputs | Autonomous Circuit |
| An answer in their data | Analysis, charts, and an interactive notebook | marimo |
| A product video or explanation | Animation, rendered video, and editable source | Remotion, Manim |
| A sales deck or report | Document source, slides, and PDFs | Marp, Typst |
| A game or simulation | Executable scenes and interactive results | Godogen, Phaser, MuJoCo |

The working loop is: describe, build, inspect, revise. Show the result beside the agent and keep the
project available for further work. The tools and checks appropriate to each domain determine what
the result is ready for.

The breadth above describes kinds of work a person can direct in Harness. Automatic coordination
and artifact handoffs between specialist agents are a separate product direction in the
[Studios proposal](plans/2026-09-17-001-zero-to-one-ideas.md).

## One audience, three ways to participate

We want to grow app usage, the open-source community, and device sales together. Each part should
make the others more useful.

| Part | Who it serves | Its role |
|---|---|---|
| Desktop app | People directing work across disciplines | The workspace for running agents, inspecting outputs, and steering projects |
| Harness ecosystem | Domain experts, tool authors, maintainers, and users sharing examples | Brings more tools and expertise into that workspace; gives authors a way to share their craft |
| Harness device | Frequent users following several tasks or long-running work | Puts status, questions, and voice controls on the desk |

A person can participate in more than one way. The desktop app works without buying the device.
Contributors can publish harnesses from their own repositories, with their authorship and upstream
projects visible. Device marketing should demonstrate its usefulness during real work.

## Positioning and messaging

The public audience wording:

> Built for the curious engineer who wants to build beyond software.

Use this invitation in the README. Technical founders remain an initial recruiting focus and guide
the first examples; readers do not need to have founded a company to belong.

The project description:

> Follow your curiosity. Build across disciplines. Open-source software and hardware for polymaths in the making.

Name both software and hardware in the description. The device makes that openness tangible: its
firmware, schematics, PCB layouts, and enclosure CAD files are available to study, change, and build.
Show those files and the physical device in the README; keep the short description focused on the
invitation.

The wording draws on three recurring ideas in the saved research:

- **Multiple interests:** [Dan Koe](https://x.com/thedankoe/status/2010042119121957316) addresses
  people whose curiosity spans several fields. Invite that curiosity without requiring a title.
- **Developing breadth:** [Garry Tan](https://x.com/garrytan/status/1728081205810073804) encourages
  founders to become capable across different kinds of work. Show a path from coding to a new craft.
- **Understanding the whole product:** [Peter Thiel](https://www.youtube.com/watch?v=h10kXgTdhNU&t=819s)
  describes entrepreneurs who understand product, people, management, and technology together.
  Keep human intent and judgment central to the promise.

These are editorial interpretations, not measured effects on signups or purchases. The description
stays short; examples in the README show what building across disciplines means. The audience section
quotes Thiel's statement with the subject included and links his name directly to the original
interview. The source notes retain the 2018 context and transcription details.

The technical thesis:

> Coding agents can build far more than software.

The founder-facing promise:

> Put your agents to work across your business.

Lead with a useful outcome and show how the person directs it. Introduce domain-specific harnesses
as the mechanism: the tools, instructions, checks, and live view behind that outcome. Persistent
sessions, engine support, and machine connections explain how the workspace supports daily work.

A campaign can tell one project from three perspectives: a prompt and its result invite someone to
try the app; a build article explains the harness and invites contribution; a desk demonstration
shows the device following work and answering an agent's question. Give each piece a clear next step
and a route to the other parts of Harness.

## What this means for the product

- Help people begin with what they want to make. Pair domain outcomes with the tools and source
  behind them so technical users can understand how the result was made.
- Make the first useful project easy to reach. Handle routine setup and show what still needs the
  user's input.
- Make results easy to inspect and revise. Show the artifact, progress, and relevant checks beside
  the agent.
- Keep code and project files accessible. Support the user's ability to read, edit, version, and
  reuse what the agent produces.
- Support moving among different kinds of work. Preserve sessions and make agents waiting for an
  answer easy to find.
- Let experts share their craft. A new domain should arrive through a package, with clear ownership,
  credit, examples, and installation instructions.

The current desktop experience is strongest on macOS. Embedded viewers run in the macOS app;
viewers on linked remote machines require a current Harness CLI on both computers. The app and
daemon currently require a Harness account. Those details belong in the
[getting-started instructions](../README.md#run-it); follow implementation status in the
[development guide](development.md).

## How we'll learn whether this is right

Recruit technical founders who already use coding agents and work across functions. Ask them to
bring a real task, observe the path to the first useful result, and learn what they choose to do next.
Include engineers and technical creators as adjacent users and compare what brings each group back.

Track the three goals separately:

- **App:** first useful project, time to reach it, return use, and work in additional domains.
- **Community:** outside authors publishing harnesses, maintaining them, and sharing useful examples.
- **Device:** purchases and continued use to follow work, answer questions, and send tasks.

Learn whether people return for managing agents, working in new domains, or both. Use that evidence
to refine the audience and messaging.