From idea to product and beyond
It’s often the things we think are solved that are most ripe for change
Yeah, we’ve all heard that before, especially this crowd.
“I want to build a screen recorder. It’s going to be great, it’ll be built using web technology, you could build plugins for it, it’s going to be open source!”
Fast forward a few weeks, and sure enough, we found ourselves having launched an open source screen recorder built with web technology. Not only that, but after being seen by tens of thousands of people the app was inching ever closer to 10 000 downloads.
Record scratch
Freeze frame
Yep, that’s me. You’re probably wondering how I got into this situation…
Kap
That’s the name of the app we ended up building, it’s crazy, but you might actually have heard about it.
A tiny side project beating alternatives on Product Hunt, trending on GitHub and being featured by Electron isn’t everyday stuff, we couldn’t have imagined it even if we tried.
What happened? Luck? Did the universe glitch? Let’s get scientific about it. I’m a scientist now.
My friends and I work on websites, apps and the alike for a living, we help people execute on ideas. That’s not always as glamorous as it may sound; working with early stage startups is messy, building products and services on limited time and budget is hard. Often you don’t get to do stuff the way you’d ideally like to, but with Kap we had the autonomy to follow a non-bureaucratic, user-centred and iterative process. We had the freedom and constraints needed to build something great.
It’s often the things we think are solved that are most ripe for innovation.
So why a screen recorder? Turns out that after a few rounds of playing ping pong with the idea, we realised that we shared the same pain points with the currently available solutions. Not only that, but we had some pretty neat thoughts on how to create something better that resonated with all of us. We almost killed the idea, and maybe that’s the lesson here; don’t be an idea killer.
There are a lot of rules we make that aren’t necessarily very useful; why shouldn’t you do something just because it’s been done before? It’s often the things we think are solved that are most ripe for innovation.
We are building something we want, need and use on daily basis. We were making something for ourselves. I think some of the best products come from people who first and foremost solve their own problems.
MVP
What does that even mean? No, really. “Minimum viable product” doesn’t really mean anything. You hear people throw it around as if it was some kind of solution in of itself, it’s not, it needs defining. Everyone has different ideas of what it means in any given setting. It’s a compromise that needs careful thought.
We asked ourselves; to get this out there, do we need 3 different export formats? Do we need audio recording? Do we need a settings screen? Do we need to custom design every element?
The answer to all the above ended up being ‘‘no’’. Ruthless prioritisation.
After about 3 weeks of building on evenings and weekends we had an MVP. I think it’s fair to say that if you can’t build an MVP or prototype and have it in peoples hands in 3 months, you’re doing something wrong.
Traction
Another buzzword, AngelList co-founder Naval Ravikant defined it as “quantitative evidence of market demand”.
In other words; if your MVP doesn’t resonate with your core demographic, you’ve either got your product wrong or you’ve got your demographic wrong.
For us it meant a few people other than ourselves using it. If you have to incentivise people to use your product other than with the value of the product itself — you have a big problem. In other words; if your MVP doesn’t resonate with your core demographic, you’ve either got your product wrong or you’ve got your demographic wrong.
We built Kap out in the open, sharing the GitHub page and alpha builds whenever we needed input. Already then we could tell that we were doing something right, the whole team and a handful of people were using even the most broken alpha builds daily!
This meant that from the very beginning we had an open communication channel with people actually using our app. We weren’t just building a product; we were building a community.
Iterate
A quote that really resonates with me is “fail forward fast”, it really captures what it’s all about.
Fail forward fast
In Mathematics iteration is defined as “the act of repeating a process with the aim of approaching a desired goal, target or result”. That translates perfectly to design and development.
Sometimes that leads to work being scrapped, redone or improved on. Understanding that it’s all part of the process, being wary of bias or getting overly attached to your own work helps maintain a healthy iterative cycle.
For us this also meant stopping up and taking the time needed to explore alternatives and knowing when to leave something and revisit it later.
Ultimately this helps build an environment ideas thrive in, where we discovered paths we wouldn’t have otherwise.
Pretty lean
Let’s summarise some of the key points and values that helped us execute on this idea
- Don’t kill ideas, if they’re not right for you they’ll wilt away.
- Identify distractions and noise as soon as it arises. Focus.
- Always know who you’re talking to, and who you want to be talking to. Understand and empathise with your demographic.
- Ask the right questions. Ask why? Question everything.
- Set a roadmap and time frame for a carefully considered and well defined MVP. Changes will happen; have a strong vision that doesn’t. Stay true to it.
- Get traction as early as possible, this is about figuring out if your product sticks and not necessarily about big numbers.
- Create an iterative and incremental process that works for you and your team, be as open and transparent as you possibly can. Ship early!
Introducing Kap 1.0
Our first stable release! We’re incredibly thankful for everyone who contributed and in different ways helped make this happen. We’re absolutely blown away by how supportive and receptive the community has been.
The first thing you’ll see in Kap 1.0 is the new dark design. We wanted a solution that was more aligned with our overall look, while still feeling at home on macOS. You’ll also notice that we’ve added additional export formats; in addition to GIF support that we introduced in 0.3, you can now export to WebM. To top it all off, you can also choose to include microphone audio in your recordings!
Diving deeper you’ll find the brand new Preferences including the ability to launch on system startup, select audio input device, define a default save to location, set a custom capture FPS, show or hide the mouse cursor in addition to highlight clicks and more.
Protip: Set your default save location to your cloud synced folder of choice for instant uploading and sharing! For example; create a Kaptures folder in Dropbox and choose it in Kap’s Preferences. Once you‘ve completed your recording and saved it, Dropbox will upload the file and easily let you grab a sharable link to it.
Open Source
For us Open Source was an entirely natural choice, we all got started by accidentally right clicking and hitting inspect. Open Source makes it easy for anyone to borrow, study and participate. It’s about making our work more accessible. It’s a fantastic way to contribute and give back, while pushing the tools and practices we use forward.
Thank you
A special thanks to Sindre Sorhus, Charlie Hield, Guillermo Rauch, Zeke Sikelianos, and everyone that contributed big and small.
Also a big thank you to ZEIT for hosting our downloads and updates, CircleCI for our builds and deployments and the amazing Electron community for their support.
