How to get hired as a web developer in 2026-27

The three web developer markets, and why advice for one sinks you in another

Web developer is one job title covering three hiring processes that barely resemble each other. Most advice fails because it was written for one of them and read by someone aiming at another.

Agency and studio employment means you are staff at a business that builds for other people's clients. You will ship several projects a year, hand most of them over, and rarely see the three year consequences. Screening is done by a lead developer or the owner, who will look at your portfolio before they look at your resume and form an opinion in under two minutes. What they are buying is throughput with low supervision: can you take a Figma file and a content doc and produce something accessible, responsive and on budget without asking the project manager eleven questions a day.

In-house at a small or mid-size business means you are the web person. The site, the landing pages, the email templates, the analytics, the booking form, the thing the sales team broke. Your manager is usually a marketing director with no technical background, and your real competition for the role is the agency retainer they considered instead. They hire on comparability and communication: have you built something like ours, and can you explain a delay without making me feel stupid. Technical depth helps you keep the job. It rarely gets you the job.

Direct client freelance and subcontract work is not hiring at all, it is sales. Nobody interviews you. A business owner finds you through a referral, a directory or a search, has a 30 minute call, and either accepts a proposal or does not. Your portfolio is a sales asset, your contract is your protection, and your cash flow depends on deposits and on how fast you invoice. The quiet variant of this market, and the best entry to it, is white label subcontracting to agencies: they have the clients and the sales function, they are short of reliable build capacity, and they will keep you busy without you ever pitching.

You can move between these. You cannot optimise for all three at once. An agency wants to see range and speed. A small business wants to see sites belonging to businesses like theirs. A direct client wants to see outcomes and hear a reference. Pick the one you want first, build for that, and treat the others as later options.

• Agency or studio: screened by a developer, judged on portfolio and speed, short loop, salaried.
• In-house: screened by a marketing manager, judged on comparable work and communication, broad scope.
• Direct client: no interview, judged on references and proposal, paid per project or per month.
• Subcontract to agencies: the lowest friction way into freelance income, because someone else is selling.
• Marketplaces (Upwork, Contra, Toptal, Codeable) are a channel, not a career. Treat them as lead generation with a fee, and move good clients off them when the contract allows.

What site builders and AI took, and what they left

Be honest about this, because clients already know and candidates who pretend otherwise lose credibility in the first call. A competent small business owner can now describe a site to an AI builder and have something presentable by the end of the day. Wix, Squarespace, Framer, Shopify and the hosting companies all ship generation tools, and tools like v0, Lovable, Bolt and Replit will generate a working application from a prompt. The floor price for a generic brochure site has collapsed, and it is not coming back.

What that killed is a specific product: the small static marketing site, built from a template, with content the client supplies, no integrations and no ongoing responsibility. If that was your plan, the plan is gone. Do not try to win it back on price. You will be competing with a monthly subscription that also includes hosting, SSL, forms and a CDN.

What it left is substantial, and most of it is more interesting than what it took. Integration is the biggest category: a business runs a practice management system, a point of sale, an ERP, a CRM, a scheduling tool and an accounting package, and wants the website to talk to two or three of them. That work is specific, unglamorous and resistant to generation, because the hard part is the other system's API, its authentication, its rate limits and its undocumented behaviour, not the page.

Migration is the second. Moving a 900 page site off a dead CMS without losing URLs, redirects, metadata, structured data or rankings is a job with a measurable failure mode, which is exactly why it gets paid. Anyone who has watched a client's organic traffic fall off a cliff after a rebuild understands why they hire for this specifically.

Then: ecommerce and payments, where money moves and mistakes are expensive. Accessibility remediation, now contractually required in a growing share of public sector and enterprise work. Performance, where Core Web Vitals (LCP, CLS, and INP, which replaced FID as the responsiveness metric) give you a deliverable you can measure before and after. Security and maintenance, including the WordPress plugin updates nobody wants to own. And the newest category, which barely existed two years ago: fixing applications that were generated by AI, shipped by a non-developer, and then went wrong. These arrive with no migrations, no backups, API keys in client-side code, authorisation checks only in the interface, and a founder who cannot change anything without breaking it. Being the person who can stabilise one of those is a 2026 service line with very little competition.

