Benedikt Deicke - Software Engineer

Ruby Templating: Baking an Interpreter

2019-09-24T00:00:00+00:00

We hope you’ve got your stroopwafels warmed on top of your coffee because today we’re gluing things up with sticky stroop (the syrup that makes the two halves of a stroopwafel stick together). In the first two parts of our series, we baked a Lexer and a Parser and now, we’re adding the Interpreter and gluing things together by pouring stroop over them.

Digging Deeper into Ruby Templating: The Parser

2019-07-30T00:00:00+00:00

Today, we continue our journey into Ruby Templating. With the lexer in place, let’s move on to the next step: The parser.

Last time, we looked at string interpolation and subsequently, dived into creating our own templating language. We started by implementing a lexer that reads a template and converts it into a stream of tokens. Today, we’ll implement the accompanying parser. We will also dip our toes into a bit of language theory.

Brewing our own Template Lexer in Ruby

2019-07-02T00:00:00+00:00

Put on your scuba diving suite and pack your stencils, we’re diving into Templates today!

Most software that renders web pages or generates emails uses templating to embed variable data into text documents. The main structure of the document is often set up in a static template with placeholders for the data. The variable data, like user names or web page contents, replace the placeholders while rendering the page.

For our dive into templating, we’ll implement a subset of Mustache, a templating language that’s available in many programming languages. In this episode, we’ll investigate different ways of templating. We’ll start out looking at string concatenation, and end up writing our own lexer to allow for more complex templates.

A Background Processing System in Ruby

2019-04-02T00:00:00+00:00

In today’s post, we are going to implement a naive background processing system for fun! We might learn some things along the way as a peek into the the internals of popular background processing systems like Sidekiq. The product of this fun is by no means intended for production use.

Let’s imagine we have a task in our application that loads one or more websites and extracts their titles. As we don’t have any influence on the performance of these websites, we’d like to perform the task outside our main thread (or the current request—if we’re building a web application), but in the background.

The Magic of Class-level Instance Variables

2018-10-02T00:00:00+00:00

In a previous Ruby Magic, we figured out how to reliably inject modules into classes by overwriting its .new method, allowing us to wrap methods with additional behavior.

This time, we’re taking it one step further by extracting that behaviour into a module of its own so we can reuse it. We’ll build a Wrappable module that handles the class extension for us, and we’ll learn all about class-level instance variables along the way. Let’s dive right in!

Changing the Way Ruby Creates Objects

2018-08-07T00:00:00+00:00

One of the things that makes Ruby great is that we can customize almost anything to our needs. This is both useful and dangerous. It’s easy to shoot ourselves in the foot, but when used carefully, this can result in pretty powerful solutions.

2017 in Review

2018-01-06T00:00:00+00:00

The start of a new year is a great time to reflect and think about the previous one. Two years ago, I started publishing my thoughts about my personal year. With 2018 just starting off, it’s time for me to look back at 2017.

Feel free to go back to my reviews of 2015 and 2016 for additional context.

The year in general

2017 was weird. I don’t really know how to feel about it. It had some highs and a good bunch of low moments, both in work and private life.

Twelve months ago, I set out with four goals:

Relaunch my website with productized consulting offerings
Launch a new product or relaunch Stage with a twist
Maintain overall revenue (from both consulting and products)
Move into a new apartment.

At the end, I managed to achieve only two of them: I relaunched my website and moved into a new apartment. While I announced new products, I didn’t launch anything and I made it to about 2/3 of my revenue goal.

The consulting business

I struggled a bit with consulting this year, even though it was off to a good start. My first consulting project of the year, Tiny Reminder, was one of the most fun projects in a long time.

Thanks to Jane Portman’s help, I was able to relaunch my website and started offering consultation calls and productized services. At about the same time I started an ongoing maintenance contract with a local startup. This provided some steady income throughout the year.

Apart from that, I haven’t figured out a way to consistently and reliably get new work. This resulted in a drought this summer with almost no new work for weeks. This lead to taking on projects that didn’t really excite me, and while it was okay working on them, I didn’t enjoy it.

It also made me give working through recruiting agencies a try. This quickly turned into a huge mess, reaffirming my previous rule of not working via recruiters.

When I finally managed to get more work, it was late in the year. I overcommitted on too much stuff at once. As a result, the last quarter was incredibly stressful.

The product business

I started into 2017 knowing that there’s no sense in putting more work into Stage unless I find some way to make it drastically more interesting to the target audience. As I didn’t have a clear idea on how to do this, I was open to focusing on something new. I set a goal of launching a new product (or a major change to Stage) within the year.

For the most part of the year, I spent a lot of time thinking about what to do next. As it took me several years to build and launch Stage, I was hesitant about starting something, not knowing if it will lead to something. I abandoned a lot of things, because I wasn’t sure if it’s worth the effort.

The irony of this is, of course, that it resulted in me not working on anything. Instead, I wasted my time worrying about starting the wrong thing. It was in August, when I finally realized this and started moving forward on some ideas I had.

