Web Development Workflows: Streamlining Processes for Efficiency of Projects

Two developers get the same project. One ships it in three weeks. The other is still fixing things three months later, breaking the live site every time they deploy, and cannot remember which file on the server is the current one.

The difference is almost never talent. It is workflow: the small set of habits and automated steps that sit between “I had an idea” and “it is live and it works”. This guide walks one real project through all six stages, with the actual config files you can copy, so you leave with a workflow rather than a list of nouns.

The Pipeline

Every professional project, whether it is a one-person WordPress site or a product with fifty engineers, moves through the same six stages. The difference between slow teams and fast ones is how much of this is automatic.

Click a Stage

Each stage has a job, a few tools, and usually one command. Pick one.

Stage 1: Plan Before You Open the Editor

The most expensive bug is the feature nobody wanted. Before any code, write down what the project must do, what it must not do, and what “finished” looks like.

Then break it into tasks small enough to finish in a day. A task called “build the site” sits untouched for weeks. A task called “add contact form validation” gets done this afternoon.

The same four columns work in Trello, Jira, Asana, Notion or GitHub Projects. The tool matters far less than the habit (illustration).

Stage 2: Build on a Branch

Never work directly on main. One branch per task keeps your unfinished work away from the version that is live, and makes it trivial to abandon an idea that did not work.

# Start from an up-to-date main
git switch main
git pull

# One branch per task, named after the task
git switch -c feature/14-mobile-nav

# ...work, then commit in small pieces
git add src/nav.js
git commit -m "feat(nav): close menu when a link is tapped"

git push -u origin feature/14-mobile-nav

Commit messages with a shape

Pick a convention and keep it. The common one is type(area): what changed. It takes two days to get used to and makes your history readable forever, and tools can generate changelogs from it automatically.

feat(cart): add quantity selector
fix(nav): close menu when a link is tapped on mobile
perf(images): convert hero images to WebP
docs(readme): add local setup steps
chore(deps): update eslint to v9

# Instead of:
update
fix stuff
final changes v2

Same commands for everyone: npm scripts

Put every routine command in package.json. Then nobody has to remember flags, and a new person on the project can start in one minute.

{
  "scripts": {
    "dev":      "vite",
    "build":    "vite build",
    "preview":  "vite preview",
    "lint":     "eslint . --max-warnings 0",
    "format":   "prettier --write .",
    "test":     "vitest run",
    "check":    "npm run lint && npm run test && npm run build"
  }
}

Now the whole project has one entry point: npm run check before you push. If that passes, you are unlikely to break anything.

Stage 3: Review Before It Goes Anywhere

Open a pull request even if you are the only person on the project. It gives you one page showing exactly what changed, a place for the automatic checks to report, and a record of why you did it.

A pull request with automatic checks and a preview link. The reviewer looks at the change, not the whole project (illustration).

A review checklist that fits on one screen

Stage 4: Let the Machine Do the Checking

Anything a tool can catch, a human should never be checking by hand. Formatting arguments in code review are a waste of everyone’s week, so delete them with configuration.

Formatting and linting

npm install -D eslint prettier eslint-config-prettier husky lint-staged
npx eslint --init
npx husky init

{
  "semi": true,
  "singleQuote": true,
  "printWidth": 100,
  "tabWidth": 2,
  "trailingComma": "es5"
}

Then make it impossible to commit code that fails. This hook runs the linter on the files you actually staged, every time you commit:

// package.json
{
  "lint-staged": {
    "*.{js,jsx,ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.{css,md,json}":   ["prettier --write"]
  }
}

# .husky/pre-commit
npx lint-staged

$ git commit -m "feat(nav): close menu on tap"
✓ Preparing lint-staged...
✓ Running tasks for staged files...
✗ eslint --fix found 1 problem

  src/nav.js:22  error  'menuEl' is assigned a value but never used

husky - pre-commit script failed (code 1)

The mistake is caught on your own machine, seconds after you made it, instead of by a colleague two days later.

Checking it works everywhere

Responsive design and cross-browser testing belong here too. Most of it you can do free, in the browser you already have.

Stage 5: Deploy Without Fear

Manual deployment is where most small projects lose their evenings. Dragging files over FTP means no record of what changed, no way back, and a live site that breaks at 11pm.

Here is a complete pipeline. Push to main, and it checks everything and publishes only if the checks pass.

name: Deploy

on:
  push:
    branches: [main]
  pull_request:              # run the checks on PRs too

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci            # exact versions from package-lock
      - run: npm run lint
      - run: npm test
      - run: npm run build

      - name: Upload the built site
        uses: actions/upload-artifact@v4
        with:
          name: dist
          path: dist/

  deploy:
    needs: check               # only if every check passed
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist

      - name: Publish to the server
        env:
          DEPLOY_KEY: ${{ secrets.DEPLOY_KEY }}   # never in the file
        run: ./scripts/deploy.sh

An illustration of a pipeline run. GitHub Actions is free for public repositories and has a generous free allowance for private ones.

Have three environments, not one

Stage 6: Watch What Happens Next

Shipping is not the end of the workflow. A deployment you do not measure is a guess.

# Fix forward if it is small and obvious.
# Otherwise, undo the deploy first and investigate calmly.

git revert <the-bad-commit>     # a new commit that undoes it
git push                        # the pipeline redeploys the good version

# Note: `git revert` is safe on shared branches.
# `reset --hard` and `push --force` are not.

Choosing the Stack Without a 40-Point Checklist

Long CMS comparison checklists are not much use when you are choosing on a Tuesday afternoon. In practice the decision usually comes down to three questions.

If You Are One Person, Not a Team

Most workflow advice assumes a ten-person team with a scrum master. Here is the honest version for a freelancer or a solo developer, because the goal is not ceremony, it is not losing work and not breaking the live site.

The README that saves you an hour every time

# Client Site

What it is: marketing site + blog for Acme Ltd.
Live: https://acme.com  ·  Staging: https://staging.acme.com

## Run it locally
    npm install
    cp .env.example .env     # ask me for the real values
    npm run dev              # http://localhost:5173

## Before you push
    npm run check            # lint + tests + build

## Deploying
Push to `main`. GitHub Actions does the rest.
Rollback: `git revert <commit>` and push.

## Things that will confuse you
- Images are optimised at build time, so add originals to /src/images.
- The contact form posts to a Netlify function, not to the CMS.
- Staging uses a copy of the database, refreshed every Monday.

Where Workflows Actually Break

Common Questions

If this was useful, share it with someone still deploying by dragging files into FileZilla.