The strategic point: stop selling pages and start selling responsibility. A site builder cannot be accountable. A generated app cannot be on call. The things clients pay a human for are judgment (what do we actually need), integration (make it work with what we have), continuity (be there in March when it breaks), and risk (if the checkout fails, someone is answerable). Price and position around those four and the builders stop being competitors. They become part of your toolkit, because the right recommendation for a yoga studio with a four figure budget genuinely is Squarespace, and saying so is how you earn the right to the next job.

• Dead as a business: template brochure sites sold on price.
• Alive and scarce: integrations with the client's existing systems, migrations without SEO loss, ecommerce and payments, accessibility remediation, performance work with measured results, security and maintenance retainers, and rescuing AI-generated builds.
• Position on judgment, integration, continuity and risk. None of those four can be bought as a subscription.

How hiring actually works, market by market

Agency and studio. The first filter is your portfolio links, opened on a phone, by someone with 40 other applications on the desk. They click two sites, look at how fast they load, resize the window, and read your description of what you did. If you cannot separate your contribution from your team's, that is a fail at this stage, because agencies have been burned by candidates who showed work they did not build. Then a 30 to 45 minute call with the lead developer or the owner, which is mostly one of your projects in detail: why that stack, what went wrong, what the client changed late, how you handled it. Then an exercise. A reasonable one is two to four hours: implement a component or a section from a provided design, responsive, keyboard accessible, with a short note on your decisions. Debug a broken page. Review a pull request. An eight hour unpaid build of a real client feature is a red flag about how that studio treats people, and you are allowed to ask to be paid. Many small studios skip the exercise entirely and offer a paid trial project instead, which is a better signal for both sides. Expect a question about how you use AI tools, and expect the answer they are listening for to be about review and responsibility rather than speed.

In-house at a small business or nonprofit. Your resume is read by someone who does not know what Astro is. Write for them. The interview is usually one or two conversations, and the most common real test is open-ended: they send you their current site and ask what you would do. This is where most technical candidates lose. The wrong answer is a list of defects. The right answer is two or three things that would move the number the business cares about, ranked, with rough effort, plus one thing you would deliberately leave alone. Say which you would do in the first month. They are trying to work out whether you will be a cost centre who complains about their legacy site, or someone who makes their numbers better. Expect the scope to be wider than the title: email templates, analytics, basic technical SEO, a print job, the CRM integration, training the intern to edit pages.

Direct client. There is no loop, there is a sales process, and it has a shape. A lead arrives (referral, directory, local network, search). You run a discovery call where you ask more about their business than about their website: what makes money, who the customer is, what happens today when someone enquires, what they have tried, what their deadline is tied to. You send a written proposal with scope, exclusions, timeline, payment schedule and what you need from them. You get a deposit before you start, and the deposit is not negotiable. Most of the skill in this market lives in the hour before the proposal, not in the build.

What gets people rejected at each stage is predictable. Portfolio stage: dead links, slow sites, tutorial projects, no statement of what you did. Call stage: inability to talk about a project as a set of decisions rather than a list of technologies, and badmouthing a previous client. Exercise stage: ignoring the accessibility and responsive requirements that were written in the brief, no README, and code that works only on the reviewer's machine. Proposal stage: a quote with no exclusions, which guarantees an argument later.

• Have your portfolio URLs working today. Broken links in a portfolio are the most common silent rejection in this trade.
• Be able to name your own contribution on every piece of work you show.
• For the agency exercise, do exactly what the brief says, then add a short note on what you would do next with more time.
• For in-house, prepare a ranked three-item critique of their existing site before the first call. You will almost always be asked.
• For direct clients, never quote on the discovery call. Quote in writing, after you have seen the content.

The portfolio: five case studies beat twenty thumbnails

Your portfolio is the hiring decision in this trade. It is also, awkwardly, a work sample of itself: if your own site takes four seconds to render a hero video on a phone, you have answered the performance question before anyone asks it. Build it fast, make it legible, make it keyboard navigable, and make the case studies the point rather than the animation.

Three to five case studies is the right number. Each one needs five things, in this order: the business problem in the client's language, the constraints you worked inside (budget, deadline, the CMS they refused to leave, the content that arrived three weeks late), what you actually built with specifics, what changed that can be measured, and what you would do differently. That last item is the one that makes experienced reviewers trust you, because it shows you have seen consequences.

