- Blog
- Journey
- Bootstrap
- Bootstrapping
Defining our vision & framework
- Joda StößerHanover, Germany
In our time during the About You Pangea Festival 2022 we came up with our vision for:
- co-creation
- our projects & startup
- the way of working & approaching ideas
- the contents of our ideas
Initially thinking about creating projects together on our company #workation in #Ibiza, we started #brainstorming business ideas and drawing up our preferred way of tackling them at the @PangeaFestival. It was a great space to disconnect and rethink our previous approaches. https://t.co/irUZKFZmfV pic.twitter.com/O8T3pYDhId
— coders.fail (@coders_fail) November 10, 2022
Instead of starting out with one idea, like many do, it was more important to us on how we are going to work and what our day to day would ideally look like. Especially, since we both had some experiences with freelance work and bootstrapping startups, that didn't work out the way we wanted to.
So a different approach was needed, to succeed some day.
The longest time was spent on the name we wanted to operate under, how we want to implement our ideas and which started we wanted to use while working near full-time and wanting to validate ideas quickly.
— coders.fail (@coders_fail) November 10, 2022
It became clear, that #bootstrapping & #BuildInPublic was the way to go. pic.twitter.com/3zfUma9ipt
The way to success would be lined with lessons learned, disappointments & failures, that was clear to us. So we decided to embrace the lessons it would provide and make it a point to fail rapidly, repeatedly, openly, publicly, honestly, confidently.
And then learn from our the results, identify our mistakes, correct our approach, iterate & improve.
The most important ones were:
— coders.fail (@coders_fail) November 10, 2022
- launch rapidly
- embrace failure as lessons
- learn & reiterate
As well as:
- try new things & approaches
- communicate our needs and thoughts honestly & clearly
- learn from other people
- connect with the community
Each of the failures would allow us to create content about it, allowing others to learn along with us and get to their goal faster. The decision to #buildinpublic was easily made and would force us to get more comfortable with failure culture, kick-start personal growth & hold each other accountable with open communication.
To do so, we needed our name and presentation to reflect and make people quickly understand. We went through quite a few iterations. Very quickly, we fell in love with the idea to have 2 domains: 1 with the .fail
TLD and one with .win
The main ones with win
/fail
TLDs in the running were:
- coders
- decode
- next
- replay / incremental / iterative
- simple / mvp / nevermind / poc / bootstrapped / value
- endless / constant / many
- loud / noisy
- humble / confident / bold / graceful
- planned / certain / upcoming / calculated
But also other like: fuckup / instant / quickly .build
In the end, we decided on the name that we both could associate with, where both TLDs were still available, and Google keywords would not be highly competitive.
Our vision framework
The rough outlines of our approach ended up being the following.
In the past we kept changing & improving the concept of an idea over and over, kept working on it for a long time, and never really launching & validating it.
People will start using it, when I get it to that perfect point and feature set.
So we limited ourselves to have a rough version 1 ready after 2 weeks. Just spending after-work hours and weekends on it.
Preferably, we would spend that time together in one location to improve our communication and keep our focus & motivation.
Getting the idea to a launch state with working out the last kinks, after successfully building the core, would take a bit more time. So we gave ourselves 2 additional weeks to do so, get people excited for it, and prepare the monetization.
This time could be very well spent apart and wouldn't require us to be in the same location. Giving us a bit more freedom and focus for the task at hand.
After the conclusion of the month, the idea needs to be fully launched and include a monetization feature. Ideally, we would already have the first purchase at that time, giving us an idea if people would like to pay for it.
This meant a v1 of an idea should only take a month, and we could validate its viability immediately.
— coders.fail (@coders_fail) November 10, 2022
And the requirements needed to be simple enough to build on weekends and after work.
If we could take a few days off, that would a bonus and the exception.
With this approach, each idea would not take more than a month to get launched, allowing us to rapidly iterate on things we would like to improve on it.