The SaaS Guidebook

One of the ideas I dabbled with was starting a new podcast related to the technical side of building and running SaaS applications. While that idea isn’t off the table, it sparked the idea of writing a book on that topic.

In the last couple of years, I gained experience in building SaaS applications for my consulting clients and myself. The lessons learned helped me a lot with my own projects and allowed me to help friends with their SaaS products.

As of today, I’m in the process of writing the book, which is a lot harder than I anticipated. While I have a rough idea about the topics, it’s tough to find the time to write. I’m confident that I’ll be able to finish it eventually, though.

Userlist

In September, Jane Portman approached me with an idea for a new product. We teamed up with Claire Suellentrop to build and launch Userlist.

Our goal for Userlist is to build a tool that allows SaaS founders to see what their users are doing inside their application, and communicate with them based on their behavior.

What excites me most about this, is the team: With Jane’s experience in design, Claire’s marketing expertise, and my experience with the technical parts, I feel like we’re in a good position to build something great.

As of today, we’re early in the process and figuring out the details. As you’re reading this I just started writing the first lines of code. If you want to follow along our journey, sign up for the mailing list. I’ll also be posting updates about the development process on Twitter.

Stage CMS

Even though I didn’t focus on Stage this year, there has been progress. Two new websites got build on the platform, which made me cross €500 in monthly recurring revenue.

I hired Cristina Mlynek to do some SEO, improve the content of the website, as well as manage Stage’s social media presence. It’s nice to see some improvements, without having to do the work myself.

The Conference

One of the highlights this year was the first edition of FemtoConf, the conference I’m organizing together with Christoph Engelhardt. It was intended to be a meet-up for listeners of our podcast and friends from the micropreneur community. Somehow it turned into a full-blown conference.

The conference was a great success. One of our goals was to give it a similar vibe as MicroConf Europe (which was a huge inspiration). We wanted it to have a focus on meeting people and building friendships, and we were able to achieve it.

As feedback from attendees was very positive, we’re organizing a second edition in March.

Private Life

As mentioned above, my partner and I moved into a new home. After a long hunt for a new apartment, we fled the tiny one bedroom apartment I moved into after finishing university. Now, we live a bit outside of Darmstadt, Germany in a quiet neighborhood and don’t have to worry about where to store our stuff anymore. The process of moving was stressful. The amount of things to think about and take care of was overwhelming at times.

On a sad note, I lost my last two grandparents this year. Seeing an entire generation of my family disappear within a couple of months had a huge impact on me.

In addition to the stressful work life in the last quarter of the year, my partner got sick. She even got hospitalized for a couple of days. While it’s nothing life threatening, it still dragged both of us down. She’s feeling a bit better now, but it’s still not clear what causes her health issues. Fingers crossed the doctors will figure it out soon.

Lessons learned in 2017

Looking back at the year, I learned a few important things:

Momentum is important. I got stuck overthinking every possible way to move forward. I was so afraid to waste my time on the wrong things that I instead wasted my time doing nothing. The moment I realized that dilemma, it was easier to start working on new things and putting them out there to gather feedback.
It’s okay to not work on some things. In October, I counted ongoing commitments (client projects, personal work related projects) and got the crazy number of 14 as a result. This made it clear that I had to explicitly put some things on the back burner and not try to get everything done at once.
Community and relationships are important. My partner, my family, my friends, and my mastermind groups helped me a lot to get through the tougher parts of my year. Thanks to all of you for your encouragement and support.

Goals for 2018

As with previous years, I set some goals I want to achieve. Unlike previous years, I’ll try a new approach. Instead of pursuing a set of goals for the entire year, I’ll break it them into quarterly goals. This will hopefully make it easer to come up with a plan to achieve them.

Nonetheless, for the sake of simplicity, these are the goals I want to achieve in 2018:

Launching Userlist
Launching The SaaS Guidebook
Get my overall revenue back to the level of 2016
Improve my personal brand

Check back in a year to learn if I managed to achieve some of them. As always, I hope this was interesting and that you got something out of it for yourself. Thanks a lot for reading and a Happy New Year 2018!

Don't call us, we'll call you: Sending webhooks with Rails

2017-09-20T00:00:00+00:00

Integrating with other services is on the roadmap of almost any SaaS application. There’s only so much your application can do itself. Sometimes it’s best to leave tasks up to others who specialize on them.

Building specialized integrations with other tools is one way to approach this. However, wouldn’t it be nice if your application had a generic way for others to be notified about things that happen on your side so they can work with that information?

When it comes to passing data around in (near) realtime, webhooks are the way to go. There is no real standard for them, but most services are working with simple POST requests that send JSON as their request body. Webhooks are triggered for different events and transmit relevant data to other parties.

In the following, we’ll be talking about how to allow other services to integrate with your application, by allowing them to register webhook endpoints and notifying them when something interesting happens.

Registering webhook endpoints

