I am finding a lawyer, working on onboarding sooner than expected, and thinking about pricing. We are close to the Beta MVP release of DevOps Metrics. Read more in the following sections of my weekly update on bootstrapping a SaaS offering.

I finished the groundwork for account management with users, all integrated via Auth0. I keep as much data as possible in my database. Although this may mean more work, in the beginning, it is beneficial for German or European companies. It means less to worry about in terms of data privacy.

In the MVP, the account management from the user perspective is basically: you can sign up and onboard yourself. For changes and questions, you write me an email.

I believe in smooth onboarding being extremely valuable for a SaaS. I strive to gather enough information during onboarding about the systems of the user/company so that I learn which other systems to integrate with next.

The onboarding consists of 3-5 steps. In former projects, I’ve learned that you need to communicate expectations in user interfaces. The user sees on the first screen that there will be steps. Recognize the step indicator at the bottom right corner.

DevOps Metrics Welcome Page in Onboarding

DevOps Metrics Welcome Page in Onboarding

That was far harder than expected! All people who advised me told me not to do on-premise and not write terms of services independently. Btw, I learned that this could also be illegal in Germany. So, finding a lawyer was the next goal, at best, one with an online background.

I found one later than I’d hoped, and it takes longer to produce terms of services and other contracts. That dragged me down. It cost me a lot of energy.

More focus on DevOps Metrics, less consulting, and an overall better-balanced schedule. What I did the last few months was not sustainable. I overloaded myself with expectations and did too many things in parallel. Plans for the following months:

  • finish consulting on 10th December
  • take a vacation to reset, work part-time on DevOps Metrics
  • starting mid-January, I spent 70% on DevOps Metrics, 30% on consulting and training gigs
  • evaluate and adapt end of March ‘22
  • burn cash until Q3 ‘22 if necessary

MVP Beta launch is close, so pricing is a question. Luckily, I was able to test this in calls with potential customers earlier this year. That’s why it is crucial to validate as much as possible before you build. (Ya, we can discuss if I may build too much in advance or make it too pretty, but hey, my journey, my mistakes. :-P)

Here is the problem I usually run into: I think many customers do not believe in paying for produced value. Gut feeling, DevOps Metrics is worth 1% of the monthly salary per developer in your teams. The product is not there yet. If it makes your teams 10-40% faster or improves quality and team dynamics, 1% of the monthly salary per developer is a no-brainer. That’s how I think about pricing: which value do you get from the solution?

But I need to start with pricing to get customers onto the product to develop it further with them.

That is the current pricing and also communicated to potential customers:

  • starts at 5 Euros per active contributor
  • active contributor is someone who committed at least once per month
  • with every more significant milestone release, I increase the price
  • when you sign-up, you have price stability for 12 months

This leaves enough room for experimentation and new pricing levels once there is more functionality.

Yes, why Felix?! … Well, I made mistakes and underestimated a lot. To give you a glimpse of what was not as planned or learning:

  • learning TailwindCSS
  • setting up a React project from scratch for the first time
  • learning React Hooks API, was used to components
  • conversations with potential customers
  • conversations with related people (e.g., advisors, fellow bootstrappers)
  • used a server middleware I was not familiar with: switched back to Spring MVC from Webflux
  • no on-premise, made SaaS solution with onboarding a priority
  • tackled the legal part too late
  • switched from macOS to Windows 10 as my development systems
  • could not end one client gig as soon as I hoped I could

A lot of me talk, sorry. But that is what I learned: I need more structure. Especially in Winter, now that the pandemic hits Germany hard, we will spend more time in our homes.

My current idea for a typical day, starting in December when my consulting gigs are finished:

  • wake up around 8 am, shower, and take a walk with podcast or audiobook for 15-30mins
  • work on product development for a 4hrs block
  • do my workout, shower - then open email and social media first time
  • spent the afternoon on calls, marketing, and business development
  • due to intermittent feasting: first food after 6 pm
  • try to spend the evening with fun activities

Rinse and repeat.

Currently, my creativity and concentration are consumed by early and mid-day calls with clients.

In the coffee kitchen, we chat about interesting and funny stuff like you would be a co-worker.

It would be best if you read this book: The Minimalist Entrepreneur. It was recommended to me, and I love it. Written by the founder of Gumroad, it gives you a blueprint for developing business ideas and building a profitable, sustainable service and product.

Some things I practice already, some not. I think there is still a lot of survivorship bias and luck involved, but his reasoning is on point:

  • profitability first
  • community first
  • build as little as possible
  • sell one by one to your first 100 customers
  • market by being you

Very strong imho: Build the house you want to live in.

In the following weeks, the goal is clear: release the MVP to a few interested customers. To make this work, I need to finish the legal parts first.

See you soon.

– Felix

Hey, I'm Felix. I share my journey on bootstrapping products and service businesses. Additionally, I write about my learnings in software architecture and tech leadership that I gather during my consulting gigs.
Hey, I'm Felix. I share my journey on bootstrapping products and service businesses. Additionally, I write about my learnings in software architecture and tech leadership that I gather during my consulting gigs.