Throughout most of the last two weeks, I have been working on a new software project. It’s called permanentlink, and it’s a SaaS tool for authors. When I published my book Zero to Sold, I ran into one particularly annoying issue: after the book was out, many links that I had put into the book started breaking. Some blogs I linked to moved, some domains stopped working. It was a nightmare. Readers started complaining that links didn’t work, and they didn’t complain to me; they reported it to Amazon. Within a few weeks, my book was marked as “containing errors,” and I had to scramble to update the Kindle version with corrected links. A week later, the same thing happened, and I removed most of the book’s links. That’s not right. Links should work within a book, which is why I built a little prototype around that.
Permanentlink allows authors to create links that will still be reachable even when the original link rots away. I derived this solution after chatting with a few authors, who resorted to building their own custom link redirection systems to avoid getting complaints. So, just like with FeedbackPanda a few years ago, I dug into what people had already built to solve this issue and made it significantly more manageable. This audience-first approach really helped me understand the core issue of link rot and how little non-technical authors can do about it right now.
Here’s the prototype’s basic functionality: once you create a permanentlink, the system will forward any requests to the original link. A the same time, it will start monitoring the original link, and once it stops working, it will redirect to an archived version (or a custom link if the author prefers that). Simple as that.
While working on the prototype for permanentlink, I ran into an old friend of mine, so to say. The more I worked on the project, a thought grew louder: “It’s not good enough yet, I need more time.“
After falling prey to that and building a few things that I didn’t need, I stopped to reflect on where this thought came from. I remembered how this thought has been following me for the last decade. In many projects, I reached a point where the initial prototype was more than enough to show people what it was about, and yet, I struggled to share it with the world.
Where does this come from? Why would my mind hold such a limiting belief? And, maybe more importantly, how could I fight it?
It starts with our sense of identity. We see our products as an extension of ourselves. If they fail, we fail. When we think applause for our work is admiration for ourselves, we conflate the inputs with the outputs.
We are what we put into the work, not what comes of it. Yet, as technical founders, in particular, we have been trained to see products and solutions everywhere. More often than not, our worth is determined by the things we produce, not the strategies we follow while we create them. We have an inherent tendency to see a product that could be “more complete” as a better product.
But prototypes are not meant to be flawlessly executed marvels of engineering. The Minimum Viable Product is supposed to validate, not to stick around. It’s something that we build not to be used, but to give us insights into what we should be building later.
Our fear of failure is at odds with this approach. Deep down, the intent and our emotional state are conflicting when it comes to MVPs. Here’s the psychological breakdown:
Consciously, we want to build something that has a high chance of being wrong. That’s the whole point: if the MVP can invalidate our idea, then we save precious time that we would have wasted on building something bigger. We want the MVP to break intentionally, as quickly as possible.
Subconsciously, we want everything we produce to be well-received. Our animal brain considers any discrepancy between our expectations and reality as a fault of ourselves. “People didn’t like the thing I envisioned? Something must be wrong with me.” We have a hard time accepting that our perception was biased. We want the MVP to be the perfect version of our imagined product or service. What we wanted to be a validation for our idea on a conscious level, we want to be a validation of ourselves subconsciously.
Here is how I untangled this conflict for myself: I thought about who this is really about. It turned out to be not about me at all.
Perfectionism isn’t really about you; it’s about how you feel others perceive you. The more you think your life is impacted by other people’s judgment, the more you will struggle with your work.
The worst part is that most people really don’t care. Remember that one weird, awkward situation recently where you said something strange in a conversation and thought about it for the rest of the week? The person you were talking to probably didn’t even notice. The only person who cares about the embarrassment is you.
I’m not saying you should completely ignore other people. Just don’t lose yourself in all of this. While it is important to cater to your audience and build a truly needed product, the person who makes that solution a reality is you. And like anything else in life, it’s a process, a journey: a multi-step approach, something to iterate over.
When you pick up a new sport, do you expect to be an expert on the subject immediately? You’ll become knowledgeable by exposing yourself to the craft. Creativity isn’t something you can train for. It’s a process of discovery and experimentation.
By regarding your product as it is right now as yet another iteration among many, you can internalize that it’s not a representation of you but of your current effort. It’s a snapshot of what you know right now, manifest in a good-enough product to learn more.
By reframing the MVP into a learning tool, you can trick your brain into disassociating itself from the product. It will turn from an extension of yourself into a tool of curiosity and learning. As this is easier said than done, consider writing down a few questions that you want your MVP to provide answers to. By having a list of research questions, your mind will come to understand that this is “just” a knowledge-gathering instrument. This will also allow you to make changes to your MVP that can more readily provide answers — or at least data from which answers can be derived.
And that is what the current version of permanentlink is for me. It’s not the final product. It’s a simplified version of what permanentlink might be in the future, ready to be tested and iterated on.
The project isn’t an extension of myself. It’s the result of a need I saw many fellow authors struggling with. It’s an opportunity to learn more. The best MVP it can be.