The Audience Was Bigger Than the IDE

The first version of a product often reveals the team’s vocabulary before it reveals the full size of the problem.

Open Free Max began with a vocabulary shaped by development. Projects. Sessions. Terminals. Agents. Workspaces. Those words were honest. They described a real part of the product and the kind of work that motivated it.

They were not the whole story.

By July 30, we were looking at OFM and recognising a tension. The product had grown around an IDE-shaped understanding of work, but the people it could help were not limited to people who considered themselves developers. Advanced AI users were already moving between research, writing, product decisions, client work, automation, and experiments. Some wrote code every day. Others used code and command-line tools as part of a wider creative or professional practice.

The question was not whether to abandon the IDE.

It was whether the IDE was the destination, or the first visible shape of a larger idea.

The developer vocabulary came from a real need

We did not start with the word “IDE” because it sounded impressive.

We started there because the problem was concrete.

AI-assisted development creates an unusual kind of work. A person may have several projects open, several sessions in progress, and several tools participating in the same broad effort. The useful context is spread across files, conversations, terminals, and decisions that may not fit neatly inside one traditional editor.

The first product decisions grew from trying to make that situation less fragmented. A workspace needed to hold more than a single conversation. A project needed to remain recognisable when the person returned. An agent needed a place in the broader flow of work. The vocabulary of development gave us a clear starting point because the tension was visible there.

Starting with a specific audience had another benefit: it gave the product a sharp test. If OFM could not help someone who was already comfortable with complex tools, it would not earn the right to serve a wider group.

The problem was never imaginary. The frame was simply narrower than the opportunity that emerged from it.

The work did not stay inside the editor

The more we followed a real AI workflow, the less useful the traditional boundaries became.

A person might begin with a question, move into research, ask for a comparison, turn the result into a brief, make a change in a project, capture an observation, and return to the original question. Some of that work looks like development. Some looks like writing. Some looks like planning. Some looks like the invisible preparation that makes a finished piece possible.

The common element is not the file type.

It is the need to keep the work moving while preserving enough context to make the next step intelligible.

That pattern belongs to more people than developers. A creator building a publishing system can have the same continuity problem as a developer maintaining an application. A freelancer handling several client projects can need the same project separation as a technical team. A product researcher can move between notes, sources, hypotheses, and decisions in a way that resembles a multi-session build.

The interface may look different in each case. The underlying pressure is familiar: too many projects, too many tools, and too much context held in the person’s head.

We had been speaking to the tool instead of the outcome

An IDE is easy to describe because it is a visible category. It tells people what kind of surface they are looking at.

The outcome is harder to describe. OFM is meant to help people coordinate AI-assisted work across projects, sessions, tools, and evolving knowledge. That sounds broader because it is broader. It also asks the reader to imagine themselves in the problem rather than deciding whether they are a member of a software category.

This difference affected the way we thought about the home page and the product’s public language. A developer might understand “AI command centre” immediately. A writer or creator may understand the underlying experience but not see themselves in the phrase “IDE.” A freelancer may not want another development environment, even if the work they do with AI would benefit from one.

The product should not make people translate their work into our internal vocabulary before they can recognise its value.

That realisation did not require a dramatic change to the core. It required a wider doorway.

The wider audience was not a marketing trick

There is a shallow way to broaden an audience. Add a few labels, list more professions, and claim that the product is for everyone.

That was not the direction we wanted.

An audience becomes genuinely wider when the product’s central idea survives a change of context. It is not enough to say that creators can use an IDE. We have to understand what creators are trying to accomplish and explain how the product helps with that work. It is not enough to list freelance work as a use case. The experience has to respect the fact that client projects need separation, continuity, and clear boundaries.

The broader audience gave us a product test, not just a copywriting exercise.

Could the concepts of projects, sessions, memory, shortcuts, and multiple AI tools remain useful when the output was an article, a research brief, a campaign, a product decision, or a working prototype? Could we explain the same underlying value without pretending that every person works like a software team?

Those questions are still active. They are more valuable than a generic promise of universality.

Creators already understand systems

The creator economy is sometimes described as if creators only need publishing tools.

That misses the work behind publishing.

A creator may maintain an editorial calendar, research a subject, develop a point of view, draft several versions, coordinate collaborators, adapt work for different channels, and keep an archive of decisions. The finished article or video is only the visible end of a much longer process. AI can participate in many points of that process, but the person still needs a way to keep the system coherent.

