The SaaS Chronicles. Issue #1.

Come along with me as I build a SaaS product and turn it into a (hopefully) successful business.

In early March 2019, I decided I wanted to make a SaaS product. I had an idea that I hadn’t seen anyone else tackle yet that has some utility for an audience I was familiar with: my fellow web designers and developers. Plus, it solved a problem I ran into myself when designing my own site.

My product is called KolorKit. It’s a color palette design and organization tool, basically taking Adobe Color and re-organizing it so that it’s actually useful for creating production color palettes. KolorKit is still in an MVP prototype stage, but you can check it out at app.kolorkit.co if you’d like to get an idea of what I’m describing.

This is what KolorKit looks like today, v0.2. Still pretty bare-bones MVP.

I thought it would be an interesting idea to start documenting the process of developing a SaaS product, from the early beginnings to a (hopefully) profitable future business. I hope to put these out on a roughly bi-weekly schedule, and they’ll:

• Document my progress and the challenges I’m working on (technical and otherwise).

• Outline a rough blueprint for people looking to develop their own SaaS product, by documenting the many decisions I’ll have to make while building KolorKit.

• Provide information that I wish I had while developing my SaaS product.

• Share additional insights learned along the way.

• And maybe gain a little exposure for my app too.

I’m inspired by the trend of people/organizations doing behind-the-scenes type content. Particularly, I’m loving the Corridor Crew YouTube channel (a hybrid BTS, personality, and games/challenges channel that gives you a view into what it’s like running a digital media studio and the fun personalities of all the employees and their friends). The SaaS Chronicles is my attempt to create something similar, but for a nascent tech company.

So if you’re interested in building a SaaS start-up, this series will hopefully provide a lot of useful information and third-hand experience for you. And if you’re just curious what it takes to build a SaaS product, then hopefully my story will be interesting enough to keep your attention.

The challenges in starting from scratch

Starting from scratch. Photo by Émile Perron on Unsplash

Now that I’d been working at a company with an established codebase for well over a year, I’d forgotten what it was like to start from scratch. I started by building a front-end prototype version of the app, and it probably took me several weeks just to finish the first “story” on my kanban board due to all the low-level scaffolding that I hadn’t done in a long time.

However, Once I got a little bit of architecture under my feet, progress came quickly. It was easy to get into the zone and finish stories, aside from the moments where I encountered a weird bug. During this phase, I even learned a new piece of tech — Vuex — which turned out to be easier than I expected.

Lesson #1: Use tech you know. There will be many hurdles in the early development stages, and this will make the speed-bumps much smoother.

Progress was quick, because I’m building KolorKit on a Laravel back-end with a Vue.js front-end, both technologies that I know very well. I also avoided making the app a single-page-app (or SPA as all the ‘kool kids’ call it), even though SPAs are the new hotness, because I’m not well-versed in SPAs and trying to figure out how those worked on top of building an app would’ve drowned me in the details.

Lesson #2: Give yourself some kind of map to follow while making your very first v0.1 prototype.

Mapping out my data structure on a whiteboard. Took me maybe 30 minutes but has probably saved me dozens of hours. Some stuff blurred (features I’m not ready to talk about yet).

I started out by creating a basic white-board diagram that mapped out the data structures of the parts that make up my application. This created a natural map and showed me most of what I needed to do to build my MVP. 20–30% of my early stories were still unanticipated, but that’s exponentially better than even 40–50%. The more uncertainty in the early stages, the more friction.

But front-end development is my professional realm and my comfort zone. Once the prototype was done, things became significantly harder.

It was time to face a former nemesis. An as-of-then unconquered beast that is the bane of all web developers. I’m talking, of course, about authentication.

Why is authentication so hard?

That was the question on my mind 24/7 for the first week after I finished my prototype while I researched (read: procrastinated) options for adding the all-important authentication to my app. SaaS apps need a way to store and authenticate users, of course, but this step felt surprisingly hard, perhaps because there’re so many options available.