Measurable change is where most portfolios go vague. You do not need a conversion study. You need something verifiable and modest, written the way these examples are written: largest contentful paint went from 4.1 seconds to 1.4 on a throttled mobile profile; the migration moved 412 pages with a redirect for every one of them, and organic sessions were flat within three weeks rather than falling; the booking form that used to email the owner now writes into their scheduling system, which removed about an hour a day of retyping; the accessibility pass cleared every automated failure on the eight templates and added a manual keyboard and screen reader pass. Record the before numbers on the first day of a project, because you cannot reconstruct them afterwards.

No real clients yet? Build work that has a real stakeholder, which is not the same as a real invoice. In rough order of how much hiring managers respect it: paid work for a tiny business even at a low price; unpaid work for a community organisation where someone else makes the decisions and can be unhappy; a rebuild of a specific existing local business site done as a speculative case study, clearly labelled as unsolicited, with before and after measurements taken from the live original (this is the most underused move available to a beginner, and it doubles as a sales pitch to that business); a tool that solves a real problem for a specific group of people and has actual users. Avoid: another portfolio template, a clone of a famous product, anything from a course where thousands of other people submitted the same repository.

Show the inside, not only the outside. Link a public repository for at least one project, with a README that explains the decisions, a reasonable commit history, and tests if the project warrants them. Agency leads do open these. A repository with four commits named update is a worse signal than no repository at all.

Plan for link rot. Client sites get redesigned and your evidence disappears with them. Screenshot and archive every project at launch, record the metrics, and write the case study in the week you finish rather than two years later when the site has been replaced by someone else's work.

• Three to five case studies, each with problem, constraints, what you built, measured change, and what you would redo.
• Measure before you start. The before number is unrecoverable later.
• One public repository with a real README and a sane commit history.
• A speculative rebuild of a named local business, labelled as unsolicited, is both portfolio evidence and a sales approach.
• Archive screenshots and metrics at launch so a client redesign does not erase your proof.

The resume and the proposal: what lands and what gets skipped

A web developer resume is read in two different ways depending on the market, so you need two versions. The agency version is read by a developer who wants stack, scale and evidence. The in-house version is read by a marketing manager who wants business outcomes in plain words. The freelance equivalent is not a resume at all, it is a proposal and a one-page capability summary.

What lands on the agency resume: live URLs next to the relevant role, with your contribution named. The platforms you can be trusted alone with, separated from the ones you have touched once. Scale facts that imply judgment: a 900 page migration, a multi-language build, a store with 4,000 SKUs, a site under a traffic spike from a television slot. Launches, plural, because shipping is the skill. Maintenance and on-call work, which is undersold constantly and is exactly what agencies struggle to staff. Accessibility and performance work with numbers. Handover and documentation, if you have ever trained a client to run their own site.

What lands on the in-house resume: the business outcome first. Rebuilt the site on a new CMS so the marketing team could publish without a developer, which removed a two week queue. Fixed the checkout error that was losing orders on mobile Safari. Cut page weight so the campaign landing pages stopped burning ad budget on bounces. Then a short technical section underneath, because someone technical may still be in the room.

What gets skipped by everyone: a skills wall listing HTML5, CSS3 and responsive design, which reads as filler because those are assumed. Logo grids of technologies you used once. Self-description paragraphs about passion, pixel perfection and being detail oriented. Certificates from video course platforms (they are not harmful, they are just not evidence, and a bootcamp name is worth less than one real client). Twelve repositories of unfinished exercises. Soft skill claims with no incident attached.

Format, briefly, because it matters more than people think for a trade with no credential: one page if you have under about eight years in, two at most, plain and parseable, no two column layout that an applicant tracking system will scramble, and a links line at the top with your site, your repository host and your best live project. Put the live URL in the bullet, not only in a portfolio nobody opens.

For freelance work, the equivalent document is the proposal, and it is the single highest leverage thing you can learn to write in this job. A proposal that wins has: the client's goal restated in their words so they know you listened, scope as a list of deliverables, an explicit exclusions list (this is the section that prevents arguments, and amateurs omit it), what you need from them and by when, the timeline with its dependency on their content stated plainly, the price and the payment schedule, and what happens after launch. Two to four pages. Send it within 48 hours of the call while they still care.

• Two resume versions: outcomes first for in-house, stack and scale for agencies.
• Live URL in the bullet, with your specific contribution named.
• Cut the assumed-skills wall and the passion paragraph. Nobody reads them and they cost you space.
• Sell maintenance and on-call experience explicitly. Agencies are short of people who will own a live site.
• Learn to write a proposal with an exclusions list. It is worth more per hour than any framework you could learn this year.

