Moving from one to two developers on your AWS serverless project

Many aspects of serverless make it particularly appealing to solo developers building side projects: only paying for what resources are being used, generous free tier, built-in autoscaling, no server patching, etc.

I’ve seen multiple cases where a side project starts with one developer and the product grows to a point where they need help and decide to hire another developer.

This is great but there are now several new concerns:

• Can I trust new-hires with access to production resources and data?
• How do I restrict access to certain resources?
• How will we do releases? With a one-person project, often no CI/CD pipeline exists given that the developer can run everything on their own machine and there has been no need to integrate their code with others’.
• How much time will I need to spend with the new-hire helping them to set up dev environment or build out features?
• How do I ensure that nothing gets broken?

If you’re using AWS, here’s a list of things that you as the founder can do to address these concerns and “team-proof” your product:

• Use AWS Organizations to provision separate AWS accounts for dev, staging and prod environments. If your app is already live and you’re just using a single AWS account for everything, you can still do this and treat the existing account as your production account within the organization. Consider restricting access to the prod account.
• Use AWS SSO instead of IAM users to connect into your AWS accounts. This makes it easy for you to manage per-account permission sets and to revoke access.
• Set up CloudTrail trails to create an audit log of all activities performed by all human and service users within your AWS accounts.
• If you don’t have any automated tests (because up to now, you’ve had time to manually check everything), consider starting to write some tests for your app’s critical use cases. These will act as regression checks for changes made by your new-hire. Focus your efforts on writing integration/E2E tests over unit tests.
• Set up CI/CD pipelines if you haven’t already done so to automate deployments to staging and prod environments triggered by merges to the main branch. I recommend GitHub Actions as it’s easy to set up if you’re already using GitHub for version control. Ensure post-deployment integration/E2E tests are run at each stage.
• Create a minimal set of documentation describing how to set up your dev environment, an overview of the architecture and the release process. While you could handhold the developer and just talk them through these things over a Zoom call, you may need to do it again with another dev if things don’t work out, so taking a couple of hours to document everything is a good use of your time.
• Agree on a peer code review process .

Even if you’ve no immediate plans to hire a new developer for help with your side project, many of the above are worth considering right now if you have any aspirations of your product becoming a real business some day.