What a Proof-of-Concept Pipeline Actually Needs
The four things a stage-one CI/CD pipeline needs and nothing more, plus why I stopped feeling guilty about hardcoding a bucket name.
Knowing you're allowed to keep stage one simple is one thing. Knowing exactly what "simple" includes is another.
I used to stack tests, linting, multiple environments, and approvals onto every pipeline from day one, before a single real user touched the thing. Then I watched a proof-of-concept take longer to ship than the feature it was supposed to validate.
A proof-of-concept pipeline exists to answer one question: does this work end to end?
Everything that doesn't serve that question is a cost you're paying too early.
The real cost of doing it "right" too soon
Picture a small project hosted on S3 for $40 a month. Its CI pipeline, a security scan here, a three-version Node test matrix there, runs $65 a month, more than the thing it ships.
Nobody sets out to build that. It happens one "just in case" step at a time, until CI/CD quietly becomes its own product instead of a way to ship one.
CI/CD is supposed to be a complement to what you're building, not a system that outweighs it.
What a proof-of-concept pipeline needs: four ingredients, nothing else
Strip a proof-of-concept pipeline down to what it actually needs, and you're left with four things:
A repo pushed straight to main, no branch protection yet. An S3 bucket with static website hosting turned on. An IAM user with programmatic access, scoped to that one bucket. And GitHub repo secrets, so the credentials never sit in the workflow file itself.
That's the whole list. Not "a good list to start with." The whole list.
Ask three engineers to build this and you'll get three different pipelines, because "just get it deployed" leaves a lot of room for opinion. Writing the four ingredients down first is what keeps that room from turning into scope creep.
What the pipeline actually looks like
Once those four pieces exist, the workflow itself splits cleanly into two jobs: one that builds, one that ships.
ExpandA proof-of-concept pipeline: a build job and a deploy job connected by a single artifact
The build job does the part that has nothing to do with AWS:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
- run: npm ci
- run: npm run build
- uses: actions/upload-artifact@v4
with:
name: dist
path: dist/The deploy job does the part that only cares about getting that build onto S3:
deploy:
needs: build
runs-on: ubuntu-latest
steps:
- uses: actions/download-artifact@v4
with:
name: dist
path: dist/
- uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
aws-region: us-east-1
- run: aws s3 sync dist/ s3://your-poc-bucket --deleteEvery GitHub Actions job runs on its own fresh virtual machine, so nothing survives between jobs except what you explicitly hand off. That's why the artifact step exists.
One artifact, uploaded once and downloaded unchanged, is what stops the deployed code from quietly becoming something different from what was tested. The same principle shows up in designing request DTOs for a booking system: the fewer places a value can drift, the fewer bugs from two copies quietly disagreeing.
Where the line actually is
None of this means skipping best practices forever. It means sequencing them.
A proof-of-concept doesn't need tests, multiple environments, or approval gates, because none of those change whether the core idea works. They start to matter the moment a second person needs to trust the pipeline without asking you first, exactly where the next stage in this series picks up.
Until then, four ingredients and two jobs is a complete, correct answer. Not a shortcut you'll apologize for later.
The Essentials
- CI/CD should complement the project, not outweigh it.
- One artifact, passed untouched from build to deploy, is what keeps what shipped identical to what was tested.
Further Reading and Watching
Keep reading