Owning the code, or opening it

Every solo founder who ships something that works arrives at the same fear: a bigger, better-resourced company takes the idea and there is nothing left. These are the notes from a strategy session with an early-stage SaaS founder who had arrived at exactly that point — the walk-through that answers it, and what it changes about how you build.

Part one · What copying you would actually cost them

The useful response is to walk the scenario through rather than argue the principle. An established company of a few hundred people, holding a full copy of the code, still has to do all of the following before a single user touches it. Each step is a place the plan stalls.

Optimistic: three months to reach where you already are. Realistic: closer to a year. Which turns the fear into the pitch:

"You can take it. It will cost you that. Or you can pay me, and have it next week."

Price the licence below their internal build cost and the buy decision makes itself. And there is a second trap for them on top: taking a competitor's code hands that competitor control of their roadmap. Every fix and every new feature either comes from you, or gets maintained by them in perpetuity.

Part two · Four things that surfaced

The cost argument answers the question that was asked. These are the four things underneath it that came up once the fear was priced — each an instinct that made sense once, and the counter-argument that reverses it now.

Part three · Explorer, villager, town planner

Simon Wardley's evolution model is the spine of the technical argument. Each stage is a different job with different standards, and the common mistake in AI-assisted building is treating all three as one. The pattern itself belongs to wardley-maps.sgit.ai; what matters here is the moment between the first two.

This is the same frame that produces the maintenance market this site argues for: somebody has to be the villagers, and the founder's first job after the prototype works is to become one for their own code.

Part four · The practical route, in order

Eight steps. The first four happen while the repo is still private and nothing is exposed; the fifth is the point of no return; the last three are habits that run alongside, starting this week.

Do now, while the repo is private — nothing exposed yet

Only after licence and IP are settled — the point of no return

Running alongside, from this week — habits

Worth settling before you publish

Part five · What your past self would have called success

Before the fear of being copied, there was a set of things that would have counted as winning. They are worth writing down, because they are all closer than the fear makes them feel.

Part six · What a week of this looks like, counted

The handover from prototype to product is invisible from the outside unless you count it. A week of this work produces almost no new features and a great deal of the following. Publishing the count is itself the discipline, because you cannot quietly skip a week when the row has to be filled in.

Four habits that produce those numbers

The point of building in the open

Be the new generation of artist — the one who controls the master, not the one who was successful and never saw the money.

Which is the argument of this whole site at the scale of one founder: the code is not the moat, the execution is; opening it costs you far less than the fear says and buys you a pitch, a discipline and a story; and what you keep — the trademark, the velocity, the relationship with the people who pay — is what was ever worth keeping.

Where to go next