In order to send webhooks, you have to know where to send them to. You have to provide your users with a way to set up new webhook endpoints. This can be done via user interface. In it’s simplest form, it would just be a textfield where users can enter a URL. In more advanced scenarios, you might allow them to specify multiple different endpoints and the types of events that should send a webhook to these endpoints.

To make things easier for your users, you can also decide to allow webhook endpoint registration via your API. This way, other services can just setup the endpoints they need, making things a lot easier for your users. Add authentication via OAuth on top, and it can be as easy as a single click of a button.

We start off by implementing a Webhook::Endpoint model. Each endpoint needs a target url, a set of events that it cares about, and an account this endpoint belongs to. To make things a little easier for ourselves, we use PostgreSQL’s array columns to store the events as a simple list.

class CreateWebhookEndpoints < ActiveRecord::Migration[5.1]
  def change
    create_table :webhook_endpoints do |t|
      t.string :target_url, null: false
      t.string :events, null: false, array: true
      t.references :account, foreign_key: true, null: false
      t.timestamps
      t.index :events
    end
  end
end

This example uses namespaces to keep things a bit more organized. We put all webhooks related code into a webhook directory. In the database we prefix all webhook related tables with webhook_.

# app/models/webhook/endpoint.rb
module Webhook
  class Endpoint < ApplicationRecord
    def self.table_name_prefix
      'webhook_'
    end

    # ...
end

To make the events array column work, we have to tell Rails about it by adding an attribute macro to the model.

attribute :events, :string, array: true, default: []

On the validation side, we only want valid http urls as target url. Luckily Ruby comes with a handy URI regular expression in it’s standard library, ready for us to use. We also add a presence validation for the events, so every endpoint is triggered by at least one event.

validates :target_url,
  presence: true,
  format: URI.regexp(%w(http https))

validates :events,
  presence: true

In order to quickly retrieve endpoints for one (or more) events later on, we implement a custom scope. It uses PostgreSQL’s contains operator (@>) to just return the endpoints interested in a particular event.

def self.for_event(events)
  where('events @> ARRAY[?]::varchar[]', Array(events))
end

Notice that we’re using Array(events) to convert the methods arguments into an array, or just leave it untouched if it already is one. This allows us to call the scope with one event name, or an array of multiple ones.

Next, we add some normalization and sanitization logic to the events setter method. This can be done, by simply overwriting the method, doing the necessary changes, and then calling super.

def events=(events)
  events = Array(events).map { |event| event.to_s.underscore }
  super(Webhook::Event::EVENT_TYPES & events)
end

In this case we’re normalizing the events into underscore strings. Afterwards we intersect the resulting array with a predefined array of event names (more on that later), to make sure all the events name are actually valid.

Finally, we add a method to deliver an event to this endpoint. It’s empty on purpose for now.

def deliver(event)
end

With the Webhook::Endpoint model in place, we need a controller, the view layer and most likely an API representation for it. There’s nothing special about the implementation of all of this, so we won’t cover it here.

Representing events

As mentioned before there is no standard on how webhook payloads should look like. In this example we use them to represent events that are triggered within your application. Assuming the application somehow works with a Project model, here’s an example of an event for a newly created project.

{
  "event_name": "project_created",
  "project": {
    "name": "Example Project",
  }
}

The webhook payload follows a simple structure. It always has an event_name and a set of embedded models with relevant data. You’re of course free to settle on a different format. Instead of embedding the event name in the payload itself, you might choose to send an X-Event-Name header with your request. Whatever you do, just stick to a pattern for all the webhooks you’re sending and document it. All the developers building integrations with your application will thank you for it.

Let’s implement a Webhook::Event model to represent a single event. This can be done as “plain old ruby object”. If you want to keep track of the state of every single event, you can store all events in the database as well. For the purpose of this example, we’ll keep it simple.

The implementation of Webhook::Event is straight-forward. It’s an object with two instance variables. One for the event’s name, and another one for its (optional) payload. To keep track of valid events, we add the EVENT_TYPES constant used earlier. Whenever you add a new event, add it to this list.

# app/models/webhook/event.rb
module Webhook
  class Event
    EVENT_TYPES = %w(
      project_created
      project_updated
      project_destroyed
    ).freeze

    attr_reader :event_name, :payload

    def initialize(event_name, payload = {})
      @event_name = event_name
      @payload = payload
    end

    # ...
end

As we want events to be delivered as JSON in the HTTP request’s body, we have to implement serialization for this event model. This can be as simple as taking a copy of the payload and adding the event_name to it.

def as_json(*args)
  hash = payload.dup || {}
  hash[:event_name] = event_name
  hash
end

However, we want to keep our code clean and not come up with the entire payload for every single event. If you’re using ActiveModel::Serializers to handle serialization of your API resources, you can leverage it to properly serialize the payload for you.

def as_json(*args)
  hash = payload.transform_values do |value|
    serialize_resource(value).as_json(*args)
  end

  hash[:event_name] = event_name
  hash
