HOW A PROJECT QUIETLY BECOMES A STUDIO.

There is a particular kind of progress that is almost impossible to photograph.

Nothing ships.

There is no launch trailer. No triumphant release announcement. No neat little box you can point to and say, There. I finished that.

You spend twelve hours working and somehow end the day with more unfinished things than you started with.

I am becoming suspicious that this is what building a studio actually looks like.

Starhound started, more or less, as a place to put things I was making.

Games. Music. Fiction. Experiments. Strange ideas that refused to stay inside whatever category they were originally assigned.

That sounds simple enough.

Make things. Put them somewhere.

Except eventually you make enough things that the machinery around the things becomes a project of its own.

I have been rebuilding the website lately.

Slowly.

Not because any individual part is particularly mysterious, but because every solved problem has an irritating habit of revealing the infrastructure underneath it.

Put the music on the website.

Fine.

Except now the music needs an archive.

The archive needs organization.

Audio and video need storage.

Storage has limits.

Those limits lead to questions about hosting.

Hosting leads to servers.

Servers lead to backups.

Backups lead to the uncomfortable realization that perhaps one aging laptop should not be the load-bearing wall beneath an increasingly ridiculous number of projects.

And somewhere in the middle of this, I am still making the actual things.

There are songs being made.

There is a game being built.

There is fiction.

There is software.

There is an ongoing experimental program where individual tests can happily consume hours of compute before informing me that somewhere, buried inside several thousand lines of Python, I have committed a typo.

The machine does not care that I had plans for the afternoon.

It has found a NameError.

My afternoon belongs to the NameError now.

THE WORK BEHIND THE WORK

We have a strange vocabulary for creative progress.

We count releases.

Books published.

Games shipped.

Songs finished.

Videos uploaded.

Versions released.

Those things matter. They are the reason the infrastructure exists in the first place.

But they hide an enormous amount of work.

A finished song may require a recording pipeline.

A game eventually needs asset management, builds, backups, distribution and a website.

A research project needs reproducible environments, storage, compute and increasingly elaborate ways of making sure yesterday's experiment hasn't quietly contaminated tomorrow's.

A collection of projects eventually needs an archive.

An archive eventually needs infrastructure.

And infrastructure eventually needs infrastructure.

This is apparently how computers reproduce.

You buy one computer because you need a computer.

Eventually that computer is running an experiment that will take several hours, which means you cannot use it for the other thing you want to build.

So you need another computer.

Then the computers need somewhere to put everything.

Then they need backups.

Then you begin thinking about servers.

I assume if allowed to continue unchecked this process eventually ends with me accidentally founding a data center.

BOTTLENECKS ARE A KIND OF ROADMAP

I've started thinking differently about bottlenecks.

They used to feel like interruptions.

I would be making the real thing if I weren't dealing with this.

But increasingly, the bottleneck is telling me what needs to be built next.

If experiments prevent development work because they monopolize a machine, the next problem isn't necessarily making the experiment faster.

Maybe the problem is that there should be two machines.

If media is beginning to strain the storage available to the website, the answer isn't to stop making media.

The storage architecture has to grow.

If five projects independently need the same kind of asset, maybe they shouldn't have five independent pipelines.

Build the pipeline once.

Let everything use it.

That changes the question from:

How do I finish all these projects?

to:

What can I build that makes all these projects easier to finish?

Those are very different questions.

The second one is how a pile of projects begins turning into a system.

THE PROJECTS START FEEDING EACH OTHER

This may be the part I find most exciting.

At some point, the boundaries between projects stop being particularly useful.

Music made for its own sake teaches me something that can become useful for a soundtrack.

An illustration technique developed for one project can become useful somewhere else.

A character can exist in a game, then an illustration, then a comic, then animation.

Research tooling becomes development tooling.

Development tooling becomes studio infrastructure.

The website stops being a portfolio and starts becoming an archive of a world that keeps expanding sideways.

The work compounds.

Not because everything needs to become one enormous project.

It shouldn't.

But because capability is reusable.

Learning how to make one thing is useful.

Building a machine that makes it easier to make the next hundred things is something else entirely.

SOME DAYS NOTHING GETS FINISHED

Those days used to bother me more.

A test runs for hours.

It fails.

Fix it.

Run it again.

A page gets built halfway.

A storage problem appears.

A song produces another idea.

One small technical decision opens six doors that weren't there yesterday.

At the end of the day there may be nothing particularly impressive to announce.

But the workshop is different.

Something that was difficult yesterday is routine now.

Something that couldn't run simultaneously can.

Something that existed on one vulnerable drive exists somewhere safer.

Something that required ten manual steps requires three.

Something I couldn't make at all has become merely inconvenient.

That counts.

Maybe more than I used to realize.

THIS IS HOW A PROJECT QUIETLY BECOMES A STUDIO

I used to think progress meant finishing things.

I still think finishing things matters enormously.

But I'm starting to think some of the most important progress happens when you notice what keeps preventing you from finishing things—and build something that removes the obstruction.

More storage.

Another machine.

Better pipelines.

Better archives.

Better backups.

Better ways for one piece of work to become material for the next.

None of those things are the game.

They aren't the record.

They aren't the book.

They aren't the experiment.

Nobody is going to buy a ticket to see my extremely sensible backup strategy.

But they are the workshop those things can come out of.

And perhaps that's what I've actually been building without noticing.

Not one project.

Not even a collection of projects.

A place where projects can keep happening.

That seems like a pretty good definition of a studio to me.

~Starhound Studio