Full-stack developer building SaaS businesses
with Golang, Node.js and React.

Launching Quickly: Applying Lessons

I have now been reading startup related books for quite a while, even smaller books about ideation, launching quickly, launching now, this blog post is about applying those lessons, this weekend! Enough putting off, enough being part of the 98% that says tomorrow or not now or not for me.

Book I read related to this:

Even to some extent:

So here I am, jamming on Daft Punk, in a café, just started the Bulletproof Diet, just landed in Krakow, Poland, just came back from vacation, had an idea before bed yesterday and am building it now! Don’t ask me why it took so long, the important thing is I am taking action now.


I wanted a simple thing to build, and ideally solving some problem I had. That’s when I thought about my recent experience trying out at least 4-5 SaaS application aimed at helping freelancers manage projects, invoice their clients and track their time. My main gripe with most of them was that they all did really well at least one of there things but almost always had poor support for receiving payments from clients (Xero was really good but a bit to big for me at this point). But because they almost all adopt the do-it-all strategy they often have less that well done features in areas that are still important to running your business.

So, I am building an application with two business goals in mind: First, gather payments from clients really well whichever gateway you use. Second, to integrate with you other software that you might be using for invoicing to sync clients and paid/unpaid status.


My Goal #1 is to solve my own problem of taking payments with something else than PayPal in Freckle.

My Goal #2 is to monetize (read market and get users) this product to a 1000$ MRR (Monthly Recurring Revenue) to help attenuate the consulting ups and downs.


Step 1: Defining launch date

Too many times I read about people afraid of launching, worrying they don’t have enough, they need X and Y feature more. Also:

If you are not embarrassed by the first version of your product, you’ve launched too late.

- Reid Hoffman

So, I will launch, whatever I have at that time, on Friday the 14th of August giving me 7 days.

Step 2: Defining core a core feature set

The core feature set should aim to solve one use case, mine, like DHH often stated, he built Ruby on Rails for his use case but is happy to put it on the open for people to adapt it to their needs. Focusing on this not only makes sure one group of clients is satisfied but also make you launch way sooner, obviously.

So, I want the product to have:

Step 3: Building

… goes to work … (continued in following posts)