What the technical stages actually test

Web developer interviews, in the agency and small business markets, are not algorithm interviews. If you are being asked to invert a binary tree, you have applied to a product engineering role that happens to use the word web in the title, and you should prepare differently. What these stages test is whether you can be handed a design and a deadline and produce something that holds up in the real world.

The design-to-code exercise. You get a Figma file or a screenshot and a few hours. What is being graded, in rough order: does it match at the specified breakpoints, does it work on a keyboard, are the semantics right (real headings in order, real buttons, labelled inputs, alt text that says something), does it degrade sensibly with long content or a missing image, is the CSS something another developer could extend next month, and did you read the brief. Modern CSS is an easy place to show current competence: container queries for components that must adapt to their container rather than the viewport, logical properties, clamp for fluid type, grid including subgrid, and :has where it saves a wrapper. Avoid reaching for a framework the brief did not ask for.

The debugging exercise, which is the most predictive of the lot. A page you did not write, something is broken, talk while you work. They are watching your method: reproduce it, confirm what you expect versus what happens, bisect, read the actual error rather than guessing, check the network panel before rewriting code, and say out loud when you are wrong. Candidates fail this by silently theorising for 15 minutes. Narrate.

Fundamentals, asked conversationally. The box model, stacking contexts and containing blocks, because positioning bugs are a large share of front-end work. Specificity and the cascade, including cascade layers. Event delegation and what happens on a click. Promises, async and await, and how you handle a fetch that fails or times out, which is the question that separates candidates fastest because most code only the happy path. Forms: validation, server trust, file uploads, why you never rely on client-side checks. Caching and what a CDN does. CORS, which breaks real builds often enough that every working developer can describe a preflight request. How a request becomes a rendered page, including DNS, TLS and the difference between server rendered, static and client rendered output.

The judgment questions, which decide senior versus mid. A client wants a feature in a week that needs three. What do you do. The content has not arrived and the launch date is fixed. How do you ship. A client asks for a carousel with nine slides and autoplay. What do you say and what do you build. The budget allows one of accessibility work, a performance pass or a CMS upgrade. Which do you pick and why. The client's developer nephew has edited the live theme. How do you proceed. Answer these with a decision and a reason, not with it depends.

The security and reliability questions that get skipped and then cost someone their job. Where do secrets live. Who has the DNS. What is the backup and have you restored from it. How do updates reach production. What is in place if the site is defaced on a Saturday. If you handle payments, why Stripe or the platform checkout rather than touching card data yourself. If you handle European visitors, how consent is captured before the tracking scripts load. A candidate who raises these without being asked moves up a band.

References, which matter more here than in most software hiring because there is no credential. A lead developer who will say you shipped on time, or a client who will say you answered the phone, is worth more than any certificate in this trade. Ask at the moment a project goes well, not a year later.

• Narrate the debugging exercise. Silence reads as not knowing.
• Handle the failure path in any code you write in front of someone.
• Semantics, keyboard access and labels are graded even when the brief does not mention them.
• Answer judgment questions with a decision, a reason and a tradeoff you accepted.
• Bring up backups, secrets and updates unprompted. Very few candidates do.

Pricing, scope and the paperwork that keeps you solvent

For employed roles, your pay is set by market and by which of the three markets you are in. Agencies pay less than product companies for similar skill, because an agency sells your time at a multiple of its cost and the margin has to live somewhere; in exchange you get volume and variety early in a career, which is why agency years are worth more than they pay. In-house single-developer roles at small businesses vary widely and often sit below both. Get real figures rather than guessing: BLS code 15-1254 for national, state and metro percentiles, then live postings in pay-transparency jurisdictions where a band is required in the advertisement. When you negotiate, negotiate against postings in your metro, not against a national average.

