DEV Community: Jamal Moir

6 Takeaways From My Failed Bootstrapped SaaS Business

Jamal Moir — Fri, 22 Jan 2021 08:56:26 +0000

They (not Einstein) say that the definition of insanity is doing the same thing over and over again and expecting different results.

So, after failing to take my last bootstrapped SaaS business past the alpha stage in 2019, there are some things about my process that I have to change.

I spent some time reflecting on my last try and a few things stood out to me as fatal mistakes that doomed my business to be just another domain in my NameCheap account.

I'm going to break each one down in the hope that you will read this, and avoid the mistakes I made.

1. I Chose Technology I Wasn't Familiar With

As an engineer, I'm always looking to learn new technologies and further my knowledge in my field. It's vital to stay relevant and to stay valuable.

At the time, I was interested in Firebase and so decided that I would write my entire backend in the stack they provide. Even though it has decent documentation and isn't too complicated, it added extra friction.

This friction manifested itself in the form of burnout and without a doubt, contributed to the downfall of my first SaaS business.

Learning new technologies is great, however, bootstrapping a business isn't the time to do this.

As a solo coding founder, you will have a tonne of work on your hands, and not just coding either. Product design, UI/UX design, creating business systems, and more will all have to become a part of your day to day tasks.

Learning new technology doesn't have to be, and in most cases shouldn't be added to that list. Don't make things harder for yourself than they already are.

And if you are worried about your skills stagnating, don't. Where in a team you have other people to handle some of the issues that come up, as a solo coding founder you are going to have to learn how to handle ALL of them yourself.

Choose technologies that you are comfortable with, are productive in, and enjoy using. You'll thank yourself down the line.

2. I Didn't Have a Well-Scoped MVP

Yak-shaving, scope creep, and over-engineering, oh my!
Any professional developer will be painfully aware of the dangers of this deadly trio. That doesn't however, mean that we don't still fall into their traps.

Engineers love to engineer. We like to find clever solutions to hard problems, we like to optimise, and we like to experiment. This all leads us down a series of never-ending rabbit-holes, wasting time under the guise of "improving the product".

In a larger company, you may have the resources to get away with this. As I found out though, solo coding founders don't.

When I was coding up the MVP for my failed SaaS business, I had a loose idea, an approximate roadmap of what I wanted to build.

I didn't however, strictly define what should go in my MVP and what could come later. I didn't define the scope of the features that I did plan out either.

Because of this, I would often hear myself saying "There has to be a better way to…", "What if I…", or "I bet I could…". I would then open up a can of worms that was happy to stay shut, add in another "cool feature", or create a solution that is way too over-engineered (but it's future proof, right?).

This lead to a bloated MVP, with features in that I didn't know if people wanted or not, that got released way past its deadline.

When you are a solo coding founder, leave cans of worms tightly shut if they don't have to be opened. If you find yourself writing code and building features because "in the future, you might need to…" then stop.

If you don't need something right now, don't make it. You don't have time to build everything you need for the future of your product. Your product won't even have a future if you don't release it due to never-ending scope-creep.

Just in time development is vital when trying to bring your bootstrapped business to life as a solo coding founder.

Design your MVP, scope it, and stick to it.

Read the other key takeaways on the original post

Firestore Rules Examples – Must-Know Patterns To Secure Your Data

Jamal Moir — Sat, 12 Oct 2019 14:41:20 +0000

This post is part of a post originally posted on my blog where I write about coding, software development and developer productivity.

I've been there… You’re staring at a blank firestore.rules page, not knowing where to start. You want to make sure that your website is secure, but you’re not sure what to do and you are worried that you will do it incorrectly. But have no fear! These Firestore rules examples will give you the base that you need to safely secure your website or application.

Firestore rules are actually fairly simple and follow a logical structure. The examples below go over common situations that might arise in your app, and how to write rules to make sure that your data is safe! Learn these patterns and you will be able to whip up a secured database in no time at all.

Firestore Rules Examples

Denying All Reads
Denying All Writes
Checking if a User is Authenticated
Checking if a Document Being Accessed Belongs to the Requesting User
Checking if a Document Being Created Belongs to the Requesting User
Using Functions **
Verifying a Value’s Type **
Verifying That a Value Belongs to a List of Values **
Verifying a Values Length **
Getting a Document From Another Collection **

**You can see examples 6-10 here

Denying All Reads

Sometimes you want to store data, but you just don’t want it to be accessed.

Maybe you have sensitive data that you want to persist, but that you don’t want to be accessible via your API. Maybe you didn’t follow the advice in this article and user data is leaking out into places it shouldn’t be and you need to turn off the tap quickly.

Either way there are many legitimate reasons for denying all reads to your database, and luckily, with Firestore rules it is very easy to do.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read: if false;
    }
  }
}