end

private

def serialize_resource(resource)
  ActiveModelSerializers::SerializableResource.new(resource, {})
end

This way, you can create events and simply pass your model instances as payload.

Webhook::Event.new(:project_created, { project: project })

Triggering events

With both Webhook::Endpoint and Webhook::Event in place, it’s time to actually trigger events. To keep things organized and DRY, we use a module to implement this. Whenever you want to trigger events, you just include that module in your model and call one of the helper methods.

We start off by adding a webhook_scope method. It’s just a stub, that has to be overwritten by each model to return the scope of the webhooks. If you’re getting a bit confused by that, don’t worry. It’ll get clear once you see the module used in an actual example in a few moments.

# app/models/webhook/delivery.rb
module Webhook
  module Delivery
    extend ActiveSupport::Concern

    def webhook_scope
      raise NotImplementedError
    end

    # ...
end

Next, we add a method to trigger events. It just takes two arguments. One for the event name, and one for its payload. It then constructs an Webhook::Event object from those and asks every endpoint interested in the event to deliver it.

def deliver_webhook_event(event_name, payload)
  event = Webhook::Event.new(event_name, payload || {})
  webhook_scope.webhook_endpoints.for_event(event_name).each do |endpoint|
    endpoint.deliver(event)
  end
end

To make things even simpler, we implement a default webhook_payload method, as well as a deliver_webhook method. The latter relies on a naming convention to generate an event for the current model based on an action name.

def webhook_payload
 {}
end

def deliver_webhook(action)
  event_name = "#{self.class.name.underscore}_#{action}"
  deliver_webhook_event(event_name, webhook_payload)
end

Coming back to our projects example from earlier, we can now trigger events like this:

# app/models/project.rb
class Project < ApplicationRecord
  include Webhook::Delivery

  after_commit on: :create do
    deliver_webhook(:created)
  end

  belongs_to :account

private

  def webhook_scope
    account
  end

  def webhook_payload
    { project: self }
  end
end

As most events revolve around creating, updating, and removing models in your database, we can also build a simple module to handle those events automatically.

# app/models/webhook/observable.rb
module Webhook
  module Observable
    extend ActiveSupport::Concern
    include Webhook::Delivery

    included do
      after_commit on: :create do
        deliver_webhook(:created)
      end

      after_commit on: :update do
        deliver_webhook(:updated)
      end

      after_commit on: :destroy do
        deliver_webhook(:destroyed)
      end
    end
  end
end

Please notice that the module is using after_commit callbacks. It’s important to only send webhooks after the data is actually present in your database. This is to prevent weird “not found” errors in the occasions where webhooks are delivered faster than your database takes to commit the transactions or it’s part of a larger transaction that fails shortly afterwards.

Using the Webhook::Observable module, adding webhook events to a model becomes as simple as this:

class Project < ApplicationRecord
  include Webhook::Observable

  belongs_to :account

private

  def webhook_scope
    account
  end

  def webhook_payload
    { project: self }
  end
end

Delivering webhooks

To deliver webhooks, I strongly recommend using a background job queue. As delivery depends on 3rd party services, you should expect them to be slow or even unreachable. As your application might send webhooks to multiple endpoints per event, you definitely don’t want your users having to wait until all of them are delivered. Using a queue also allows for retries when delivery fails for some reason.

In this example, we’re using Sidekiq as background job queue. This is not a requirement, though. ActiveJob with any backend you like will to this job as well.

# app/workers/webhook/delivery_worker.rb
require 'net/http'

module Webhook
  class DeliveryWorker
    include Sidekiq::Worker

    def perform(endpoint_id, payload)
      return unless endpoint = Webhook::Endpoint.find(endpoint_id)
      response = request(endpoint.target_url, payload)

      case response.code
      when 410
        endpoint.destroy
      when 400..599
        raise response.to_s
      end
    end

    # ...
end

The implementation will raise an exception for all HTTP status codes that indicate some sort of error. Sidekiq will catch the exception and just retry the delivery a few moments later. Please know that HTTP status code 410 Gone is an exception. It’s a small idea picked up from Zapier. Whenever the endpoint returns a 410, we consider it no longer valid and just remove it from the database.

The actual HTTP request is nothing fancy. As a result, we just use Net::HTTP from Ruby’s standard library.

def request(endpoint, payload)
  uri = URI.parse(endpoint)

  request = Net::HTTP::Post.new(uri.request_uri)
  request['Content-Type'] = 'application/json'
  request.body = payload

  http = Net::HTTP.new(uri.host, uri.port)
  http.use_ssl = (uri.scheme == 'https')

  http.request(request)
end

Finally, we add the implementation of Webhook::Endpoint#deliver we skipped earlier. It enqueues a new Webhook::DeliveryWorker for the given event.

def deliver(event)
  Webhook::DeliveryWorker.perform_async(id, event.to_json)
end

