#005 - Who Stops Scope Creep When You Work Alone?

Listen on Spotify or watch on YouTube

Scope creep. As developers, we do not like hearing those words.

As a consultant, I have heard them many times. I have dealt with projects where somebody wants to add another feature—one nobody has tested and nobody has asked for—and I have always found it a little strange. Why would you make the scope bigger without knowing whether the extra work is useful?

Developers are not innocent either, of course. We improve a bit more code than we were supposed to. We touch one more part of the system because we are already there. We tell ourselves the extra change will make everything cleaner. That is why we try to keep the scope as small as possible.

I understood all of that in theory.

Then I started building my own iOS application.

Suddenly, scope creep arrived much faster than I expected.

When nobody is there to stop you

I gave myself the past week to develop features. I wanted to build something that was at least lovable: a minimum lovable product rather than only a minimum viable product.

That sounds reasonable. A product needs some love. It should not merely exist; it should feel good enough that someone might actually want to use it.

But there is a problem hidden inside that idea. “Lovable” can become an excuse for almost anything.

I began adding features without knowing whether they would help other people. In some cases, I was not even sure I would use them myself. Still, I kept building them.

The application remains focused on what it is supposed to do, but it is now much broader than I originally intended. It has more bells and whistles than the first version was supposed to have.

This is the first application I have built completely myself, from front to back, with the intention of releasing it on the App Store for other people to use. That means I am learning more than the technical side of building an app. I am also learning what happens when the developer, business owner, product owner, and stakeholder are all the same person.

You can think, “This might be useful,” and immediately give yourself permission to build it.

There is no product owner asking whether it is a priority. There is no teammate saying, “Can that wait? Is it really necessary for the first version?” There is no market evidence telling you that the feature matters.

There is just you, your idea, and the dangerous ability to implement it.

Minimum viable, then minimum lovable

The lesson I want to carry into future applications—and into future features for this one—is simple to describe and harder to follow.

At the start of a project, define its focus. Decide what the product is supposed to do. List the minimum features it needs to be viable. Then decide what small amount of extra care would make it lovable.

And stop there.

Do not keep expanding the definition because another feature sounds handy. Finish the agreed scope, release the product, and put it in front of people.

That last part matters because I currently have no real user feedback. I can guess what people might want, but those guesses are not the same as evidence. Every speculative feature adds development time and technical scope. It may also become something I have to maintain, even if nobody ever uses it.

The alternative is to release a smaller product and learn from what happens next.

If people use it and enjoy it, feedback should start to arrive. I also hope that sharing more of what I build—and making more logs like this one—will help me meet potential users and hear what they actually need. Then I can build in response to real feedback instead of inventing requests on their behalf.

And if there is no feedback because nobody uses the application? Then perhaps it is time to sunset it, remove it from the App Store, or take it offline, depending on the project. That would not make the work pointless. It would still have taught me something, and it would allow me to move on without maintaining a growing collection of features nobody wanted.

Releasing is part of the experiment

The application is almost finished. I still need to handle the administration required to get it onto the App Store. After that comes marketing, which is something I am completely out of my depth with. That should be an interesting challenge, and I will try to make more logs about it.

Then I may begin a new project, or return to the planner and refine it. I am also considering dabbling in game development after this application.

Whatever comes next, I want to take this lesson with me: start small, define the goal, decide what “viable” and “lovable” mean, and do not quietly turn version one into version four.

Release it into the wild. Find a test audience. Gather feedback. Build from that.

I am trying to learn as much as I can from this project, both as a developer and as someone building a business. I think those lessons will help with my own future applications and with future clients too.

So this is a short log with a fairly simple conclusion: keep the scope small enough to ship.

Maybe this helps somebody else who is building alone. In the worst case, it is a reminder to myself the next time I decide that one more feature “might be handy.”

How do you decide when a first version has enough—and who keeps your scope under control when you are working on your own?