Support & Bugfixes

Most websites and web apps don't fail all at once. They accumulate a small backlog instead: a form that breaks on one browser, a dependency that's two major versions behind, a feature that half-shipped before the person who started it left. None of it is an emergency by itself, and none of it gets fixed, because there's no one whose job it is to look. This is that job — bugfixing and ongoing support for a project that's already live, whether or not I'm the one who built it.

Sound familiar?

• A bug report has been sitting open for weeks because nobody has time to look at it.
• The developer who built the site is gone, unresponsive, or was never full-time to begin with.
• Small requests — "can we change this," "this looks broken on mobile" — pile up faster than anyone gets to them.
• A dependency update has been avoided because nobody's sure what it'll break.
• Something worked yesterday and doesn't today, and nobody's changed anything on purpose.
• You have a developer or team, but they're underwater and a second pair of hands on the frontend would actually help.

None of this needs a rebuild. It needs someone to read the code, fix what's broken, and stay reachable for what comes up next.

Who this is for

A good fit if:

• There's a live website or web app already — built here or somewhere else — with a real backlog of bugs, small fixes, or maintenance that keeps getting pushed.
• The previous developer or agency is gone, slow, or otherwise not a reliable point of contact anymore.
• You want a direct line to whoever's actually doing the fix, not a ticket queue.
• The work is genuinely ongoing — not a single afternoon's job, but not a full rebuild either.

Probably not a fit if:

• Nothing exists yet — web development or MVP development is the right starting point for a new build.
• The scope is a mystery even to you — something feels wrong but nobody can say what — that's exactly what the Frontend Technical Audit is built to answer first.
• The site was built here on a package that already includes Monthly Care — that's covered under the €79/month Support add-on instead of a separate engagement.
• The problem is purely backend infrastructure, hosting, or DevOps with no frontend component at all.

What's covered

• Bug triage and fixes. Something's broken — a form, a layout, a piece of logic that stopped working after a browser or dependency update — and it needs a fix, not just a diagnosis.
• Small features and changes. Additions too small to be their own project: a new field, a tweaked flow, a section that needs to work differently than it does today.
• Dependency and framework updates. Keeping React, Next.js, and the packages around them current, so an update doesn't turn into a multi-day fire drill six versions later.
• Taking over an unfamiliar codebase. Reading what's there, understanding the patterns already in use, and working inside them instead of introducing a second, inconsistent way of doing things.
• Monitoring and early warning. Catching a regression, a broken build, or a performance drop before a customer reports it instead of after.
• Being reachable. A direct line to the person doing the work, with a response time that's agreed upfront instead of assumed.

How it works

1. Short call. What's broken, what's been tried already, and roughly how big the backlog is — enough to tell whether this is a single fix, a retainer, or an audit first.
2. First look. For anything beyond a trivial fix, I read the actual code before quoting anything — the same discipline as the audit, just scoped to what's already known to be broken.
3. Fix or retainer agreed. A single defined bug gets a fixed price. Ongoing work gets a monthly retainer with a defined scope and response time, confirmed before anything is billed.
4. Work ships incrementally. Fixes and changes go out as they're done, with a preview before anything goes live — not batched into one unreviewable release.
5. Stay or step away. A retainer runs month to month with no lock-in. If the backlog gets cleared and there's nothing ongoing left, that's a fine place to stop.

Pricing, honestly

The same rule applies here as everywhere else on this site: fixed price where the scope allows it, and a clear explanation when it genuinely can't be fixed upfront.

• A known bug — reproducible, scoped, understood — gets a fixed price once I've actually looked at the code, not before.
• Ongoing support runs as a monthly retainer: a defined number of hours and a defined response time, scoped after the first look at the codebase, not a number picked before anyone's read it.
• Anything that turns out bigger than expected — during the first look, or partway through — gets flagged before it's built, not invoiced afterward as a surprise.

Why Nordbüro

• The person triaging the bug is the same person fixing it — no handoff between a support desk, a project manager, and whoever actually touches the code.
• Working inside an existing, unfamiliar codebase is routine here, not an exception — real engagements regularly start with someone else's code, not a blank repo.
• A response time that's committed to upfront, from a studio small enough that the commitment is real.
• No incentive to stretch a small fix into a bigger retainer than the situation actually needs.

This is a small, senior-only studio — a solid fit for a defined backlog or a genuine ongoing need, not a substitute for a full in-house team on a large, fast-moving product.

---

Have a live site or app with something that needs fixing, or a backlog that's stopped moving? Get in touch and describe what's going on — if it's a quick fix rather than an ongoing engagement, I'll say that instead of proposing more.