DevOps for Early-Stage Startups


This guide is about the technical, procedural, system, and security issues around software development and deployment that you should think about as your startup gets started, especially once you have developers building & deploying code.

Target Audience

This guide is for very early-stage startups, around the time you have your initial angel or pre-seed funding, and importantly, have a few developers working and some code running.

Typical Scenarios

Most startups start with a couple of founders and an idea, then proceed to quickly build something to prove that idea, get users and feedback, get funding, and then take over the world.

Software Development

For most early-stage tech startups, software development is the core process they must master, and the sooner they get on the right road, the sooner they can quickly & consistently deliver features to their users.

Getting Started

Writing code is, in many ways, simple — get a private GitHub account, a development environment, and write code! And you should start that way, as getting going is important, but don’t forget to also chip away at other suitable best practices, outlined below.

Security, Users, and Keys

Before we get started, a quick word about users, passwords, and all that. The absolute rule, to be observed above all others, is NEVER SHARE usernames or accounts among your team. Many startups share users & passwords, including with their 3rd party developers or part-time staff, and this creates endless security risks and other nightmares later. Do not do it.

Two & Multi-Factor Authentication (2FA/MFA)

You should enable and use 2FA wherever possible, especialy for internal use and developers. This may not be available on all services and can get annoying if it’s needed 25 times per day, so you have to balance security vs. annoyance factor. But at least enable it on key infrastruture and administrative accounts, i.e. any user that can cause damage.


The first thing you need is a git repository, which today is usually done on, though some people prefer the more powerful system; they are quite similar, and both have free plans you can start with.


When and how to branch your code is often controversial, with no best way, though feature branches and merges to dev, test, and main are probably the simplest to start with.

Fall in love with README files in your Git repo — write them for key developer things, especially how to set up a new development & deployment environment for each new developer; this will save much pain later. Also create a README for the system environment variables, feature flags, and other options that are needed to run and configure it. Keeping these up to date will save a lot of time.


Broadly, your tooling is up to you and has to fit your technology stack, comfort level, and where or how you will be deploying (more on that below). But to get started, start with the tooling you know such as a development environment, possibly a build environment like Jenkins or other CI/CD, Docker if you’ll be using it (you probably should), and so on. More on this, below.


It is very important to be deploying your application to a cloud environment as early as possible, ideally right from day one. Do not just test or look at the system on developers’ laptops, as this will hide all sorts of problems that will slow you down later, especially as the team grows and others need to see or test the system.


Everyone uses Slack, often for everything. In concert with email and perhaps a few other whiteboard or documentation systems, it’s often the core day-to-day communication channel. This is especially true for today’s remote workforces, as Slack becomes the common water cooler for everyone.


Decide early on where you want to main developer and system documentation. This can vary a lot, from markdown files in the repo to Google Docs to Wiki systems like — ideally you can stick to one place and format for docs, though these tend to vary over time — the most important thing is to get used to writing things down, tracking the system physical and logical architecture, how things work, a team directory, build and deployment process, etc.

YAGNI — You Aren’t Going to Need It

You should start doing lots of best practices and building up things as you go, as outlined below, BUT you should not overbuild or get stuff you don’t need. Known as YAGNI, or you aren’t going to need it, it’s the sin of overbuilding infrastructure, over-designed features that are ways out in the future, etc. Don’t over-build, and don’t over-engineer.


It’s critical that you set up and own all your own SaaS and service subscriptions, especially for anything software development, code, and cloud-related things. It’s very easy for your part-time or 3rd party developers or others to do this for you, in their own accounts to just get going, but that’s a very bad idea, as they can withhold access, etc. if there is a payment or other type of dispute. Do not let others own anything or you’ll likely regret it. No personal services, period.


Software and system architecture is highly variable, depending greatly on the problem being solved, where the system will be deployed, the scale of the system, the experience of the team, and the technology stack involved.

Programming Languages

Choosing a programming language is often a religious war, but generally, you should choose from a very small list of the most common languages and environments. Using a popular language will make it much, much easier to hire, find tools, use 3rd parties and 3rd party libraries, etc.

Esoteric Services

Avoid fancy new or esoteric services like the plague. This includes the latest databases and other systems that are on the bleeding, or even leading, edge, unless they add some very unique value to your solution (unlikely).


Avoid microservices in early-stage systems, as they are not worth it. They greatly complicate development, destiny, deployment, and troubleshooting are not something you should generally mess with.

Never Build What You Can Buy

You should also not build what you can buy, especially in these days of plentiful SaaS and other services that are everywhere, often for free or at low cost. Almost everything we used to have to build is now at your fingertips. And you can always build your own later when your scale or needs exceed what’s easily buyable (by which time you’ll have more resources to build it).

Off-Shoring Development

Many startups outsource some or even all of their early-stage development, and many push this offshore to save money. This is fine, but there are some additional considerations when using outside development companies.

Code Ownership & Control

