Lee Painter Music for the Soul. Code for the Bowl.
17 July 2026 / Code

From MVP to MVB

This morning I spent fifteen minutes building something that, a month ago, was an engineering project.

Not because one of our engineers had done anything wrong.

Quite the opposite.

A few weeks ago one of the team had been working on a release note generator.

The idea was simple enough.

Compare two Git branches.

Collect the referenced tickets.

Produce human-friendly release notes alongside a detailed developer change log.

Like any good engineer, he started by understanding the problem.

He asked questions.

Clarified the requirements.

Integrated it into our existing framework.

Built something that worked.

It took several weeks.

It was still rough around the edges, exactly what you’d expect from an MVP.

Nothing unusual about that.

That’s how software gets built.

Or at least…

That’s how software used to get built.


Yesterday I’d been stabilising the Skill architecture behind Vork.

I wanted something that genuinely demonstrated what the platform was capable of.

Fifteen minutes before our daily stand-up I had an idea.

What if I built the release note generator as a behaviour instead?

Not an application.

Not a product.

Just a behaviour.

So I asked Gemini to write me a specification.

We went backwards and forwards a couple of times.

Eventually it produced an importable JSON definition for the Skill.

I imported it into Vork.

Configured the OAuth client.

Connected it to GitHub.

During the meeting I was still trying to work out why authentication wasn’t behaving.

It turned out GitHub OAuth Apps return an encoded form, while I’d configured the client to expect JSON.

That wasn’t an AI problem.

It wasn’t even a coding problem.

It was simply understanding how GitHub OAuth actually works.

Once I’d fixed that…

Everything just clicked.

I entered the client ID.

The client secret.

Pressed Run.

It connected to GitHub.

Compared the branches.

Collected the issues.

Generated release notes.

Generated the developer change log.

First time.

About ten minutes after the meeting ended I’d posted the output to the team.

Then I just sat there.

Slightly shell-shocked.

Not because it worked.

Because I wasn’t debugging it.

I genuinely expected to lose the next three hours chasing obscure bugs.

Instead…

I was finished.


People keep asking whether AI will replace software developers.

I think they’re asking entirely the wrong question.

The interesting question isn’t whether AI writes code.

The interesting question is why we’re still packaging behaviours into applications.

Think about what actually happened.

A month ago this was an engineering project.

Requirements.

Meetings.

Questions.

Framework integration.

Implementation.

Testing.

Today it was a conversation.

A specification.

A JSON file.

One configuration change.

Done.

The hardest part wasn’t writing the behaviour.

The hardest part was remembering how GitHub OAuth actually worked.

The bottleneck wasn’t software development.

The bottleneck was knowledge.

Once the knowledge existed…

The software almost assembled itself.


For decades applications made perfect sense.

Behaviours were expensive.

If every useful feature took weeks of engineering effort, you bundled hundreds of them together into one application.

You sold the application.

That was the economics of software.

I’m no longer convinced those economics still apply.


For years we’ve talked about the Minimum Viable Product.

Build the smallest application you can.

Release it.

Learn.

Iterate.

That made perfect sense when software itself was expensive.

Today I’m wondering whether we’ve reached a different point.

Maybe we don’t need an MVP anymore.

Maybe we need an MVB.

A Minimum Viable Behaviour.

Don’t build the menus.

Don’t build the dashboard.

Don’t build the administration screens.

Don’t even worry whether it’s a product.

Just build the behaviour.

Can it solve the problem?

Can someone use it?

Can you learn from it?

Only then decide whether it deserves to become an application.

That feels like a fundamentally different way of thinking.


Ironically, none of this diminishes the work our engineer did.

His implementation was correct.

Mine was simply possible because the world changed underneath us.

A month ago there wasn’t a better answer.

Today there is.


I think this is why Vork exists.

Not because I wanted another AI platform.

Not because I wanted to automate everything.

Because I think the fundamental unit of software is changing.

Applications made sense because behaviours were expensive.

Behaviours are becoming cheap.

Applications are becoming containers.

Behaviours are becoming the valuable thing.

I’m not sure we’ve fully grasped what that means yet.

I certainly hadn’t.

Until this morning.

So I’ll leave you with the same question I’ve been asking myself all day.

If a useful behaviour takes fifteen minutes…

Why would you build another application?