Might Work Studio

Strategy documents contain exactly the kind of information you don't want casually leaking into logs, dashboards or some helpful admin panel.

So privacy became architecture rather than a checkbox.

Authentication moved to persistent users, Argon2 password hashing and server-side sessions using opaque HttpOnly cookies. Only token digests are stored. Sessions can expire and be revoked.

More importantly, I adopted a rule for the product itself:

Admins operate the platform. They do not automatically get to read private canvases.

It makes debugging slightly less convenient.

Today I'm making the project public.

Not launching it. Not declaring version 1.0. Not pretending I have heroically completed software.

Putting it outside for people to see.

The system now has a typed node model, reusable strategy frameworks, persistent canvases, authentication and sharing, presentation generation, assets and the foundations of scenario simulation.

There is also an increasingly embarrassing list of things I still want to build, improve and re-iterate even before testing. 

But perfect is the enemy of good, and shipping, and fun. 

By now the dangerous part wasn't a lack of features.

It was having enough features to get lost in them.

So the focus shifted toward making the existing system legible: better presentation output, simulation persistence, visual assets, security, clearer workflows and something another human could actually understand in a demo.

There are still dozens of plausible directions.

That is not a roadmap.

That is a labyrinth without David Bowie in the heart of it.

The project started as CanvasOS.

That made sense when I thought I was building a clever canvas.

Then it became StrategyCanvas, which explained the product nicely and had roughly the same brand distinctiveness as calling a restaurant Food Place.

As the system expanded into workshops, simulations and presentations, even canvas became misleading. The canvas is just one interface to the model.

For a while I landed on mightwork.it.

I loved it.

Strategy is uncertainty. You build a model, expose the assumptions and ask whether this might work.

Unfortunately .it was an Italian country-code domain and, despite being half German, I had neglected to acquire an Italian passport.

.Studio url was luckily not that much more expensive.

The visual identity went through several directions before settling on something warmer, calmer and friendlier.

The application deals with complicated structures. The interface therefore has no business making them feel even more complicated.

I wanted clarity without sterility and professionalism without the visual language of software purchased by a procurement committee in an airport hotel.

The friendlier direction won.

There is still colour, character and a little weirdness.

Strategy has suffered enough navy blue, modern and McKinseylikes.

Simulation stopped being a sketch on the roadmap and became a backend domain.

Models, schemas, repository, service and router layers went in, followed by persistence migrations and HTTP tests.

The API now has explicit operations for creating and manipulating simulation state rather than hiding the feature inside generic canvas logic.

This is the stage of software development where screenshots become significantly less exciting while the product becomes significantly more real.

There are only so many ways to photograph a repository layer.

I wanted simulation, but not a text box where an LLM invents three futures and calls itself strategic foresight.

So Simulation Suite started without AI.

A scenario is a structured variation of the model: change assumptions, variables or relationships and examine what follows. The important part is preserving the relationship between the original plan and its alternatives.

The user draws and edits the strategy.

The application maintains the data model underneath it.

AI can help interpret that model later.

Nobody walks into a board meeting carrying an infinite node graph.

So I started building presentations from the same underlying model.

The target isn't one export button. The same strategy should be able to become a short presentation, long presentation, C-level summary, investor view, internal deck, pitch or workshop report.

Then came presentation styles: professional, creative, inspiring and others.

This clarified one of the project's better ideas:

One model, many views.

Change the model once. Tell the story differently depending on who needs to hear it.

Far more useful than maintaining six PowerPoints called FINAL_v7_reallyfinal.pptx.

A strategy tool eventually has to survive contact with other humans.

Canvas membership gained editor, viewer and feedback roles. Guest sessions and share links followed, including proper expiration and logout behaviour.

The interesting part wasn't sharing. It was sharing without weakening the privacy model.

The same thinking now applies to assets. Images can belong to users, canvases, nodes and presentations without becoming an excuse for platform administrators to browse through people's work.

Collaboration is easy if everyone gets the keys.

I decided against that particular innovation.

I didn't want a Save button.

The canvas should behave more like Miro: change something and the system remembers it. Autosave now tracks edits and reports saving, saved and failed states without turning persistence into a user task.

This creates a surprisingly large number of less glamorous questions.

What constitutes a change? What happens during rapid edits? What if a request fails? What gets restored after refresh?

Nobody puts database persistence in a product trailer.

Everybody notices when it doesn't work.

Communication Planning came first, followed by Campaign Planning, Concept Planning and Digital Marketing Planning.

This was the first point where the architecture started paying rent.

The canvases looked different because the problems were different, but underneath they used the same node-definition system, connections and output infrastructure.

That suggested a much larger idea:

Don't build a strategy template.

Build a system capable of describing strategy templates.

Subtle difference. Considerably worse for the roadmap.

The node library grew past 200 definitions.

I started breaking strategic frameworks into reusable primitives instead of implementing every framework as another bespoke feature.

The backend gained NodeCategory, NodeDefinition, NodeField and NodePort. Definitions could describe their own fields, inputs, outputs and behaviour instead of relying on frontend hardcoding.

This was boring in exactly the right way.

The more vocabulary the platform understands, the less application code is needed to invent another canvas.

Strategy frameworks are, after all, mostly different arrangements of people asking similar questions in increasingly expensive rooms.

Once the basic model worked, every idea started looking reasonable.

Workshops. AI. Simulations. Presentations. Wizards. Research. Collaboration. Scenario planning. Exports. Templates.

All excellent ideas.

Together, an excellent way to never finish anything.

So I reduced the immediate problem to four things: make the node system solid, protect the data, produce useful outputs and create somewhere to experiment with scenarios.

Everything else could wait.

Some of it waited for almost three days.

The first important architectural decision was separating what you see from what the system knows.

A node is not a coloured rectangle. It has a type, fields, ports and behaviour. A connection isn't a decorative arrow. It describes a relationship that other parts of the system should eventually be able to reason about.

That distinction sounds obvious.

It also happens to be the difference between building a drawing tool and accidentally starting to build a small operating system for strategic thinking.

The second option sounded more interesting.

Obviously also much more work.

The original idea was fairly small: build a node-based tool for strategy.

Most strategy work starts as a messy network of facts, assumptions, goals, opinions and dependencies. Then, through some strange corporate ritual, we flatten all of it into rectangles in PowerPoint.

I wanted to keep the structure alive.

The first prototype borrowed its mental model from Blender rather than Miro: typed nodes, meaningful connections and outputs generated from the graph.

React and TypeScript in the front. FastAPI, SQLAlchemy and PostgreSQL behind it.

At this point it was mostly an editor.

Unfortunately, it worked.

That meant I had to decide what it was actually for.