This is where OFM’s original instincts remain useful. Project boundaries can protect different editorial efforts. Persistent knowledge can reduce the cost of returning to a subject. Reusable shortcuts can preserve a recurring way of starting. Multiple tools can support different stages without making the entire process feel disconnected.

The product does not need to become a specialised creator platform to support that work. It needs to recognise that creation is a system of decisions, not just a blank page.

That is a familiar idea to anyone who has ever built something in public. The audience sees the result. The maker lives inside the sequence that produced it.

Vibe coding made the boundary even less clear

Vibe coding is often presented as a new kind of development, but its cultural importance reaches beyond code.

It describes a way of working in which a person moves quickly between intention, conversation, experiment, and result. The person may know enough to guide the work without wanting to manually perform every step. They may be building a tool, testing an idea, creating a prototype, or turning a rough concept into something others can use.

That rhythm also appears in writing and product work. The material changes, but the cycle is similar: describe what matters, inspect what comes back, correct the direction, and keep going.

An IDE-shaped product can support this rhythm, but the rhythm is not owned by the IDE. It belongs to people who are using AI as a collaborator in a broader practice.

This helped us see why the product should remain comfortable with technical workflows while speaking to a wider set of ambitions. The command line can be part of a creator’s process. A project can be a client engagement. A session can be an editorial decision. The categories overlap without becoming identical.

The challenge is to preserve the usefulness of the structure without forcing everyone to adopt the same identity.

We chose entry points instead of one giant promise

A broad audience does not mean one broad page that tries to explain everything at once.

People arrive with different problems. One person wants to manage several AI-assisted projects. Another wants to build and publish. Another wants to work with local knowledge. Another wants to move between tools without losing the thread. If the first explanation begins with the complete product, the reader may have to search for the part that matches their day.

This is why use cases became important to our thinking.

Use cases are not simplified versions of the product. They are entry points into the same underlying experience. Each one starts with a situation the reader can recognise and then shows how the product’s structure could support it.

The distinction helps us keep the product honest. We do not need to claim that OFM replaces every tool or serves every workflow perfectly. We can explain the specific tension it addresses and let the reader decide whether that tension exists in their work.

The goal is recognition before persuasion.

If someone sees their own day in the problem, the product has earned the right to explain more.

The product still needed a centre

Broadening the audience created a risk in the other direction. If OFM could serve developers, creators, freelancers, researchers, and vibe coders, what held the product together?

The answer could not be a list of professions.

The centre is the experience of working with AI across more than one isolated task. People need a place where projects can remain distinct, sessions can have continuity, useful knowledge can persist, and different tools can participate without forcing a total reset. Those needs can appear in different forms, but they create a recognisable product idea.

The centre is not “a tool for developers.” It is a working environment for people who have outgrown one conversation at a time.

That phrase also explains why we are not trying to become a generic AI assistant. A single prompt and a single answer can be useful, but OFM is concerned with the work that surrounds the exchange: the project that gives it meaning, the next step that follows, and the knowledge that should still be there later.

This centre gives the wider audience a reason to exist together.

What we refused to disclose in the story

Build in public has a boundary.

Sharing the evolution of the product can make the work more understandable and more human. It does not require publishing private prompts, internal architecture, security details, unreleased mechanisms, or the exact sequence by which the product achieves an outcome. Users deserve a story they can relate to, not a recipe for reconstructing the implementation.

This is especially important when the audience grows. A public explanation needs to be useful to a creator without becoming a technical disclosure. It needs to be concrete enough to carry meaning without revealing the internal machinery that should remain private.

The story is about why a decision mattered, what tension it exposed, and how it changed the way we see the product. It is not a request for the reader to copy our internal process line by line.

That boundary is not a limitation on transparency. It is part of responsible transparency.

What this means for people using OFM

For someone who already works comfortably with AI and command-line tools, the broader direction means they do not have to pretend their work fits inside one professional category.

They can use OFM to organise a product build, a research effort, an editorial system, a client project, or a set of experiments. The product’s structure remains useful because it is based on continuity and context rather than on the label attached to the person.