A critical element of any 3rd party contract and arrangement involving software is who owns the code and who controls access to it. Most contracts are pretty good at who owns it, but be sure you own it for real, and the 3rd party or offshoring company has no rights to it, now or ever (i.e. they can’t use it in other projects, etc.)


As mentioned above, to get started, just get started with a development environment and private code repository, e.g. GitHub and a development environment and basic tools (like Gradle, Maven, webpack, etc.) and go from there.

Development Processes

Different companies will use different processes to build software, based on the founders’ experience, but all will generally be so-called Agile processes. This means rapid and flexible software development and very frequent deployment, with very short development cycles, from hours to days, so new code is designed, built, and deployed much more rapidly than in traditional processes.

Development Tracking

It’s important to track and manage your development work, even for a single developer. Plus, you’ll find it much easier to expand your team and scale if you start off with a good system. By far the most common is the Jira system, which creates simple issues or tickets for everything you want to do: features, bugs, enhancements, etc. and gives them a priority, owner, assignments, etc. Other popular systems inclue Trello, Asana, and Pivotal. You can also use GitHub Issues for basic bug and issue tracking.

CI/CD Systems

The CI/CD (Continuous Integration / Continuous Delivery-Deployment) concept means different things to different people, and can be used in different ways. As a startup, you want to focus on a few core tasks you need to be done — the goal is a simple one-click centralized build and deployment system — this will greatly speed development, adding developers, plus it forces all sorts of best practices along the way.

CI — Continuous Integration

CI systems continually merge in, build, and ideally test your code as it’s committed to your repositories. This forces developers to deal with conflicts, failures, and problems on a near real-time basis, while things are fresh in their minds, with the goal to ensure the code is always as clean, stable, and functional as it can be.

Code Checking

More advanced CI systems will run a number of code-checking tools to help check for common mistakes, security issues, formatting problems, etc. All this varies highly by language and technology stack, but it’s good to start introducing the basics as soon as you can. It’s especially important to scan the code for hard-code security credentials and keys, which should NEVER, EVER be in the code, configuration, or any checked-in file.

Supply Chain Checking

Supply Chain Security is an important new and developing area that you’ll see mentioned. This is making sure the myriad of 3rd party libraries and code you use in your software is safe, secure, and up to date. Over time, this becomes very important.

Code Testing

Developers should include unit and other tests in their code, and ideally there are also higher-level feature, white/black-box and other testing, too. The CI system normally runs as many of these tests as is practical (at least all the unit tests), though this is a complex area — you should at least set it up to run the unit tests on every commit or merge.

CD — Continuous Delivery-Deployment

The second part of CI/CD is the delivery or deployment phase, usually bundled in the same CI/CD tool, and focused on deploying the built and tested the application to its environments, such as for dev, testing, or eventually, production.

Developer Data & 3rd Party API Services

Modern applications rarely stand alone, instead depending at least on a database or two (and their data), and often many 3rd party services (APIs) as part of best practices. However, this greatly complicates the developer experience, as they often need most, if not all, of these services available to build and test their code each day.

Local Services & Data

Developers often run a small number of local services, such as databases, and usually in Docker Containers. The availability of containers on the laptop (and plenty of RAM) has greatly simplified this process and is popular for running things like MySQL, ElasticSearch, and many other 3rd party products.

Shared Services

More complex systems often need bigger services that are hard or impractical to have on every developer’s laptop. In this case, teams will usually deploy shared databases, etc. to a private development environment that developers can reach via VPNs, ssh tunnels, or great networking tools such as Tailscale. A development environment is usually provisioned for this, so the developers and the deployed development stage code share the same data.

Testing & QA

You need to test your software, or your users will be testing it for you. The challenge for early-stage startups is good testing resources are expensive, and automated testing is complex and expensive.

Infrastructure & Deployment

Once you have some working code and an application to deploy, you need some place to actually run it, usually on cloud infrastructures such as AWS, Azure, or Google GCP.

Getting Started

Start with a set of cloud accounts that you own (not your 3rd party developers, nor employees). The exact structure will vary by cloud, but one account is probably good to start, with provisions for at least three or our completely separate environments: dev, test, and production, plus maybe staging later.

Infrastructure as Code

Modern infrastructure is managed as code, using the IaC model, or infrastructure-as-code, usually using either a cloud’s native system, e.g. Cloud Formation on AWS, or an industry-standard cross-cloud tool like the ever-popular Terraform from Hashicorp.

Secrets Management

Managing secrets in cloud environments can be quite challenging. It’s very important to get this right or at least well-secured, or else hackers or others can easily compromise, or even destroy your entire system. Note that secrets include all users, passwords, keys, authentication data, and most critical configuration data such as host names, IP addresses, database names, etc. If you don’t want it broadcast on the Internet, it’s a secret.


You will undoubtedly be pushed to use Docker containers and Kubernetes very early on. This may or may not make sense, depending on your team’s experience level and the size or complexity of what you are building.

Monitoring, Logs, Tracing

Once your system is deployed and has any users, you’ll need to monitor and manage it. Monitoring means many things to many people, but you should strive for basic Monitoring, Log collection, and ideally some distributed tracing (usually much harder to do and often not needed).


