Infrastructure you can build in a weekend vs what takes a hire

A pre-seed founder in Berlin messaged me last month. She had raised EUR 400,000 and was trying to figure out what infrastructure to build before launch. She sent me a list. It had 23 items on it. Kubernetes. ArgoCD. Prometheus. Grafana. OpenTelemetry. A service mesh. An API gateway. Terraform modules for three cloud providers. A secrets management vault. A security scanner. An autoscaling setup. On and on.

I asked her how much time she had. She said two weekends. I told her to delete the list and start over.

The conversation that followed is one I have had at least forty times. Pre-seed founders either try to build everything because they read a blog post about how Spotify does infrastructure, or they build nothing because they are scared of doing it wrong. Both are mistakes. The truth is that a surprising amount of infrastructure can be set up in a weekend by a technical founder who is willing to follow instructions. And a smaller amount genuinely requires someone who has done it before.

The problem is that founders cannot tell which is which. So here is the line, drawn from three years of building startup infrastructure and cleaning up infrastructure that founders built themselves.

What you can build in a weekend

I am going to be specific, because generalities are useless here. These are the things I have watched a single technical founder set up in a weekend, repeatedly, without help. Not perfectly. Not production-hardened. But functional and good enough to launch on.

A CI pipeline that runs tests on every push. GitHub Actions. Twenty lines of YAML. Your tests run on every pull request, and merges to main are blocked if tests fail. This is the single highest-leverage thing you can do, and it takes an hour.

# .github/workflows/ci.yaml
name: ci
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

That is it. No matrix builds, no caching strategy, no parallel test runners. Those come later. The point is that no code reaches main without passing tests. If you have this, you are ahead of roughly half the pre-seed startups I audit.

A deploy that is one command, not a script that lives on someone’s laptop. If your deploy is a shell script on the founder’s MacBook, it is a single point of failure. Move it into CI. The pipeline builds a container image, pushes it to a registry, and deploys it. If you are on a single VPS, this is docker pull and docker run via SSH from a GitHub Actions runner. It is not elegant. It works, and it is reproducible.

  deploy:
    needs: test
    runs-on: ubuntu-latest
    if: github.ref == 'refs/heads/main'
    steps:
      - uses: actions/checkout@v4
      - uses: docker/build-push-action@v6
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:latest
      - name: Deploy
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.HOST }}
          username: deploy
          key: ${{ secrets.SSH_KEY }}
          script: |
            docker pull ghcr.io/${{ github.repository }}:latest
            docker stop app || true
            docker rm app || true
            docker run -d --name app --restart unless-stopped -p 80:3000 \
              ghcr.io/${{ github.repository }}:latest

Is this GitOps? No. Is it going to scale to a cluster with twenty services? No. Does it beat a shell script on a laptop? Yes, by a margin that is hard to overstate. The deploy is reproducible, auditable, and does not require the founder to be online. That is the bar at pre-seed.

Basic monitoring with a single alert. I do not mean a full Prometheus stack. I mean Uptime Robot or a health check endpoint monitored by a free service, with one alert that pages someone if the site is down. This takes fifteen minutes and it is the difference between finding out your site is down from a user email versus finding out before the user notices.

A secrets strategy that is not a .env file in the repo. This is where most pre-seed startups fail, and it is also the easiest fix. Use a secrets manager or at minimum encrypted environment variables in CI. GitHub Actions secrets are free. Doppler is free for small teams. The point is that no secret is committed to the repository. I have audited startups where the production database password was in a file called config.example.js. It was not an example. It was live.

These four things, CI, deploy, monitoring, and secrets, are a weekend. I have seen it done. I have done it myself on a Sunday in Leh when the internet was intermittent and the power went out twice. It is not glamorous. It is the floor.

What takes a week of focused work

There is a second tier of infrastructure that a technical founder can build, but it takes a week, not a weekend. It requires reading documentation, making decisions, and testing. Most founders try to skip this tier and jump straight to the third, which is where things break.

Migrating from a VPS to a managed container service. If you have outgrown the single VPS, the next step is not Kubernetes. It is a managed container service like ECS, Cloud Run, or Fly.io. This takes a day to set up and a few days to migrate to. The benefit is autoscaling, health checks, and zero-downtime deploys without you building them. The cost is learning the platform’s deployment model, which is simpler than Kubernetes by an order of magnitude.

A real CI/CD pipeline with GitOps. This is where you move from “CI deploys via SSH” to “CI builds an image, updates a manifest, and ArgoCD syncs it to the cluster.” It is a better model, and it is the one I install for every startup that has more than one service. But it takes a week to set up properly. You need a separate deploy repository, an ArgoCD installation, application manifests, and a rollback procedure that you have actually tested. The founders who try to do this in a weekend ship a broken ArgoCD setup that nobody understands, which is worse than the SSH deploy they replaced.

An observability stack that is not just uptime monitoring. Prometheus, Grafana, and a small set of dashboards. This takes a week because the hard part is not installing Prometheus. The hard part is deciding what to measure. I have seen startups install Prometheus, scrape everything, and end up with 400 metrics and zero useful dashboards. The week is spent on: what are your three SLOs, what are the five alerts that actually matter, and what does the dashboard look like that you would open during an incident. The installation is a day. The thinking is the rest of the week.