For freelance work, the single most expensive mistake is selling hours. An hourly rate punishes you for getting faster and invites the client to audit your day. Three better models. Fixed price per defined scope, which requires you to write exclusions and change orders properly, and which rewards speed. A day rate for work with unpredictable shape (audits, debugging, legacy rescue, sitting with a client's team), typically sold in blocks. A monthly retainer or care plan, which is what turns freelancing from feast and famine into a business: hosting, updates, backups, monitoring, uptime, a small bucket of changes per month, and a stated response time. Three care plan clients paying monthly change your year more than one big build.

How to price a fixed scope without guessing. Estimate in deliverables, not hours. Break the build into countable items (templates, not pages; integrations; forms; migration volume; content entry) and price per item, because clients can follow that arithmetic and it makes change orders obvious. Add a contingency for the things that always happen: content arriving late, a third party API being worse than its documentation, two extra review rounds. State the number of revision rounds included, because unlimited revisions is how fixed price work turns into unpaid work. Quote ranges before you have seen the content, firm numbers only after.

The paperwork is short and non-negotiable. A written agreement with scope, exclusions, timeline, payment schedule, revision rounds, a change order process with a stated rate, late payment terms, and an intellectual property clause assigning the work to the client on final payment (not before). A deposit before work starts, commonly a third to a half, and payments tied to milestones rather than to launch, because launch can be delayed by the client for months. Pass-through costs (fonts, plugins, hosting, stock) billed as pass-through or clearly included, never absorbed quietly.

Own the right accounts, and make sure the client owns theirs. The client should hold their own domain registration, their own hosting or platform account, their own analytics, and their own payment processor, with you given access. Reselling hosting in your name looks like easy recurring revenue until you want to stop working with someone and discover you are holding their business hostage, or they are holding you. Document credentials, keep a handover file, and write into the contract what happens at the end of the relationship. The cleanest reputation in this trade belongs to developers who are easy to leave.

Two scope habits that pay for themselves. First, require content before the build starts, or price a content entry phase separately, because missing content is the most common cause of a stalled project and it is almost always the client's side that stalls. Second, separate discovery from delivery and charge for discovery on anything substantial. A paid discovery (audit, requirements, sitemap, integration review, a fixed quote at the end) protects you from scoping for free, and it is also a low-risk first purchase for a client who does not know you yet.

• Stop selling hours. Sell defined scopes, day rates for unpredictable work, and monthly care plans.
• Price in countable deliverables so change orders are obvious arithmetic.
• Deposit before work starts. Milestone payments, not a single payment on launch.
• IP transfers on final payment, in writing.
• The client owns domain, hosting, analytics and payments. You hold access, not ownership.
• Charge for discovery, and require content before the build clock starts.

What to learn, what to be known for, and where the work comes from

Learn in this order, and resist skipping the first item, because it is the one that separates people who can fix anything from people who can only assemble. HTML semantics and accessibility, properly, including what a screen reader does with your markup. CSS as a system: layout with grid and flexbox, the cascade and specificity, container queries, custom properties, and how to structure styles so a stranger can extend them. JavaScript the language, including async behaviour, fetch and error handling, the DOM, and modules, before any framework. Git, including the recovery commands, because the day you need them you will be under pressure. The request lifecycle: DNS, TLS, caching, CDNs, status codes, and the difference between static, server rendered and client rendered pages. Then a framework. Then deployment and the boring operational layer: environments, backups, monitoring, logs, and how a change reaches production.

Pick a platform to be known for. This is the highest return career decision in client web work, because specific beats general in every sales conversation ever held. WordPress still runs more of the world's sites than any other CMS and is where most small business budget lives, including the whole long tail of maintenance and rescue work; modern WordPress work (block themes, custom blocks, ACF, headless) is a different trade from the shortcode era, and plenty of competent developers avoid it, which keeps rates better than its reputation suggests. Shopify is where the money is if you want ecommerce: themes, Liquid, apps, Hydrogen, and merchants who can measure what you did for them. Webflow, Framer, Wix Studio and Squarespace are all genuine businesses for developers who sit at the seam between design and code and add the custom code, integrations and CMS modelling the platforms cannot do alone; their partner directories send real leads. For custom work, Next.js or Astro with a headless CMS (Sanity, Payload, Contentful, Storyblok, or WordPress as a headless backend), and Laravel if you want to be the person who builds the application behind the site rather than the site. Edge platforms (Vercel, Netlify, Cloudflare) are worth knowing because small clients inherit their economics.

Add one scarce specialism on top of the platform, because this is what makes you non-interchangeable: accessibility remediation and audit, technical SEO and migrations, Core Web Vitals and performance, ecommerce conversion and checkout work, integrations with a particular vertical's software (dental practice systems, legal case management, restaurant point of sale, church management, trades scheduling), or multilingual and localisation work. Vertical knowledge beats technical novelty in this market. The developer who has built eleven sites for dental practices and knows which practice management systems have an API wins that twelfth job against anyone, at a better price, with a shorter sales cycle.

If you want a salaried job rather than clients, the channel is not the job board alone. Agency and studio roles are often filled before they are advertised, so build a list of 30 to 50 studios within commuting or remote distance (their client work is usually credited in the footer of sites you admire, and local design award listings and agency directories name the rest), then approach the lead developer directly with one specific, generous observation about something they built and a link to your two strongest case studies. Say you are available for build work as well as a permanent role, because subcontracting is how a lot of agency hires actually start. For in-house roles, search titles beyond web developer: web manager, digital producer, marketing technologist, webmaster, web coordinator, CMS developer, and the various flavours of WordPress, Shopify and Webflow developer. Nonprofits, universities, local government, healthcare groups and trade associations all employ web people and advertise in places a general job board does not reach.

Where client work comes from, in descending order of reliability. People who already know you, told specifically what you do now (vague announcements produce nothing; the message that works names the service and the type of business). Subcontracting to agencies and to other freelancers who are over capacity, which you get by introducing yourself to studios as build capacity rather than as a job applicant. Other professionals who serve the same clients: designers, copywriters, photographers, SEO consultants, fractional marketers, bookkeepers, and the local IT support company who gets asked about websites constantly and has nobody to send them to. Local business networks, chambers and trade associations, which are unfashionable and still work. Platform partner directories once you qualify for them. Speculative audits of named local businesses, sent as a short specific observation rather than a generic pitch. Marketplaces last, as a floor rather than a plan.

Then do the one unglamorous thing that compounds: after every finished project, ask for a referral and a reference at the moment the client is happiest, which is the week after launch and never later. Client web work is a referral trade. Two reliable referrers are worth more than any amount of content marketing.

• Fundamentals first: semantic HTML and accessibility, CSS as a system, JavaScript the language, Git recovery, the request lifecycle. Framework after.
• Be known for one platform: WordPress, Shopify, Webflow or Framer, or custom Next.js and Astro with a headless CMS.
• Add one scarce specialism: accessibility, migrations and technical SEO, performance, checkout, or one industry's software.
• For salaried work, approach 30 to 50 named studios directly and search the in-house title variants (web manager, digital producer, CMS developer, webmaster).
• For client work: people who know you, agency subcontracting, and the professionals who serve the same businesses.
• Ask for the reference and the referral in the week after launch, every time.

What a screen is looking for

These are the terms that a resume screen, human or automated, is matching against for this role. Use the ones that are true of you, in the words the posting uses.

• Web development
• Front-end development
• Full-stack development
• HTML5
• Semantic HTML
• CSS
• CSS Grid
• Flexbox
• Container queries
• Responsive design
• Mobile-first
• Tailwind CSS
• Sass
• JavaScript
• TypeScript
• React
• Next.js
• Astro
• Svelte
• Vue
• Nuxt
• Node.js
• PHP
• Laravel
• REST API
• GraphQL
• Webhooks
• Third-party API integration
• WordPress
• Block themes
• Advanced Custom Fields
• WooCommerce
• Headless CMS
• Sanity
• Payload
• Contentful
• Storyblok
• Shopify
• Liquid
• Shopify Hydrogen
• Shopify Partners
• Webflow
• Framer
• Wix Studio
• Squarespace
• Stripe
• Payment integration
• Ecommerce
• Checkout optimisation
• Site migration
• URL redirects
• Technical SEO
• Schema.org structured data
• Core Web Vitals
• Largest Contentful Paint
• Interaction to Next Paint
• Cumulative Layout Shift
• Lighthouse
• Web performance optimisation
• Image optimisation
• Caching
• CDN
• Cloudflare
• Vercel
• Netlify
• DNS
• SSL
• Web hosting
• WP Engine
• Staging environment
• Git
• GitHub Actions
• CI/CD
• Deployment
• Backups and restore
• Uptime monitoring
• Web accessibility
• WCAG 2.2 AA
• ARIA
• Keyboard navigation
• Screen reader testing
• Accessibility audit
• Cross-browser testing
• Playwright
• Google Analytics 4
• Google Tag Manager
• Cookie consent
• GDPR
• Web application security
• OWASP
• Dependency management
• AI-assisted development
• Code review
• Figma to code
• Design handoff
• Client communication
• Scope and change orders
• Website maintenance retainer
• Technical discovery
• Documentation and handover

Mistakes that cost people this job

Questions people ask