Monitoring can get overly complex and unwieldy as folks like to monitor everything. Start by keeping it simple, and focused on key metrics that impact your users or the system. Basic monitoring services will automaticaly pick up stuff like out of memory or diskspace, etc. and you should add a 3rd party service to monitor your public web app and APIs, as that’s what the users are looking at, and you need to know if they are down or broken.


Work hard to get logs from your applications into a centralized collection system, as this will help developers and operations teams really understand and troubleshoot what is doing on, especially in production when unexpected things happen. This is really important for production troubleshooting.


More advanced than monitoring or logging, tracing, or what is now called Observability, is about knowing what’s going on inside your application. This is especially useful when there are many services or other moving parts, which make it very hard to know where and why something failed.

APM, JS Errors & RUM

While monitoring and logging are important for your backend services, today’s modern applications tend to have very complex front-end systems, usually based on Javascript. Since this code actually runs on the users’ laptops or phones, it’s very hard to get good error reporting or troubleshooting info.

Company IT Infrastructure

Aside from your core technology, you also need to think about your general IT and things like email, websites, and especially DNS, as the latter directly intersects with your core systems.

DNS / Domains

You can register your domain anywhere, though GoDaddy seems the most popular these days and is well-known. Note that some domain endings, such as “.io” have separate registrars you have to use.

Google Suite / Workspaces

Many companies use the Google workspace system, as it’s flexible, inexpensive, and familiar. You can manage your documents, email, groups, calendar, and nearly everything else there via their web interface. It’s a very easy place to start and get going quickly, usually within an hour.

Email Users & Groups

When setting up new emails for employees, use a standard format for simplicity, which also makes it much easier later to share documents, to know what email goes to who, etc.

Company Culture

There are many books and blogs on general company culture, but fewer on technical, security, and development culture. Even those are generally focused on hiring, engineering management, motivating the team, etc.


Instill a security culture right from the beginning, and from the top down. This means everyone, from CEO to office cleaning staff adheres to basic principles, where any significant violation gets an audience with the CEO.

Users & Passwords

This means having clear separate users, passwords, keys, etc. for every user and not sharing. It also means NEVER sharing users and passwords in emails or other persistent message channels, and even then, separating user and password in separate channgels (e.g. send username in email and password via SMS). Even better is a central password system like 1Password

Laptop Security

As a startup, you usually won’t be able to use expensive enterprise-level network, computer, and phone management tools, so the best you can do is follow best practices, build a security culture, and generally remind folks of key points.

Data Security

Your data, especially information you have on your customers or users, should be protected at all times. Don’t let employees just send it around in any format or treat it carelessly. Obviously, you have to balance this with convenience and getting work done, but build a culture of data protection from the beginning.

Do Things Right

Startups are masters of shortcuts and doing things as quickly, cheaply, and effectively as possible. That’s fine, but there is also a balance of doing things right, or at least realizing and recognizing that something is a shortcut or likely to be problems later.

Code Quality

Part of doing things right means writing good code. This can be hard under time pressure, but is very important and often saves a lot of time in the end. Ensure your teams create well-structured, well-documented, logical, and easy-to-follow code from day one, as this will really help all who join later, and greatly speed future development.


Create a culture of good documentation right from the beginning. This is hard, and there is a balance of good and useful vs. dumb and wasteful, but try to get basic docs like design, code, and diagrams right from the beginning.


This guide has covered the technical, procedural, system, cultural and security issues around software development and deployment that you should think about as your startup gets started, especially once you have developers building & deploying code.


Below is a basic checklist of key things small startups should think about and implement for baseline technology development and system management:

  1. Own your source code repository, on GitHub or GitLab
  2. Own all your accounts on all services, clouds, tools, etc.
  3. Limit 3rd party (outsource) access to systems
  4. Separate users in every system for every user
  5. Separate users in every system for services
  6. Build separate development and testing environments that closely match production
  7. Use an automated CI/CD system, including tests
  8. Use Infrastructure as Code to manage your cloud environments
  9. Manage secrets carefully in development and deployment
  10. Include security everywhere
  11. Use monitoring and logging everywhere, including JS error tools
  12. Document all the time
  13. Build at least basic QA from the beginning
  14. Don’t build what you don’t need
  15. Always buy when you can (vs. building)
  16. Use the simplest architecture you can (KISS)
  17. Use very mainstream programming languages and tools
  18. Avoid esoteric services and the latest tools
  19. Avoid Kubernetes unless you really need it, then let others manage it
  20. Use a ticket/issue tracking system for all development work
  21. Never share passwords in email or other persistent messages
  22. Set up and use Google Workspaces for basic docs and email
  23. Setup good DNS and eventually move it to a cloud
  24. Build key security, quality, and documentation into the culture



CEO of ChinaNetCloud & — Global Entrepreneur in Shanghai & Silicon Valley

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Steve Mushero

Steve Mushero

CEO of ChinaNetCloud & — Global Entrepreneur in Shanghai & Silicon Valley