It’s important to serialize the event model in the very moment the delivery is triggered. Otherwise the payload might have changed until the delivery takes place, resulting in weird data and confused developers.

Taking things one step further

While the implementation shown here covers the most important parts to get webhooks implemented in your application, there are a few more things you should consider.

Allowing for authenticity checks

As webhooks are usually delivered to more or less public endpoints it’s best to add some way that allows the receiving application to ensure the data is actually coming from you. One common way to do this is to add a signature somewhere in the payload. This can either be done in the JSON body or in a custom HTTP header. The signature should be based on the payload itself and a secret only known to the sending and the receiving application.

Accidental Denial of Service attacks

Based on the details of your application, it might happen that you send a lot of requests to the endpoints. Some of them might not be able to handle the load. With retries in place, the number of requests sent to the endpoint will only increase, making things worse. It’s a good idea to have some sort of rate limiting in place or even temporarily disable an endpoint that is unable to process requests right now.

Wrapping up

Webhooks are a great way to allow applications to integrate with yours. At their core, they’re simple and easy to understand HTTP requests. With just a little bit of code, they allow your users to use your application in ways that you didn’t think of before.

You can get the source code of everything explained in this article at GitHub’s Gist. You should be able to use it in your existing applications, with just minor modifications.

Just skip it: 9 features your product does not need to launch

2017-04-04T00:00:00+00:00

Building a SaaS (or any software product, really) takes a lot of time and money. It’s hard to stay focused on the things that actually produce value for your customers. In the following, I’ll show you a few things that you can easily skip until after launching. This way, you’ll launch earlier, and maybe even learn that you don’t need some of the features you thought everyone wants.

1. Self-service on-boarding

The dream of SaaS is that it’s full self-service at some point. People sign up, give you money, and you never have to talk to them. To achieve this dream, you spend a lot of time building and tweaking your self-service customer on-boarding flow. You create wizards, guided tours and streamline everything.

However, when you have not launched yet, I urge you to skip it. Instead, manually set up your customer’s accounts for them. Afterwards, invite them to a screen sharing call and walk them through your application.

Or, for a better effect, let them try to figure it out themselves, while you’re watching. When they get stuck or confused, help them by explaining things. This way, you learn about the actual problems of your application and any potential mismatch between your assumptions and your customer’s expectations.

Take notes about the things that don’t explain themselves and improve them. In the end, you’ll get a much better understanding about what you have to (or don’t have to) explain in a walkthrough.

2. Activity streams

Activity streams are a good way to show your customers what happened while they were away. While they’re a good way to show and document the value generated by your tool, they rarely are the feature that produces the value for your customer.

On top of that, there has to be a lot of activity for them to become meaningful. So, when people just signed up, they are not going to see anything useful anyways.

Instead of implementing activity streams before even launching, remove that feature until your customers request some insights into their account activity.

3. Payment Integration

Don’t implement a payment integration before you launch. I know, this sounds bit unintuitive, because you’re building this product to make some money.

However, not implementing a payment integration, does not mean you cannot get paid.

Why don’t you start by invoicing your customers manually, asking them to wire transfer the money? You can also use services like PayPal or Gumroad to sell pre-paid subscriptions packages for a couple of months. Those tools are set up within minutes and don’t require you to integrate anything into your application.

Even if you’re expecting a huge amount of new customers at launch, you don’t need automated billing right away. You have until the end of your trial period to get payments implemented.

4. Permissions / User Roles

A fine grained roles and permissions systems is sometimes praised as a great feature of your application.

In my opinion, it makes things more complicated for both you and your users. Your application only needs one or two different roles. Chances are good that it doesn’t need them at all.

For your launch, only allow one user per customer. People can easily share their login credentials should multiple people need to work with your application. Don’t worry too much about someone in your customer’s team screwing up the settings or accidentally deleting something. A complex permissions system is not the fix for trust and competence issues.

5. Administration Interface

It’s tempting to implement a secret administration interface that gives you convenient access to your customer’s data. In my experience, you don’t really need it to get started, though.

For one, you don’t have a lot of data and customers to look at in the first place. For another, you can just peek into the database, or ask your developer to run a quick query.

Over time, you’ll recognize what bits of information you actually need, and which tasks you have to execute often. As soon as it takes your developer a substantial amount of time to do these things for you, it makes sense to implement a dedicated administration interface for those things.

6. Advanced Technology / Architecture / Infrastructure

When starting out, you want to use the latest and greatest piece of technology around. It’s nice and shiny, and all the cool kids are using it right now.

However, you don’t need it to solve your customer’s actual problems. A fancy, one-page, real-time, super fast JavaScript application is pretty cool, but it’ll take a lot longer to develop. A simple form with a bit of code in the back-end will do the job just as good.

Just because some piece of technology is the best thing for a large, successful startup with lots of customers and engineers, doesn’t mean it’s the right thing for your application. Start with something simple, and build up from there. Build more advanced stuff when you actually need it. You cannot anticipate the problems you’ll run into eventually, so don’t try to anticipate them by using an advanced and complex setup.