Denying All Writes

Denying all writes is another thing that you might find yourself wanting to do. Maybe you have written a bunch of articles and manually added them to your Firestore database. You want to display them on your website, but want to make sure that no one can modify or delete them.

Similarly to the above denying all writes is trivial.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow write: if false;
    }
  }
}

If you want deny both reading and writing to the database, then the two can be combined like so.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

Checking if a User is Authenticated

If you don’t want to deny all read and write access to your database, and want users to be able to see, create and change things on your website or app, then you are probably going to want them to be authenticated.

The following Firestore rule example does this by checking that the request being made to your database contains a uid.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: request.auth.uid != null;
    }
  }
}

Checking if a Document Being Accessed Belongs to the Requesting User

Now, using the previous example we made sure that only authenticated users can access our data, but what about if we want to take this one step further?

Often we don’t want to just let all users access all data, but further separate it out, and only let users see their own documents.

To do this in Firestore, when creating documents you should create a userID field and store the creating user’s uid in it. Then, when trying to access that document later on, check to see if the uid in the request matches the user ID that is stored in the resource being accessed.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /petowners/{ownerId} {
      request.auth.uid == resource.data.userId;
    }
  }
}

Checking if a Document Being Created Belongs to the Requesting User

In addition to only letting users see their own data, we only want to let them write data that belongs to their account. Letting users write to other peoples accounts could get us in all sorts of trouble!

This is done in a similar fashion to the example above. The only difference is that instead of checking the resource object’s user id, we check the request.resource object’s one.

The request.resource object is the document that is being sent in the request to your database.

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /petowners/{ownerId} {
      request.auth.uid == request.resource.data.userId;
    }
  }
}

Firestore is a great database to quickly get your apps up and running. Perfect for churning out all the website and app ideas that you have (if you struggle to come up with ideas, check this post out).

But, even for small side projects, if there is ever the chance that you will get users (yourself included!), then considering security from the outset is a must.

Hopefully these Firestore rules examples have shed a bit of light on how you can secure your database too.

How to Never Run out of Coding Project Ideas

Jamal Moir — Sun, 06 Oct 2019 01:49:07 +0000

"I don't know what to make!" - Every budding developer ever

I'm sure these words have spurted out of your mouth when trying to come up with new coding project ideas at some point. Probably accompanied by "I can't come up with ideas" and "I'm not an idea person".

But let me tell you this - You are an idea person.

Everyone is an idea person, and every developer can come up with a whole boatload of coding project ideas.

The problem is, there are two types of idea people; conscious idea people and unconscious idea people, and the majority of developers, especially budding and junior developers, fall under the latter.

But it's OK! Becoming a conscious idea person - a conscious thinker is something that anyone can do.

How to come up with coding project ideas

1. Decide that you are going to be a conscious idea person

This is the most important step. Start every new endeavour with a positive affirmation - "I will become a conscious idea person".

2. Train yourself to think consciously

Train to catch yourself mid-thought and realise that the noise going on in your head, isn't actually noise, but a goldmine of budding ideas.

This is the hardest step and will probably take a bit of practice, but is well worth the effort.

While you are walking around, on the train or sitting on a park bench consciously take note of, and observe what you are thinking.

3. Notice your budding ideas

Note how I say "notice budding ideas" and not "come up with ideas". You are already coming up with them, you just aren't noticing them.

They usually come in the form of "it would be nice if...", "I wish...", "if I had ... then I could ...".

When phrases like these pop into your head, notice them! These are your possible billion dollar ideas.

4. Notice dissatisfaction

Whenever you are dissatisfied, displeased, discontent - something can be improved. And that something, could be an idea.

Consciously take note of these times and you will have more seedlings to play with.

5. Write it down!

Once you have a seedling in your grasp, a budding idea or a dissatisfaction, write it down.

I use a page in Notion to dump all of my ideas into. Even the bad ones, the boring ones, the silly ones.

The more you write down, the more potential coding project ideas you have. Even the ones that you think are no-so-great might combine or morph into something amazing.

If you forget your ideas, they are of no use to you, so write them down!

Follow these five steps and I promise that you won't struggle to come up with ideas. You might however have the opposite problem - So many ideas, that you just don't have the time to pursue them all.

Can't win them all - Sorry!

This post was originally published at my personal blog