Marcel Pociot

Windy is in early access!
A browser extension to transform every element on any website into Tailwind CSS

From idea to 5,000+ licenses sold in 12 months

Published on

Almost exactly one year ago I was sitting down with Sebastian to have lunch, where we discussed new Beyond Code product ideas. Up until that point we have already launched two successful video course:

  • Build A Chatbot - a video course about how to create your own PHP based chatbots
  • PHP Package Development - a video course about how to write and structure your PHP applications in packages

Scratch your own itch

While brainstorming about new and interesting product ideas, I remember that I mentioned to Sebastian that it's super annoying to use "php artisan tinker" in your projects in a good way. You first have to use your terminal of choice, open the folder, run "php artisan tinker" and then write the code that you want. If you want to write code that includes multiple lines of code, editing this can become pretty time consuming and cumbersome. Also, "php artisan tinker" does not immediately reflect code changes, as it requires you to manually restart the process. And if you want to use tinker via SSH, you have to do all of this via an active SSH connection.

So I knew that this is something that bugs me personally and something that I wanted to see improved - if only for myself.

Build publicly

On October 11th. 2019, I went to Twitter and asked about opinions on how I could write a native Mac application using JavaScript:

At that time, I didn't want to use Electron, because I believed that Electron would be slow and perform poorly. And this is a pretty common misconception of Electron - but I'll get to that later.

So even though people mentioned other technologies like Xamarin, Nativescript or React native, I went for the complete native approach and build the starting working on the first prototype of Tinkerwell in Swift. I have quite a good background in Objective-C, so the lightweight alternative of Swift - with it's Javascripty syntax felt really good and I was making a lot of progress real fast. I actually had planned some days off of work during that time and so most of the development happened in the evenings, after spending time with my family.

Only two days later - on October 13th - I tweeted this screenshot, of an already running version of Tinkerwell.

Basically the whole development of Tinkerwell was done publicly via Twitter. I had no idea if this is a product that would only be interesting to me, but after tweeting about it I received a lot of very positive feedback from others, that had the same issues with the current "php artisan tinker" solution that I had.

So tinkering with local Laravel projects was pretty much done in a proof of concept way in ~2 days and I showed this to Sebastian and we talked about the possible use cases for this, and Sebastian was extremely excited about it. But, his personal use case was more about looking into client projects, not just local development projects. So this means that he wanted to, for example, quickly perform an Eloquent query on a client project that is on a staging server.

So we needed a way of running Tinkerwell via SSH.

October 14th, one day later, I got this working. And most importantly, this did not modify your code in any way, or had you to install any third party packages. It was just plug-and-play, ready to tinker!

Over the coming days, I spent a lot of time polishing the user interface so that it does not look like a proof-of-concept anymore.

Determining the product type

As I said, while building Tinkerwell, I was mostly scratching my own itch. But as the feedback was so positive, we quickly realized that we are onto something that might be interesting for a lot of developers - not just Sebastian and me. That's also when we realized that we are able to sell this product - instead of simply giving it away for free.

But this also came with its own problems to solve. Having only sold video courses so far, we had to think about two solutions:

How would the licensing work?

As we have only sold online licenses to our video course platform up to this point, selling actual license keys for a software product was a completely different task. Let alone the fact, that we needed a payment provider to easily sell Tinkerwell within the EU, as we are a Germany based company.

After some research, I found out about Paddle - which is a fantastic service, that takes care of all the VAT mess when you sell digital goods. In addition to this, Paddle also provides a software development kit, to easily add licensing into your application.

Adding this to the Swift based version of Tinkerwell was really just adding 5 lines of code and we had solved the problem of selling and accessing our application.

How can we make sure to keep the app updated for our end users?

Distributing web applications is easy, when it comes to updates. If something crashes for you or your users, you can simply deploy a new update and you're good to go. In most cases, your users might not even notice that something was buggy and not working. If you ship software on the other hand, this becomes a lot harder. Once a version is published and downloaded by your users, they have this version installed. And if there's a bug in this version, you can't simply "hot patch" it, but you will need to roll out a separate update.

For the Swift based version, we used a framework called Sparkle that did all the heavy lifting of checking for updates, notifying users, showing release notes, etc.

Time to launch

Before we launched Tinkerwell, I gave access to the application to some of my friends and asked them about any bug-reports and their feedback, which has been really valuable. So after taking care of the initial batch of little bugs, it was time to release Tinkerwell.

Exactly 25 days after I asked on Twitter about a possible technology to use for a native Mac app, Tinkerwell was ready to go and I made the annonucement tweet:

I didn't know what to expect from this launch at all. The only promotion that I did was keep posting about building Tinkerwell publicly and that's pretty much it. Tinkerwell is not a SaaS where you have a trial period. You either go and buy it, or you don't.

On the launch day itself, we sold 325 Tinkerwell licenses, resulting in a net revenue of 4,133 Euros. That was simply amazing, especially given the super short development time that went into a verison 1.

Moving to Electron

The next days and weeks passed and we continued to release a lot of new features and updates to the Swift based version of Tinkerwell. But as the user base grew, more people were asking for a Linux and Windows version of Tinkerwell. At first I wanted to write these versions completely native as well, and started writing some C#, but I quickly realized that we at Beyond Code simply would not be able to deliver support and feature parity for a software that would be written in multiple languages.

During December of 2019, I started rewriting Tinkerwell from scratch using Electron. It actually wasn't as time consuming as you might think, because I was already using an HTML based code editor in Swift - and the code evaluation itself happens in a PHAR file. So I was actually able to reuse quite a lot of code while making the switch over to Electron.

As I said, I was first against writing Electron based applications, because I heard so much negative feedback about this. But once I started working with Electron, I noticed that most of the negative feedback is complete nonsense. Yes, there are poorly performing and sluggish Electron apps out there - but most of those apps are based on poorly performing and sluggish web experiences.

So when making the move to Electron, I did not notice any performance loss at all, which was great - because that's what I feared the most.

And in addition to this, moving to Electron allowed us to support Windows, Linux and macOS all using the same code base, which was amazing!

But it also required us to handle the whole licensing ourselves. Paddle unfortunately does not offer a SDK for Electron, so we had to build that from scratch. It now consists of a Laravel backend that validates the licenses and keeps track of license activations, as well as the application logic used to verify and activate the licenses.

Moving to Electron even lead me to record a complete stand-alone video course about writing Desktop applications with Electron - where I teach others how to implement things like licensing, auto-updated etc. in their own applications.

So overall, it maybe took me a month of rewriting Tinkerwell (again mostly in the evenings) and soon version 2 of Tinkerwell was ready to be released. It not only brought Windows and Linux support, but it also added the ability to be framework agnostic and supported Laravel and WordPress out of the box.

In the meantime, the supported frameworks by Tinkerwell have been extended to include:

  • Laravel
  • Symfony
  • Statamic
  • WordPress
  • Magento
  • Shopware
  • Typo3

and many more. You can even create your own custom drivers!

One year later

Since the release of Tinkerwell 2.0, we added a ton of new features, like support for Laravel Vapor or Docker, improved the overall user experience and updated the built-in Laravel version and I still use Tinkerwell every single day.

More than 5,000 people have already bought Tinkerwell and for most of them, it drastically changed the way that they work with their Laravel projects - which is extremely amazing.

We can't wait to share upcoming new Tinkerwell features with you and I'm very grateful for every developer that we are able to help with our software tools and video courses - not only Tinkerwell, but also HELO and Invoker.