I spent weeks considering the many ins-and-outs of authentication and multiple options for implementing it, when in reality all I needed was to make sure my users could log in. In the end, I picked the simple (and quick) option which is what I should’ve been looking for in the first place.

In hindsight, implementing authentication wasn’t so bad. But because this was the first time I’d implemented authentication in a production application, I agonized over the decision for far too long and wasted many more hours researching than I needed to.

Lesson #3: For anything that’s ancillary to your application, look for the quick and easy way to do it, not the perfect way.

If you’re like me, the temptation to try to be perfect is almost irresistible, but the truth is that I enjoyed working on my application much more than finding an authentication solution, and even if you end up paying for a service to do some ancillary thing that you could’ve written yourself, the time saved is more than worth the cost. And you’ll appreciate spending more time on your app which will reduce friction and make it easier to keep the momentum going.

Ultimately I landed on using Auth0 as my authentication provider. This meant I could outsource the nuts and bolts of authenticating users to an outside service (and thereby also improve the security of my app, since those guys know what they’re doing more than I do).

But authentication doesn’t live in a vacuum. You need to also store your users and information about them.

Creating the sign up flow: keep it simple.

Lesson #4: I would strongly recommend you keep your app’s connections to its services as one-dimensional as possible.

I needed a way to collect more information about a user when they signed up without doing it in Auth0. It’s technically possible to do this in Auth0, but I chose to keep Auth0 to just authentication in order to decrease overall coupling between it and my application. This makes it easier to swap out Auth0 for another solution in the future if I ever felt that I needed to.

My final solution was to simply create middleware that would determine if I had all the information on the user that I wanted (name and occupation in my case), and if the user didn’t have those items filled out, I could deduce that they had just signed up, so I’d redirect them to a page with a quick form for said information. Once they filled out that form and submitted it, they’d be able to access the app again. This works well, I think, and I’m happy with how it turned out. All told, it took a few weeks to get the signup form page and a (very) basic account dashboard page built out and properly integrated into the signup/login flow.

This is a diagram of how the sign up/log in flow works in KolorKit.

This is where we are: v0.2.0 (live as of 5/27/19)

And this is where the app stands right now if you visit it. This is v0.2.0, and the total feature-set I’ve built thus far is as follows (so you can get an idea of how much work has gone into this):

• You can create/edit/delete individually-named color-sets in your theme.

• You can edit the colors in said color-sets, using either hex, RGB, or HSB values to manipulate the colors. Those values all sync with each other, so if you change the hex, it changes the RGB and HSB values as well and so on.

• Color-sets collapse if you’re not editing them so that you can see more on screen at once.

• You can sign up for an account and login via Auth0.

• When you sign up for an account, you’re first redirected to a page to complete sign up before you can access the app again.

• You can view your account dashboard, which for now just shows your email, provides a button to reset your password (the actual logic is also handled by Auth0), and provides a link to logout.

In fact, just listing all that out reminded me of just how much work I’ve done so far and how far I’ve come as a developer since I first started and wouldn’t have had half a clue how to do all the stuff I’ve done for KolorKit.

I’m about two and a half months into this project so far, and it’s been an enjoyable, if at times frustrating, ride. I’ve recently been grappling with a new problem of how to get my users’ accounts synced up with contact records in a CRM (specifically Keap (formerly Infusionsoft), since I work there and have a free account). I’ve tried to figure out a solution for well over two weeks and all I’ve gotten is frustration. But I’ll save that topic for another entry of The SaaS Chronicles, probably once I figure out a solution so I can give you that instead of just venting.

What’s coming up next

Right now, I’m working on defining what v1.0 of KolorKit will look like and trying to plot the course from where I am today to v1.0. I’ll tackle this subject of deciding what features need to be in v1.0 (including architecture and support features that you don’t immediately think about like billing) and the intricacies of planning in the next chapter of The SaaS Chronicles.

If you found this an interesting read and/or interesting concept for a blog series, leave me a note in the comments on what kinds of topics you’d be interested in reading about when it comes to creating a SaaS product.

Till next time.