← All posts

Building apps faster

Know what to build

A lot of times I’ll find myself so excited by an idea I'll start building it ASAP, just to be stuck 2 days later on something I didn't thought about.

Map out your MVP, draw a few mockups, think about the features you'll implement and how they’ll be implemented.

Resist the urge to build it right away and force yourself to cool down and put some thinking into it. Once you're ready, go -

Tech stack ADHD

Much overlooked: use the technology you already master. Not jumping in there with the latest new stuff trending on HN / Github.

Our thinking is flawed (cognitive biases) and we overlook the negative aspects until we actually run into them.

Learnt this the hard way a few times over. Every time I think it’ll be fine after reading a few posts praising the pros, every time I’m wrong. Classic survivorship bias.

A good example is the serverless module, back when it was the new thing to try. It was still very early but I didn't care. I'd host it on Lambda so it's cheap and use some DB that appears to look like Mongo, DynamoDB.

I started working on a new project (ElioPay) with it but after 2 weeks had to go reverse gear to keep my sanity. I spent time debugging like hell, but as it was relatively new tech, the internet wasn't full of explanations and blog posts on the issues I encountered.

The amount of time I lost figuring out ways around constraints imposed by serverless (which I absolutely didn’t anticipate) and the amount of time it took me to figure out how to use well DynamoDB was not worth it, in what I was trying to achieve wasn't learning a new tool or having a stack ready for millions of users.

So if your goal is to ship fast, go with mature tech. It doesn't mean you shouldn't try new stuff! It's fun to experiment. And of course you need experimentation to learn.

Just be clear on what you want, is it learning a new tech, or building something fast?

For me, after experimenting a lot, I mostly come back to:

  • Node (Express), Mongo, Passport for auth(for users)
  • Stripe for payments
  • Hand made CSS (with a lot shared between pages) for landing pages
  • HTML/ejs + JQuery for early prototypes, then React for clean dashboards

It might not be the absolutely most performant for 2020 but it's reliable, wildly battle-tested and the ecosystem is huge.

It took a time to decide myself on my current stack after experimentation with Rails, PHP and Django on some projects and at the end I’m sure all of those would have yielded similar results.

A great example of not giving a fuck about the stack is Pieter Levels. His entire suit of products (notably Nomadlist) runs on a PHP, SQLite and JQuery stack and makes as of this writing ~300k$ ARR while handling millions of visits on a website faster than most React apps today. All running on single monolithic instance.

Split into blocks

If you create a lot of similar projects, you can strive to re-use at a maximum code between them.

Recently I started splitting recurring parts of my projects into components (Node modules):

  • I have a module that handles authentification and account management through passport
  • One that handles billing with Stripe, managing user subscriptions, adding/removing cards, upgrading plans, etc... (update: stripe announced their billing portal so I might switch to that)
  • One that gives an overview on my users and how they're using the app.
  • One that generates a minimalist documentation from Markdown files
  • And one that generate nice error pages.

As of right now I use them in 6 different projects. For now they're pretty basic feature-wise but as I'll improve them, they'll be available on all the products as simply as updating the dependencies.

These modules make sense only because I know I'll use the same functionalities in later projects.

Focus on the important and reduce the scope

Rationally prioritising is hard.

Not losing time on useless/not-that-useful things. Legal notices and privacy policy don't matter if no-one is using your site. You'll add them later and re-use them as much as possible.

Laziness stirs us toward the easiest task and make us lie to ourselves to think they advance us.

Make sure to set boundaries to your MVP and stick close to them.

Be careful not to look too often at the big picture (the masterplan) as you'll get discouraged by looking at the mountain. Open a notepad and write the steps to get to your goal. Then split that into small, actionable, scoped tasks and see if they are all really required.

Focus on tasks that bring you closer to your desired outcome (most often validating the idea asap) and throw the rest.

That doesn't mean you shouldn't adapt to feedback and learnings on the way of course.

Thanks for reading!

Subscribe to get future posts. No spam ever.

twitter - github