Andy Van Slaars

Andy Van Slaars

moon indicating dark mode
sun indicating light mode

Defining a my “default” tech stack

I’ve been thinking a lot lately about building out some side projects. It’s been a while since I built anything substantial outside of a work environment, where certain decisions have already been made and there are constraints in place.

Without those constraints (and with some new ones, like a miniscule budget 😅), as an independent developer trying to build something, what would be the default tool set I’d ultimately enjoy working with and be best served by. I’ll be collecting my thoughts on that here.

I’m a big proponent of being pragmatic and using the right tool for the job, but I still think a default starting point helps take some of the decision making process out of the standard needs for projects. From there, if there is a reason to deviate from a standard choice, it’ll be an informed decision based on the potential trade-offs weighed against the pre-defined default.

Design and prototyping

Figma stands out for it’s power, speed and the fact that it runs in a browser. It’s great for sharing and for collaboration.

Front end

The front end landscape offers no shortage of options. This is really where my desire to define (at least loosely) a “default” set of tools came from.

Language and Framework

These are kind of big ones to get out there right away. I’m a huge fan of JavaScript, but I’m growing more and more fond of the benefits of TypeScript. Its type safety brings me back to my C# days without taking me out of the JS runtime.

My go-to front-end framework is, and will continue to be React. I am more than happy to learn other frameworks, but as a default tool, I’m going to go with the one I know best.

Build tools

Building the front end has grown more involved over the years. As much as I enjoy (occasionally) getting my hands dirty and hand-rolling all the webpack and Babel config for a project, if I’m going for speed and the ability to focus on building things, I want something that’s ready to go out of the box.

For libraries

I’d grab tsdx before trying to get all the configuration right. I’ve done it, and it can be painful when you’re trying to optimize the output, account for tree-shaking, shipping types and bundling in multiple formats. tsdx does all of that for you out of the box and it’s all wrapped up a neat little npm package.

For apps

There was a time where I would have just used create-react-app. It’s a great tool, but lately, I’ve been thinking more and more about Gatsby as the starting point for building apps. In situations where you can benefit from the SSR functionality Gatsby offers, it’s all built in. For places where that’s not as much of a concern, you still have a solid build setup ready to go with no need to configure it yourself. Of course, if you need to configure something to enable some non-standard functionality, the ability is there. The plugin and theming capabilities offer a ton of power and flexibility too.


I’m a huge fan of Jest and testing library for unit testing and Cypress for integration testing.


Recently, I’ve fallen in love with the workflow enabled by Tailwind. Coupled with React’s component model, it allows you to iterate quickly and encapsulate groupings of utility classes into components for reuse.

Back end

I know there are a ton of choices in terms of languages and technologies available, but I’m inclined to lean toward leveraging AWS for most of my backend needs. It’s basically a one-stop shop for auth, DB, storage, CDN, FaaS, DNS, etc. That being said, I’m not as well-versed on the AWS ecosystem as I’d like to be (yet), so I could be swayed to other providers for certain things. For instance, I am hosting this site on Netlify and they offer some of this functionality (essentially abstracting AWS, but still) and I’d be more than willing to forego the direct AWS interactions if the Netlify abstraction met my needs. For a more all-in approach, I’d still look to tools like Amplify to abstract some of the configuration pain from me.