When Two People Run the Whole Show: A Simple Pipeline That Actually Works

You are one of two people building a digital product. Maybe it is a simple inventory management web app, or an API service for business partners. Your team is small, your budget is tight, and your goal is to have something usable in weeks, not months. At this point, the first question is not about pipelines or CI/CD. It is: "When people start using this app, how do I send them a new version without logging into the server every single time?"

In a small startup, manual processes feel natural. You SCP a file to the server, SSH in to restart the service, or copy-paste a database query. It works for the first few releases. But after three or four times, you start noticing the cracks. You forget a step. You copy the wrong file. You skip a migration. And if you have more than one environment--say, staging for testing and production for real users--you have to remember the exact sequence for each one, hoping nothing slips through.

This is where a simple pipeline enters the picture. Not as a grand project, but as a tool that runs the same steps every time your code changes. You start with one configuration file in your repository that defines three steps: build, test, and deploy. Build turns your code into an artifact that can run. Test runs automated checks--for example, whether a new feature breaks an old one. Deploy sends the artifact to the target server.

What a Simple Pipeline Looks Like

For a small startup, the tool does not need to be complicated. GitHub Actions, GitLab CI, or the built-in CI from your cloud provider are all fine. What matters is that the pipeline runs automatically when you push to a specific branch. For example, pushing to main triggers build, test, and deploy to staging. If everything passes, you deploy to production with one click or one command.

Here is a concrete example. Imagine you have a Node.js web app hosted on a small VPS. Your pipeline file might look like this:

Here is a visual overview of the pipeline:

Here is what that pipeline configuration looks like in practice:

name: Simple Pipeline

on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build

  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm test

  deploy-staging:
    needs: test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm install
      - run: npm run build
      - run: |
          rsync -avz --delete dist/ user@staging-server:/var/www/app/
          ssh user@staging-server 'systemctl restart myapp'
flowchart TD A[Push to main] --> B[Build: create artifact] B --> C[Test: run automated checks] C --> D{All tests pass?} D -- Yes --> E[Deploy to staging] D -- No --> F[Fix code and push again] F --> A E --> G[Manual trigger for production] G --> H[Deploy to production]
  • On push to main: install dependencies, run tests, build the app, copy the build artifact to the staging server, restart the service.
  • On manual trigger or tag: repeat the same steps but deploy to production instead.

That is it. No Kubernetes, no container orchestration, no multi-stage approval gates. Just three steps that run consistently every time.

Full Ownership Means You Own the Pain

Full ownership means you and your teammate hold complete responsibility for this pipeline. There is no separate DevOps team. No long approval process. You write the pipeline, you run it, and you fix it when it breaks. That sounds like a lot of pressure, but it is actually an advantage. You know exactly how your application gets delivered. You know what can go wrong. And you know how to fix it because you built it yourself.

When something fails--and it will fail--you do not wait for another team to respond. You look at the logs, identify the step that broke, and fix it. This hands-on experience is invaluable. It teaches you the fundamentals of delivery in a way that no book or course can replicate.

Basic Observability Without the Dashboard Obsession

You need to know whether your pipeline succeeded or failed, and if it failed, at which step. Most pipeline tools already provide logs and notifications. That is enough for now. You do not need a full observability stack with dashboards, alerts, and distributed tracing.

Add one or two simple metrics to your application itself. Track the number of incoming requests, the error rate, and the average response time. These three numbers tell you whether a new version is running normally after deployment. If the error rate spikes or response time jumps, you know something is wrong. You can check the pipeline logs to see what changed, and roll back if needed.

The One Thing Small Teams Forget

Documentation. Not the long, detailed kind that nobody reads. Just a short note about how the pipeline works, what to do when it fails, and how to roll back to a previous version. Write it down while it is still fresh in your mind. This note becomes critical when you are unreachable--on a flight, sick, or on holiday--and something goes wrong. It also helps when your team grows and a new person needs to understand the delivery process.

A simple markdown file in your repository works fine. Include:

  • The branch that triggers deployment to each environment
  • The commands to run a manual rollback
  • Where to find logs when a step fails
  • Who to contact if both of you are unavailable

When This Pattern Stops Working

This simple pipeline will not fit forever. As your team grows, your application gets more complex, and your user base expands, you will need more structure. You might need parallel test runs, database migration steps, approval gates for compliance, or deployment strategies like blue-green or canary releases. You might need to separate build, test, and deploy into different stages with different responsibilities.

But for a small startup that needs to move fast, starting with a simple pipeline and full ownership is the right move. You learn the basics of delivery without being buried by complex tools. You build a foundation that can evolve as your needs change. And you avoid the trap of over-engineering before you have a product that people actually use.

Practical Checklist for Your First Pipeline

  • Define three steps: build, test, deploy
  • Choose one CI tool (GitHub Actions, GitLab CI, or cloud provider built-in)
  • Set the pipeline to trigger on push to main
  • Add a manual deploy step for production
  • Log request count, error rate, and response time in your app
  • Write a one-page document on how to roll back
  • Test the pipeline by breaking it on purpose and fixing it

The Takeaway

A simple pipeline built by the people who own the code is better than a complex system managed by someone else. Start small, own the process, and let the foundation grow with your product. You will learn more about delivery in your first month of running a pipeline than in a year of reading about it.