For developers, this does not make the product less relevant. It puts development inside a larger landscape of work. For creators and freelancers, it offers a way to understand why a product that looks technical might still speak to their daily reality. For people who move between both worlds, it removes the need to choose which identity is allowed at the door.

The benefit is not that every workflow becomes identical. It is that the product can support the differences without losing its centre.

The next challenge is speaking plainly without becoming generic

Once a product finds a wider audience, its language can lose its edges.

“Work better with AI” is broad enough to include everyone and specific enough to help no one. We need the opposite: language that is accessible because it is concrete, not because it has been emptied of detail.

That means telling stories about recognisable situations. Returning to a project after a pause. Moving between AI tools. Keeping one body of work separate from another. Reusing a familiar starting point. Carrying an idea from research into production without losing the reason it mattered.

These situations are more useful than a category label because they give people something to compare with their own day.

The work ahead is partly editorial and partly product design. Every new explanation tests whether the underlying experience is coherent. If we need a different promise for every audience, perhaps the product has no centre. If one promise can be translated into several real situations without distortion, we may be getting closer.

We are still in that process.

The IDE was the beginning, not the boundary

Looking back at the July 30 realisation, the important shift was not from developers to everyone.

It was from a surface to a problem.

The surface was an IDE-shaped workspace. The problem was the fragmentation of ambitious AI-assisted work. Once the problem became clearer, the audience became easier to see. Anyone carrying several projects, several tools, and several kinds of context could recognise some part of it.

That does not mean OFM is finished, or that it is right for every person who uses AI. It means the product has a more honest way to describe what it is becoming. The goal is not to hide its technical roots. The goal is to make those roots useful to people whose work extends beyond software.

The IDE taught us how to begin.

The wider audience is teaching us where the product can go.

A larger audience asks for a better product, not louder claims

The easiest response to a wider opportunity is to increase the volume of the message. We would rather increase the precision.

If OFM is going to serve advanced AI users across different kinds of work, it has to keep earning that position through the details: clear projects, understandable sessions, useful memory, flexible tools, and language that respects the person’s actual workflow.

The audience being larger than the IDE is not a reason to dilute the product. It is a reason to examine what was valuable underneath the original frame.

That examination is still happening. It will shape the pages we create, the stories we tell, and the decisions we make when a new audience brings a new version of the problem. We want people to feel that they are entering an ongoing adventure, not stepping into a category designed for someone else.

Open Free Max started by helping one kind of work feel less fragmented.

Now we are learning how many kinds of work were waiting for the same relief.

That widening view changes the stories we have to tell about the product. A developer may recognise the value of several active projects immediately. A creator may experience the same value as a way to hold research, drafts, and decisions together without losing the thread. A freelancer may care less about the label of the tool and more about whether client work, personal experiments, and content can coexist without becoming one indistinct pile.

The underlying problem is not ownership of a profession. It is the cost of switching context. Anyone who carries more than one kind of work knows the feeling of returning to a project and spending the first part of the session reconstructing what was already known. The vocabulary changes between professions, but the loss of continuity feels familiar.

This does not mean every person needs every part of OFM. A broader audience should make the product more attentive to different starting points, not more eager to put every capability in front of everyone. The work is to find the common human problem without flattening the ways people solve it.

That is why the next stage is as much about listening to language as building screens. Words such as project, session, memory, plan, and workspace can mean different things depending on the life surrounding them. If OFM is going to welcome more people, it has to leave room for those meanings while remaining clear about what it promises.

The audience is bigger than the IDE because the need for continuity is bigger than software development. We are still building from the place where the idea began, but we are no longer treating that place as a boundary. The product can remain serious about complex work while becoming easier to recognise from the outside.

That recognition will not come from removing the complexity that makes the product useful. It will come from giving the complexity a more welcoming shape. People who create, research, manage, and build all deserve serious tools, but they should not have to prove that they belong to the category before they can understand the invitation.

This is a change in posture as much as a change in audience. We are learning to ask not only what the product can do, but what a person believes they are allowed to do when they first encounter it. A workspace can be powerful and still feel open. It can support advanced decisions without making the first decision feel like a test.

The answer will continue to evolve because the people arriving at OFM will continue to surprise us. That is healthy. A product that defines its audience too early eventually starts protecting its definition instead of helping the people in front of it. We would rather keep the definition useful, provisional, and connected to the work people are actually trying to carry.