Sealas was our our first attempt to create a SaaS.
It started out as a simple idealistic idea: frustrated with the available options, we wanted to create an easy to use accounting application, that encrypts all user data before storing.
But we failed horribly.
How did we fail?
So first, let’s start with how we measure failure in our case, because failure can mean so many things. We didn’t fail because we had a bad logo, or bad landing page conversion, or bad reviews.
We failed because we had 0 paying customers. We had more or less 0 publicity. We had no tangible idea how to fix it, and not enough money we perceived could be a useful investment.
Lesson 1: Know your skillsets! They’re important.
Consultants did give us a small boost from time to time, but were they actually a good investment for us? No.
First, we didn’t have enough money, to really hire them help us with marketing long-term. Consultants are expensive as shit, and marketing/sales/publicity is what we completely lacked.
Thus, second, no consultant can give us advice so good, it will change our respective skillsets.
Neither of us is good with sales, neither from experience, nor from talent.
Lesson 2: Believe in your Product.
Another thing that always felt off was our belief in the product.
This wasn't something that was obvious on the surface level — or that either of us openly admitted. However, plans kept getting dragged out, "Just this one more feature, and then we can get started with 'marketing'."
But it wasn’t just that we never got to the point where we felt confident with the set of features implemented.
There was something more fundamentally off.
Lesson 3: Have a plan that makes sense.
So, let's go back to our initial conversation when the idea behind Sealas was formed:
There were two ideas behind us starting this project. On the one hand, I wanted to get away from freelancing work towards a more stable work environment. One in which I can work on my own products. One in which I can use my experiences as a freelancer to create tools that make the life of a freelancer easier.
On the other hand, we wanted to create a company in which it is possible to work for and on open source, and getting paid to do that.
So, we’re creating a proprietary SaaS product to do open source full time.
There’s something pretty wrong here.
Fixing the plan
Let’s have a look at is actually within our skillsets and experience:
We have been working with and on open source projects for as long as we had a career in IT, probably for as long as we have been in touch with computers.
We enjoy teaching people, be it by talking at conferences or at companies that hire us or by sharing our experiences in written form.
Teaching people is not only in itself a fulfilling activity, that certainly is part of it, but it is also always a wonderful opportunity to learn more yourself.
User Experience Design
We enjoy creating functional user experience design. Those directly exposed on the web to the public, or on those that are for the people interacting with the code or APIs.
One of the impulses behind creating Sealas, was to have among a sea of opaque interfaces, an accounting solution that is as easy and intuitive to use as possible.
Integrating our Skillset into a sensible business model
A new plan and model for Sealas is in order.
Point 1: Sealas is going to be open source
The first and most obvious point after discovering the inanity of our original plan was:
Let’s make Sealas open source. We are open source people, and creating proprietary software to support our open source work is a strange dissonance within our business model.
Point 2: Our process behind the development is going to be open source
Starting with this post, we are going to be publishing a weekly blog post about everything we do regarding Sealas: How and why we develop certain parts, how and why we design certain parts, and how we are doing with the business part of it.
Point 3: Our pricing is going to be Pay What You Want
We’ll go away from the classical fixed plan of SaaS pricing and go for a PWYW model.
This is so we can make the first two points our main focus and rely on the quality of our project or our documentation along the way to gather the attention of financial supporters. Either by paying directly for the project or by hiring us to do stuff we talk about.
Given this new direction, we should also establish our criteria of success:
We want this project to be a teaching experience, for us, and everyone who subscribes to our blog or newsletter. If, at the same time, our future PWYW customers are happy enough to allow us to do this full time, that would be absolutely fantastic. Indirect markers of success would be training gigs at companies who want to learn how to foster and use Open source, and its methods. But fundamentally, we want to not burn out, doing something that feels indescribably wrong.