Being the only developer at my company

I’m a developer at OOGT, a creative studio from The Netherlands.

Since the start of May I’m the sole developer at OOGT. Starting something from the ground up is really, really cool. But it also comes with some choices. In this article I’ll briefly go over these choices and why I made them.

Managing the work 📆

Because there was no ‘tech team’ yet at OOGT, there was no workflow yet for technical projects/tasks. I introduced a system that I’ve gotten familiar with at previous companies. Basically, it’s a kanban/scrum variant where we define these 8 phases:

• To refine. Work that needs to be ‘broken down’. It’s given an estimation in hours during a refinement meeting.
• Ready. Work that is estimated and ready to be picked up.
• To do. Work that is planned for the current week.
• In progress. Work that is actively being worked on.
• Review. Work that should be reviewed by someone else of the OOGT team (or the whole team during lunch).
• Acceptance. Work that is ready to be accepted by the client (on a staging/testing environment).
• Release. Work that is accepted but needs to be released (to a production environment).
• Done. 🎉

We use Asana to manage the work in these phases. Because we want to be as transparent as possible, we also provide our clients with access to Asana.

Choosing a tech stack 💻

The biggest/most impactful choice I had to make was which tech stack to use. I went for a React front-end in combination with Next.js to support server side rendering. The application is being deployed to Now. I also deployed it to Amazon Lambda, but because Now has a nifty now dev command you can use locally I went with that. I also really like the ease of use for aliasing a Now deployment to a live url.

Our apps use Jest for JS tests, which run in Travis automatically when a push has been done to a Git branch or a PR has been merged to ‘master’. Also, a deployment to Now is done automatically. It has a target of ‘staging’ by default, except for when the (merge) commit is done to the ‘master’ branch. In that case, it’s automatically deployed with a target of ‘production’. This means it also updates the alias of the production url to the latest build/deployment.

Lastly, our components are being developed using Storybook before they are being used in an app. To host these Storybook builds, these builds get pushed to an AWS S3 bucket which is enabled for static hosting.

We use Amazon’s Route53 to manage domains, routes and DNS records.

In case you have any questions about setting up this Travis, Storybook or Next/Now environment, feel free to comment and I’ll gladly add some Github gists to show the configuration we use.

Choosing a CMS. Spoiler: it’s Wordpress. ✍️

Because we work with clients that would like to have access to the content and the ability to edit some of this content, I had to pick a CMS that ticked a few boxes:

• Can be used in a headless way (I like my frontend and backend to be completely separated)
• Supports multilingual setups
• Is relatively cheap
• Is easy to setup

I went over a couple of options, being Strapi, Contentful, Graph CMS and good ‘old’ Wordpress. Even though I really liked Contentful and Graph CMS because they are managed solutions and look very promising/futureproof, I still went with Wordpress. Main reason is that it’s cheap, and because it supports the concept of pages out-of-the-box. Setting it up is only a few clicks of work using Amazon Lightsail. To support HTTPS traffic you need to setup a Load Balancer (in Lightsail) as well and attach it to the instance running Wordpress.

To use Wordpress in a headless way, the REST API is a start. I also installed these plugins at one of our first projects:

• Advanced Custom Fields to create custom fields that our frontend ‘knows’
• ACF to REST API to include these Advanced Custom Fields in the API response
• WP Multilang, a free multilingual plugin (alternative for WPML) which is compatible with the REST API out-of-the-box
• Yoast SEO to make metatags manageable
• WP REST API Yoast SEO to include Yoast SEO data in the REST API response
• WP-REST-API V2 Menus to make menus manageable/translateable and expose these through a menu endpoints

As you can see there’s a bunch of plugins needed to create a workable situation. However, these plugins are free and require minimal configuration.

I did find Strapi to be very promising, but before using it in production for one of our clients I want to wait until it’s out of beta.

If you have any questions or tips regarding using a CMS in a headless way, then please let me know in the comments 🙏 *Yes, you can also use the comments to bash on Wordpress and how it’s not an elegant solution but still used by millions of users and thousands of companies

Advantages of being the only developer 👍

It’s a relief to be able to choose your own tech stack. When choosing techniques to use I find the following to be important:

• It should have decent documentation. I don’t plan on digging my way through third-party source code any time soon 🤷‍♂
• It should be used/maintained actively
• It should be relatively easy to (de)-couple it into our application

Being the only developer I can make sure these requirements are met.

Disadvantages of being the only developer 👎

This is an obvious one; tunnel vision. Every now and then it’s nice to discuss challenges and choices with a peer or to get feedback on your code. Fortunately, I know that our ambition is to grow the team as soon as our funds and incoming work allow us to.

Are you also the only developer at your company? Do you have any questions or tips for me? Leave a comment and I’ll get back at you asap.