The Modern Web Development Workflow, Day to Day: From Ticket to Production

What does a modern web development workflow look like day to day?

A developer picks up a small, well-defined ticket, creates a branch, implements the change (often with an AI agent working against tests), and opens a pull request. Continuous integration runs type checks, linting and tests, a preview deployment gives everyone a working URL, and a teammate reviews the change before it is merged and deployed. Monitoring and error tracking then confirm it works for real users, and the cycle repeats several times a day.

The principles behind the tools

Teams use different tools, but good workflows share four ideas. Small changes, because small changes are easy to review and easy to undo. Automated checks, because machines are better than people at noticing a broken type or a failing test. A working preview of every change, because reviewing a running app catches problems that reading code misses. And a person accountable for every merge, whether the code was written by a human or an AI agent.

A day in the life: one feature from ticket to production

Here is a realistic day for a developer on a small product team adding a "export invoices to CSV" feature. The times are illustrative.

Branching: keep it simple and short-lived

Most web teams use a branch-based workflow close to GitHub flow. GitHub's documentation describes six steps: create a branch, make changes with clear commits, open a pull request, address review comments, merge, and delete the branch. It recommends keeping each commit to one complete, isolated change and using a separate branch for each unrelated set of changes.

• One main branch that is always deployable, usually called main.
• Short-lived feature branches, ideally merged within a day or two. Long-running branches create painful merge conflicts and big, hard-to-review pull requests.
• Descriptive branch names with a type prefix, such as feat/, fix/ or chore/, which makes the history easy to scan.
• Protected main branch. GitHub's branch protection rules can require pull request reviews, require status checks to pass, require conversations to be resolved, and block force pushes. Turning these on means nobody, human or agent, can push untested code straight to production.

Pull requests: the unit of work

A pull request is where a change is explained, checked and agreed. A good one is small (in our view, a reviewer should be able to read it properly in under half an hour), has a description of the problem and the solution, links to the ticket, includes screenshots or a short recording for UI changes, and notes anything risky such as a database migration. Open it as a draft early if you want feedback on direction before it is finished.

CI: the checks that run on every change

Continuous integration (CI) runs automated checks every time code is pushed. Continuous delivery or deployment (CD) takes the merged result to an environment automatically. Together, CI/CD means the path from commit to production is the same every time. A typical set of CI checks for a TypeScript web app:

Two GitHub features are worth enabling on any repository. Push protection, part of secret scanning, blocks hardcoded credentials before they reach the repository. Dependabot security updates open pull requests that update vulnerable dependencies to a patched version, which then go through the same CI checks as any other change.

Preview deployments: review the running app

A preview deployment is a live copy of the app built from a branch or pull request. Using Vercel as the example, its documentation says it creates a preview deployment by default when you push to a branch that isn't the production branch or open a pull request, and that each deployment gets an automatically generated URL, typically posted as a comment on the pull request. Other hosting platforms offer similar features; check their documentation for the details. Previews let designers, product managers and clients check a change without installing anything, and let reviewers test on real phones.

Working with AI agents, with review built in

AI coding agents such as Claude Code and Cursor's Agent can read a codebase, edit files and run commands, so they fit naturally into this workflow. The discipline is what keeps it safe. Anthropic's Claude Code best-practice documentation recommends:

• Explore, then plan, then code. Have the agent read the relevant code and propose a plan before it changes anything, especially for changes across several files.
• Give it a way to verify its work, such as tests, a build or a screenshot comparison, and ask it to show evidence such as test output rather than just claiming success.
• Keep project rules in a file the agent reads, such as CLAUDE.md, covering commands, code style and branch and PR conventions.
• Review in a fresh context. A separate session or subagent reviewing the diff is not biased towards code it just wrote.

AI code review tools that comment on pull requests are useful as a first pass: they are quick and consistent at spotting common mistakes. In our view they should add to human review, not replace it, and changes to authentication, permissions, payments and data deletion should always get a human reviewer who understands the system. For the specific risks of unreviewed AI output, see the risks of shipping AI-generated code.

Code review: what reviewers look for

Google's published engineering practices give a useful standard: approve a change once it definitely improves the overall code health of the system, even if it isn't perfect. Reviews that demand perfection slow teams down; reviews that rubber-stamp let problems through. A practical checklist:

1. Does it do what the ticket asked, and nothing unrelated?
2. Are authorisation checks in place for every new data access?
3. Are the important behaviours tested, including failure cases?
4. Is it understandable without the author explaining it?
5. Does the preview deployment behave correctly, including on mobile and with a keyboard?
6. Is anything risky, such as a migration or a new dependency, called out and justified?

Automated testing: the test pyramid

The test pyramid, introduced by Mike Cohn and explained in detail in Ham Vocke's article on Martin Fowler's site, says to write many small, fast unit tests, fewer integration tests, and very few end-to-end tests, because high-level tests are slower, more brittle and more expensive to maintain. The article warns against the "ice-cream cone" shape: lots of end-to-end tests and few unit tests. AI agents make writing tests cheaper, which makes it tempting to generate huge suites; the pyramid is a reminder to put each test at the lowest level that can catch the problem.

Releasing: deploy often, release deliberately

• Merging deploys. On most modern platforms, merging to the production branch triggers a production deployment automatically.
• Feature flags separate deploy from release. Code can be in production but switched off, then enabled for staff, a few customers, then everyone.
• Database migrations go first and stay backwards compatible, so the old and new versions of the app can both run during a deploy.
• Know how to roll back. Most hosting platforms let you return to an earlier deployment; find out how yours does it. Vercel's documentation also describes staging a production deployment, checking it on its generated URL, then promoting it to your production domains without rebuilding. Practise the rollback before you need it.

Monitoring: closing the loop

A change isn't finished when it merges; it is finished when it works for users. At minimum, run error tracking on the front end and the server, uptime checks on key pages and APIs, structured logs for important events, and alerts that go to a person who will act on them. Watch the error tracker for an hour after a significant release. Performance matters too: our guide to Core Web Vitals covers what to measure. For how the hosting side fits in, see deploying SaaS on Vercel, Railway or AWS.

The weekly rhythm

We work in fixed two-week sprints with a demo at the end of each, which is a common variation of this rhythm. Whatever the cadence, the aim is the same: working software in front of people regularly.

Scaling the workflow up or down

• Solo developer. Keep branches, pull requests and CI even when you review your own work. Use an AI review and a fresh-context agent review as your second pair of eyes, and read your own diff on the preview before merging.
• Small team. Everything above, with one required human approval and protected main.
• Regulated or larger teams. Add code owners for sensitive areas, required approvals from security for specific paths, audit trails of deployments and formal change records.