Working with a In-House Web Developer

What this role actually does

Depending on the org shape, the developer also inherits the tracking implementation for every campaign that runs. UTM discipline, event naming conventions, and consent management all sit under the developer even when marketing operations formally owns the reporting. A developer who ignores tracking implementation lets marketing operations report numbers finance will not defend.

The In House Web Developer builds and maintains the marketing site, the landing pages, the microsites, and the front end of any lead capture flow. The seat sits under the head of marketing operations, the head of demand, or the head of brand depending on how central the site is to the business. Most weeks the developer is shipping landing pages, fixing broken tracking, testing performance, and coordinating with design and copy on new work.

A working web developer spends real hours with the designer on layouts and components, real hours with the copywriter on final content, real hours with marketing operations on tracking and analytics, and real hours with SEO or LSO on structure, schema, and performance. The seat carries the CMS, the front end framework, the marketing site repo, and often the A B testing platform.

The developer owns page ship velocity, site performance, tracking accuracy, and the component library that lets non developers ship pages inside the CMS. In many orgs the developer also owns the personalization layer and the integration with the CDP.

What a functioning web developer does not do: own product engineering, take on backend infrastructure outside the marketing stack, or build one off features for every sales request. They do not own product roadmap decisions. They own the marketing web surface. A developer who is being pulled into product features has a scope problem the manager has to fix.

The developer also owns the discipline of the release protocol. Ship reviews, staging QA, and rollback plans keep the marketing site alive during high traffic moments. A developer who skips the protocol on a small change is one deploy from a site outage during a launch.

The web developer's week is shaped by the marketing calendar. Launches, campaigns, and event pages arrive in bursts. A developer who cannot smooth the burst pattern with a template layer ends up in crunch every quarter.

How to brief them well

You brief a web developer on the page, the tracking, the performance target, and the launch date. Here is the design. Here is the tracking spec. Here is the performance budget. Here is the deadline. The developer comes back inside a defined build window with a shipped page.

Bad briefs look like a design without a spec. Please build this landing page. Please launch this microsite. Please update the pricing page. Every ask without tracking and performance requirements produces a page that ships and then breaks in analytics or fails on core web vitals.

Context the developer needs on arrival includes the current tech stack, the CMS, the component library, the tracking model, the SEO or LSO spec, and the release protocol. A developer who does not know the release protocol is going to push straight to production and break something.

The strongest brief pairs a page with a hard spec. Landing page for the mid market product. LCP under two seconds. Tracking events for hero click, form start, form submit. Ship in five business days. Do not accept scope additions after the design is signed off. Named nos protect the ship date from every stakeholder who wants a change on day four.

The strong brief also names the tracking events the page will not fire. Over instrumenting a page produces analytics noise and slows performance. Naming the events to skip is the discipline that keeps tracking clean.

The brief also names the browser and device support matrix. A page tested only on desktop Chrome ships bugs on mobile Safari that show up in the next analytics review. Named support in the brief prevents the QA argument later.

Review cadence + operating rhythm

Weekly at the web developer level is a busy calendar. A Monday standup with the marketing team on pages in flight. Development work throughout the week. A Wednesday review with the design and copy team on staging builds. A Friday deploy window on tested changes. Numbers reviewed weekly are ship pace, staging bug count, and site performance.

Monthly is the operating review. Page ship velocity, performance metrics across the site, tracking accuracy against the model, and technical debt items in the backlog. The developer walks in with a list of refactors that will save future ship time and asks the manager to prioritize.

Quarterly is the site health review. Performance across the site, SEO or LSO structure, accessibility audit, and CMS technical debt. This is where major rebuilds get planned and where the team decides which parts of the site to sunset.

Annual planning at the web developer level includes a stack decision and a career track. Which CMS to invest in, which testing platform to adopt, and which parts of the site to rebuild. Career path: senior developer, tech lead, engineering manager, or a move into product engineering.

Between the standing cadences the developer also runs a weekly performance regression check on the top ten pages. Core web vitals regress silently when third party scripts change or when new content lands. A weekly check catches the regression before organic traffic reacts.

Weekly the developer also runs a dependency audit on the frontend build. Package updates, security advisories, and deprecated APIs. A developer who does not audit dependencies ends up fighting a critical security patch during a launch week.