When it comes to infrastructure (servers and stuff), keep things simple as well. Don’t expect huge growth in the early days that would warrant a super scalable and high performance infrastructure setup. It’s not worth the time and money unless you are absolutely certain you’ll need it.

7. Settings and customizations

For the initial version of your product, implement the bare minimum of features you need to solve the customer’s problem. Try to optimize for just one simple use case, and don’t any customizing.

For one, this will make the application easier to use, for another it’ll save you a lot of time to build it. Pick some reasonable defaults and stick with them until enough people request more options and settings to tweak.

This includes things like: The number of different types of things (Field types, modes, …), custom themes and branding, available languages, sorting, filters, pagination, different views on the same data, and a whole lot more.

A good example for this is is Tiny Reminder. In the first sketches of the product, there were several types of form fields that people could use collect data from their clients. In the process of cutting down unnecessary features, Jane removed all but four simple ones (Short Text, Long Text, Tasks, and Files). Up to now, nobody missed the ones she decided to drop.

8. Metrics

Collecting data is important to understand how your customers use your application. However, the metrics are meaningless until you collected a lot of data points.

Don’t attempt to measure and track every single action your customers might take in your application. Skip that part until after your launch. You can get a pretty good first idea about your customer’s usage patterns just by looking at the data in your database.

Once this data doesn’t answer all your questions, slowly start collecting data points for different things. As always, keep it simple and to a bare minimum. Having an overwhelming amount of data only makes it harder to draw any conclusions from it.

9. Customer support tool / knowledge base

Customer support is one of the core features your application should offer. It’s important to keep your customers happy. They will run into problems and there should be an easy way for them to get help.

However, a simple support email address is more than enough to get started. You don’t need a dedicated customer support tool. Once you get too many support requests to be able to handle them via email, you can integrate a proper tool.

This also is true for the knowledge base. It’s a super useful tool to reduce the number of support requests you get. Don’t bother building it before your launch. Instead, learn from the common issues your customers have and write the knowledge base content based on that.

Bonus: Don’t build software at all

Did you ever consider that you might not even need to build a software product? Chances are, your customer’s problems can be fixed by offering a service. Start by doing things manually and learn about your customer’s actual problems and requirements.

This gets you into learning mode quickly, and you’ll save a lot of time and money that would otherwise go into building a software product that doesn’t fit your customers’ needs.

Brian Casel’s Audience Ops is a great example of this. Instead of starting with software, he started offering a service. Only now that he knows what tools would actually be useful, he’s building a software product.

Your mileage may vary…

As always, your mileage may vary. Depending on your actual product you cannot go without some of these features. Be careful about the features you add to your application early on. While most of the things listed above are useful, it’s probably too early to spend time on them.

2016 in Review

2017-01-04T00:00:00+00:00

A year ago, I published my first Year in Review post. I did not publish anything since that review and therefore was a little hesitant about writing one for 2016. It was a tweet by Jamie Lawrence that convinced me to write this review:

“Year in review” posts are great way of rewriting history, and a terrible way to compare yourself with others – Jamie Lawrence

However, my intention isn’t to rewrite history. Instead, I want to preserve the things (both good and bad) that happened this year.

To give you some perspective, please allow me to introduce myself. I’m Benedikt Deicke, a software engineer and consultant who launched Stage, a content management system for bands, as a side project in 2015.

The year in general

Looking back at 2016, I’m a little disappointed, even though I shouldn’t be. My goals for the year included increasing my revenue, growing Stage to 1,000€ MRR, and launching a productized consulting offering. I only count the revenue goal as a success, but more on that below.

The consulting business

In contrast to 2015, the consulting business was a smooth ride. I was able to hit my revenue goal for the year by consulting alone, and even a few months early. I had the pleasure of working on interesting projects, together with people I like and admire.

The lessons learned in previous years definitely helped to make this possible.

I also sold some coaching and mentoring retainer packages. While this was part of my goals for the year, I only call it half a success, because I never announced them publicly.

The SaaS business

One of my biggest goals this year, was to grow Stage to 1.000€ in monthly recurring revenue. I started the year with a baseline of 357€ MRR. Unfortunately, I quickly realized that adding 643€ was going to be tough. My target audience (professional musicians) are hard to reach online and don’t care about their websites that much. In the end, I managed to close two deals, adding 58€ in revenue. A third deal I closed in 2016 will start adding another 79€ in MRR this February. So, depending on how you count it, I’m at least 506€ short of my goal.

Here are the things I tried to grow Stage this year:

Lead generation

To help achieve my MRR goal, I hired a lead generation service. The goal was to get prequalified leads for one-on-one product demos. This was one of the worst experiences this year. While happily taking my money, they failed to deliver at all. Instead I got put off with empty promises for the first few weeks, until they finally decided to stop responding to messages at all. It took several weeks to get both the subscription cancelled and my money back. The service has been shut down completely since.