A basic security baseline. Not a SOC 2 audit. Not a penetration test. A baseline: dependency scanning in CI, container image scanning, HTTPS everywhere, RBAC on your cloud account, and a threat model that identifies your top three risks. This takes a week because the threat model requires you to sit down and think about what you are actually protecting and from whom. Most founders skip the thinking and install the tools, which gives them a false sense of security. The tools without the threat model are a checkbox, not a control.

What genuinely requires a hire or a program

This is the line. Everything above this point, a technical founder can do with time and willingness. Everything below this point requires either someone who has done it before in production, or a structured program that delivers it.

A production-grade GitOps setup with multi-environment promotion. A single ArgoCD instance syncing one app to one cluster is a weekend. ArgoCD with staging and production environments, promotion pipelines that require approval, sync windows, drift detection, and a rollback procedure that has been tested under simulated incident conditions, is not. I have watched founders attempt this and produce a setup where staging and production diverge silently, where ArgoCD is syncing manually because the auto-sync was causing issues, and where nobody knows how to roll back because the rollback was never tested. The damage from a broken GitOps setup is worse than the damage from no GitOps, because it creates the illusion of control.

An observability stack with OpenTelemetry instrumentation. Installing Prometheus and Grafana is a week. Instrumenting your applications with OpenTelemetry traces, correlating traces with metrics and logs, building SLO dashboards that the on-call engineer can actually use during an incident at 3am, and setting up alerting that does not page you on every noise. This takes experience. The difference between a good alerting setup and a bad one is not visible until the first real incident, at which point it is too late to fix it. I have been on calls where the on-call engineer spent twenty minutes looking at dashboards that told them nothing while the outage continued. That is a setup built by someone who had never been paged.

A security baseline that survives an actual audit. Dependency scanning is a weekend. A security posture that includes network policies, secret rotation, access reviews, an incident response plan, and documentation that maps to a framework like CIS or SOC 2, is a different thing entirely. Startups try to shortcut this by buying a compliance automation tool and clicking through it. The tool generates the paperwork but not the security. When an investor or an enterprise customer asks for evidence, the gaps show up in the first ten minutes.

Runbooks that work under pressure. Writing a runbook in a calm office is easy. Writing a runbook that an engineer who was woken up at 4am can follow, with their hands shaking, while the Slack channel is filling with messages, is a skill that comes from having been on call. I have never seen a founder write a good runbook on the first try, because they have not been in the incident that the runbook is for. The runbooks I write are tested. I run the incident scenario, hand the runbook to someone who has never seen it, and watch them try to follow it. If they get stuck, the runbook is wrong. Most first-draft runbooks fail this test.

A cloud architecture that is cost-optimized for your actual scale. Founders overprovision because they are scared of running out of capacity, or they underprovision because they are scared of the cloud bill. Both are wrong. Right-sizing compute, storage, and networking to your actual traffic pattern requires knowing what the options are and what the tradeoffs cost. I audited a pre-seed startup last year that was spending EUR 2,800 a month on AWS for a product with 200 daily active users. They had a three-node EKS cluster, a Multi-AZ RDS instance, an Application Load Balancer, a NAT Gateway, and CloudFront, all for traffic that a EUR 40 VPS would have handled. They did not need a hire. They needed someone to look at the bill and tell them what to turn off. But knowing what to turn off without breaking the system is not obvious.

The mistake I see most often

The mistake is not building too little or building too much. The mistake is building the wrong tier. Founders spend a weekend trying to set up ArgoCD and a multi-environment pipeline, fail, and conclude that infrastructure is too hard and they should just hire someone. Then they hire someone and ask them to build the weekend-tier things, which the hire does in two hours and then sits idle because the founder has nothing else for them to do.

Or founders build nothing, launch on a VPS with a deploy script, raise a seed round, and then face investor diligence with no CI, no monitoring, no runbooks, and a deploy process that lives on a laptop. The investor asks what happens when someone merges to main, and the founder pauses, and the pause costs them 15% of their valuation. I have watched this happen. The pause is expensive.

The correct sequence is this. Build the weekend tier yourself, now, before you need it. Build the week tier yourself when you have one paying customer and a second service. Get help with the hire tier when you are about to raise, or when you are about to onboard an enterprise customer who asks for security evidence, or when your deploy process is scaring your investors.

Do not try to build the hire tier in a weekend. Do not ignore the weekend tier because you think you will hire someone. Build the floor, stand on it, and bring in help for the ceiling.

What I actually tell founders

When a pre-seed founder asks me what to build, I give them a one-page checklist. It has the four weekend items and the four week items. I tell them to do the weekend items this Saturday. I tell them to do the week items before they raise their seed round. I tell them to get help with the hire tier before they raise their Series A or before their first enterprise deal, whichever comes first.

The founders who follow this do not call me in a panic at 2am because production is down and nobody knows how to deploy. The founders who ignore it do.

If you are a startup reading this and recognizing the gap between your weekend tier and your hire tier, Basecamp exists for exactly this reason: digitalaultis.com/basecamp

The line between what you can build yourself and what requires experience is not where you think it is. The weekend tier is bigger than you expect. The hire tier is deeper than you fear. Build the floor this weekend.