Measurement (real KPIs, not vanity)

Four numbers matter at the in house web developer level.

First, page ship velocity. Pages shipped per month against the plan. When velocity drops, either the backlog is unclear or the component library is decaying. Both are the developer's job to raise.

Second, core web vitals across the site. LCP, INP, and CLS on the pages the developer owns. This is the number that ties web development to organic performance.

Third, tracking accuracy. Percentage of events firing correctly across the site. Below ninety five percent breaks marketing reporting. The developer partners with marketing ops to keep this above threshold.

Fourth, uptime and incidents. Site downtime in the last quarter and incidents that required rollback. A healthy operation runs at four nines or better.

Vanity metrics that mislead include lines of code written, commits per week, and CMS entry count. A developer who reports commits is measuring effort.

The diagnostic layer under core web vitals is the third party script inventory. Every marketing tool that lands on the site adds a script. When performance drops, the diagnosis usually starts with the newest script. The developer who owns the script inventory diagnoses regressions in an hour rather than a day.

Underneath core web vitals, the developer watches third party script weight. Every tag, tracker, and widget adds cost. The developer who cannot say no to the marketing ops request for another tag lets the site slow down one script at a time.

Compensation + career path (honest ranges)

In House Web Developer comp splits by seniority and market.

Junior

Junior. Zero to three years experience. Base 75 to 100 thousand. Bonus 5 to 10 percent. Total cash 80 to 115 thousand.

Mid level

Mid level. Three to six years. Base 100 to 140 thousand. Bonus 8 to 15 percent. Total cash 115 to 165 thousand.

Senior

Senior. Six to ten years. Base 140 to 190 thousand. Bonus 10 to 20 percent. Equity 0.03 to 0.10 percent at earlier stage. Total cash 160 to 230 thousand.

Lead or principal

Lead or principal. Ten years and up. Base 180 to 240 thousand. Bonus 12 to 22 percent. Total cash 205 to 295 thousand.

Coastal enterprise adds twenty to thirty percent. Contract rates range from one hundred twenty to three hundred dollars an hour depending on stack. The typical next step is senior developer, tech lead, engineering manager, or a move into product engineering. A healthy tenure in one company is two to four years.

The negotiation moment for a web developer is whether the seat sits in engineering or in marketing. Reporting into engineering gives access to code review standards and infrastructure. Reporting into marketing gives control of the roadmap. The offer that leaves the line unclear produces a developer who spends the year negotiating for scope.

The offer for an in house developer should name access to production. A developer who cannot deploy on their own schedule is a developer who is going to feel like a contractor with a badge. Deploy access matters more than a small increase in base.

Common ways this seat fails

The seat also fails when the developer cannot handle the launch that requires a change on Friday afternoon. Every marketing operation has moments where a page needs to ship before a Monday event. The developer who cannot accommodate the compressed launch cycle without breaking the site loses political room for the code quality argument during normal weeks.

The developer who over engineers the marketing site. Every page becomes a custom build. Every component becomes bespoke. The component library never lands. Ship velocity drops. Marketing goes back to freelancers.

The developer who ignores performance. LCP creeps up. Bounce rate follows. Organic traffic declines. The developer who does not run a performance budget on every ship loses the SEO or LSO argument every quarter.

The developer who cannot align with marketing operations. Tracking breaks. Attribution goes bad. Marketing reports lose credibility. The developer who does not partner with the ops team on tracking QA lets the plumbing rot.

The developer who cannot say no to product engineering. Product engineering asks the marketing developer to help with a product feature. The web developer says yes and the marketing site stops shipping. The developer who does not defend the scope of the marketing web loses the marketing site to the product roadmap.

The developer who cannot document. Every page has a custom hack. Nobody else can maintain the site. When the developer leaves, the site becomes unmaintainable. A developer who does not document is a single point of failure.

The seat also fails when the developer cannot say no to marketing on scope creep during a build. Every landing page has a moment where marketing adds a section on day four of a five day build. The developer who accepts the addition without renegotiating the deadline ships late and loses trust.

The seat also fails when the developer cannot document the pages the marketing team maintains inside the CMS. A CMS with fifty pages and no documentation becomes a liability the day the developer leaves.