Doing cold outreach

In another effort, I hired a virtual assistant to help me with researching potential leads. It was a great experience and my virtual assistant was a great help. She went through several record label websites, compiled lists of bands, and researched their managers.

I later used that list and emailed potential customers. While I got a pretty good response rate, none of them were interested in the product.

In addition, I tried reaching out to record labels. Thanks to a friend, I even got an in-person meeting with a major record label. Unfortunately they also were not interested in my offerings.

The three deals I closed this year, all came via referrals from friends and people I met in previous years. So, to sum it up, it was a great learning experience with no effect on growth at all.

Bye, bye profit…

To make things worse, the hosting provider I was using for Stage, shut down in early 2016. They were a perfect fit for the requirements Stage had. Also they were quite cheap compared to the alternatives. In hindsight that should have been a warning sign.

They were kind enough to announce the end of their service several months in advance. Still, I had to move to multiple new providers (they were the only ones that combined all of my needs in one service) and the costs skyrocketed. What once was a profitable (read: making a bit more than 0€) product was now losing several hundred euros per month. Most of it was fixed costs, though. Having my MRR goal in mind I had some hopes to make it up in added revenue, but as you know that never happened.

For 2017, I’m hoping to be able restructure parts of the product to be able to cut costs down to a level where it stops draining my bank account.

New endeavors

In previous years, I tried to focus on Stage as my one and only side project. In the second half of the year, I allowed myself to think about new ideas.

One result of this was EVGadgets, an affiliate website for electric vehicle accessories. The plan was to outsource the writing on Upwork, publish a lot of reviews, get picked up by Google and earn a lot of money using affiliate links.

I totally underestimated how hard it is to find good people on Upwork, though. None of the reviews I got was great and all had to be edited quite a bit. A few of the reviews were so bad, it didn’t even make sense to edit them.

What really kicked all my motivation out of me, was dealing with the accounting and legal side of hiring through Upwork. The amount of work I had to put in to be on the safe side made it unbearable.

Right now, the site is still up and I’m not ruling out giving it another try. But it’s definitely not going to make any money anytime soon.

The Podcast

In 2016, Christoph Engelhardt and I continued recording episodes for our (German) podcast Nebenberuf Startup. In total, we published 17 episodes. It’s fewer episodes than we set out to publish. We failed to stick to our bi-weekly schedule because of our other commitments. Still, it was fun to record episodes with people like Steli Efti, Åke Brattberg, and Daniel Alm.

FemtoConf

The most exciting thing coming out of the podcast this year is FemtoConf 2017. What was meant as a meetup with some of our listeners, turned into an international mini conference. People form Germany, Finland, Czech Republic, Spain, France, Slovenia, Russia, and even the US bought a ticket to be part of it. Check back in a year to learn how it went.

Rails Girls Summer of Code and Refugees on Rails

There was no Rails Girls Frankfurt event in 2016. Instead I joined Refugees on Rails Aschaffenburg as a coach and Rails Girls Summer of Code as a supervisor. As always, I loved meeting new people while teaching how to become a software developer.

Goals for 2017

Maintain overall revenue

While I’m a little wary about the usefulness of this goal, I’d like to maintain my revenue generated in 2016. While it helps to have a clear number in mind, it also makes it easy to choose the quicker ways to make money over the ones that take time to grow.

Relaunch my website with productized consulting offerings

I definitely want to relaunch my website this year. For one, I’m getting a bit tired by the design. More importantly though, I finally want to focus on offering productized consulting packages.

Launch a new product or relaunch Stage with a twist

During 2016, it became clear that Stage is a tough product to sell. Maybe it’s the target audience, the product, or me just being bad at selling. For 2017, I want to come up with something new and launch it. That might be a new product, or a new major feature of Stage. Whatever it’ll be, I want to make sure, it’ll fix a pain people are having, making it easier to sell it.

Move into a new apartment

On the personal side of things, I want to move into a new apartment. We’ve been kinda looking for a new one for a while now, but it was never a serious undertaking. Promoting this to a goal for the year will help to make it happen.

Conclusion

As mentioned earlier, I’m a bit disappointed about 2016. I was wishing for a better result when it comes to Stage. Nonetheless, I learned a lot of things while trying to make it work. Most importantly: There are no silver bullets for anything.

I hope you got some value out of reading this. I tried to include all business related ups and downs I had this year. Thanks for reading and a Happy New Year 2017!

2015 in Review

2016-01-04T00:00:00+00:00

This is the first time I’m writing a “Year in Review” post. In the past, I wasn’t sure about the value of me writing a post like this. However, I always liked to read similar posts by people I know. I hope there’s something in this post that is of value to you, or at least inspires you in some way or another.

Let me introduce myself: I’m Benedikt Deicke. I’m currently running two businesses side-by-side. Most of the time I’m working as a consultant, helping small and medium businesses with their software development projects. Additionally I’m working on a product called Stage, a content management system for band websites.

