Goodbye Waterfall: The Workflow That Puts Frontend at the Center

Let me describe a scenario that might sound familiar:

1. Product Owner defines requirements
2. UX creates wireframes
3. Design delivers PSDs
4. Backend implements features
5. Frontend receives everything and has to "make it look pretty"
6. Deadline missed, bugs appear, everyone stressed

This is the classic waterfall workflow. And it doesn't work anymore.

Why the Old Workflow Fails

The fundamental problem is that frontend comes last. This means:

• Source order problems discovered too late
• Designs that kill performance
• UX that doesn't work on mobile
• CMS-generated markup that can't be styled
• Zero time to refactor

When frontend is "painting the wall at the end", you're not building a site — you're putting makeup on a problem.

The New Paradigm

In the modern workflow, disciplines work in parallel, not in series:

Phase 1: Requirements (Multidisciplinary)

Requirements aren't written by one person and passed along. They're defined by:

• Product Owner (what and why)
• UX (how the user interacts)
• Design (how it looks)
• Frontend (how it works technically)
• Backend (how data flows)

Everyone in the same room. Everyone contributing.

Why this matters: Problems that used to only appear at the end are now detected at the start:

• "This carousel will kill performance on 3G"
• "This animation doesn't work in Safari"
• "This layout breaks on small screens"

Phase 2: Prototyping (In the Browser)

Instead of passing static artifacts (wireframes, PSDs, specs), the team creates functional prototypes in the browser.

Prototypes are:

• Interactive
• Responsive
• Testable on real devices
• Quickly iterable

Modern prototyping tools:

The goal is to test ideas before committing production code.

Phase 3: Development (With Ready Markup)

When a feature reaches development, it already has:

• Tested and approved design
• Validated HTML markup
• Working CSS
• Defined JavaScript behavior

Backend's job becomes: get data from the database and pass it to the template. No need to invent markup or guess CSS classes.

Benefits:

• Fewer back-and-forths
• QA compares code against prototype (gold standard)
• More predictable deploys

The Detailed Frontend Workflow

Within the prototyping phase, frontend has its own mini-workflow:

1. Provisioning (Environment Setup)

How long does it take for a new dev to start working?

Bad: Days of manual configuration Good: One command and ready

Tools that help:

• Docker — Consistent environment
• nvm/fnm — Correct Node version
• dotenv — Environment variables
• Updated README — Clear instructions

2. Story Writing (Work Definition)

Each task should have clear criteria:

3. Development (Code)

With a clear story and ready environment, development flows:

1. Create branch
2. Develop isolated component
3. Test in Storybook
4. Write tests
5. Integrate into application
6. Code review
7. Merge

4. Distribution (Delivery)

How does your code get to production?

Typical pipeline:

Push → CI (lint, test, build) → Staging → QA → Production

Modern tools:

• GitHub Actions / GitLab CI — Automation
• Vercel / Netlify — Deploy preview per PR
• Feature flags — Deploy without release

Committing Compiled Assets: Yes or No?

Classic question: should we commit compiled CSS/JS?

Arguments against:

• Pollutes git history
• Merge conflicts
• Information duplication

Arguments for:

• Simpler deploy
• Less CI dependency
• Easier rollback

Modern answer: Generally no. CI compiles and deploys. If you need rollback, redeploy the previous commit.

Continuous Integration for Frontend

CI isn't just for backend. Frontend benefits enormously:

On Push:

• Lint (ESLint, Stylelint)
• Type check (TypeScript)
• Unit tests
• Build

On PR:

• Visual regression tests
• Bundle size check
• Accessibility audit
• Deploy preview

On Merge:

• Deploy to staging
• E2E tests
• Performance tests

Example workflow (GitHub Actions):

The Culture of Automation

The goal of this entire process is:

Reduce what can go wrong when humans do repetitive tasks.

Each manual check is an opportunity for error. Automate everything you can:

• Code formatting (Prettier)
• Type checking (TypeScript)
• Tests (Jest, Playwright)
• Deploy (CI/CD)
• Even partial code review (linters)

Starting the Change

If your team is still on waterfall:

1. Don't try to change everything at once — Introduce one practice at a time
2. Show results — Nothing convinces more than evidence
3. Document gains — "Before: 3 days. After: 4 hours"
4. Create allies — Find those who suffer with the current process

The transition is gradual, but each incremental improvement makes the next one easier.