The year in general

All in all, I’m quite happy about how this year turned out to be. The fact that it was off to a rough start probably had some influence on that. One of my clients of 2014 was close to bankruptcy and still owed me a bunch of cash. As a result, I barely made enough money to pay my rent and living in 2014. That was a real downer, but it also had a positive effect on me. For the first time ever, I made the choice to set goals for 2015. I set an overall revenue goal, committed on launching Stage, agreed to write 20 blog posts, and made the decision to refurnish our bedroom.

The SaaS business

I started the year focusing on Stage. It wasn’t launched to the public yet, and I was working on some new features to be able to onboard a new client. Everything got done in time and their website launched in late March. After this was done, I considered the product as “good enough” and started working on the marketing website. It took a while, but I was able to achieve my goal and launch it in June.

In preparation for the launch, I also started sending emails to my launch list. It was a nice learning experience and a first for me. I also set up an email course about building band websites.

A few weeks after the launch, Stage got posted on Product Hunt. It did quite well, and I got a bunch of traffic to its website. Unfortunately, none of this had any effect. I haven’t gotten a single signup since the launch of Stage.

I did some experiments with advertising on Facebook. That got me a few signups on the email course, but none of them converted to signups for the actual product.

If I didn’t have paying customers, I’d consider the product a total failure. For now, I’m assuming that I wasn’t able to reach the target audience with the approaches I tried. As a result, I’ll try some direct sales approaches in 2016. We’ll see how that goes…

The consulting business

As I mentioned before, the consulting business was off to a rough start this year. Luckily, my client avoided bankruptcy and was able to pay me in February. Still, it wasn’t a great experience. Amazingly enough, something similar happened a few months later. I didn’t get paid for months, because of a delayed investment. Eventually, the client got their investment and has been able to pay on time since.

During the time I was waiting to get paid, the taxes for both 2013 and 2014, as well as the tax deposits for 2015 were due. That cut a huge hole into my savings account. Luckily, I had known this day would come eventually. I had set aside enough to pay the taxes and still be able to pay my rent while waiting for my invoices to get paid.

I definitely learned two things this year:

I won’t let anyone talk their way out of an upfront deposit anymore.
I’ll always keep enough cash in the bank to pay my living for at least 6 months.

Against all odds, I hit my revenue goal for this year. I was able to make enough money to end this year with a profit.

The Podcast

I’m co-hosting a (German) podcast together with my friend Christoph Engelhardt. It’s called Nebenberuf Startup, and we’re mostly talking about building a software related product business on the side. It started in early 2014 as a result of our bi-weekly mastermind-y calls. We still joke about it being our very own group therapy session. Nonetheless, it became quite successful in 2015. We recorded our 50th episode just a few weeks back, grew an online community of more than 50 people around it, and interviewed some amazing people.

(If you’re into Year in Review posts, check out Christoph’s over here…)

Rails Girls and Rails Girls Summer of Code

Once again, I was involved in the Rails Girls Frankfurt event that took place in autumn. This time not just as a coach, but also as a part of the organizing team. The event was a success, and it was great to meet so many inspiring people.

I also joined the Rails Girls Summer of Code as a supervisor and coach again. While I’ve been a supervisor in the previous two years, this year was an even better experience. It was awesome to work with so many people on making the world a little bit better.

Conferences

I only visited one conference in 2015: MicroConf Europe. Once again, it was an amazing experience. I was stoked to meet some of my online friends, talk to inspiring people and learn a thing or two during the talks.

The personal side of things

Okay, I’ll admit it right away: I failed to accomplish my goal to refurnish the bedroom. While my girlfriend and I did some planning, we never found the time to actually pull it off.

At least we found the time to spend a beautiful weekend in Bremen, as well as some amazing 2,5 weeks in sunny Spain. It was lovely to just relax in the sun for a while.

My goals for 2016

Having goals for 2015 helped a lot to stay focused and not get distracted by too many things. It sometimes made it easier to come to a decision, because I was able to judge things about their effect on my goals.

Increase overall revenue

In 2016, want to increase my overall revenue by about 30%. In theory, I could accomplish that by just doing consulting the entire year. However, that would probably have a negative effect on my other goals.

Grow Stage to at least 1000€ MRR

As I mentioned above, Stage did not grow at all this year. Yes, I onboarded a new client and increased the MRR this way, I already had their commitment in 2014. When it comes to Stage, my primary focus for 2016 will be on growing both revenue and the number of customers.

Launch a productized consulting offering

Throughout the year, I had several discussions with fellow consultants about productized offerings. I have some ideas in mind, that I’d want to try in 2016. My goal is to have at least one productized consulting offer launched to the public and making some money.

Conclusion

As always, the year had its ups and downs. In the end, I’d consider it one of my most successful years so far. Let’s hope 2016 exceeds it!

If you made it this far, I hope you got some value out of this post. All that remains is wishing you a very Happy New Year 2016!