English
العربية
Deutsch
EspañolNext.js in Berlin
Next.js development for Berlin teams
A Next.js development company working with Berlin product teams. Two hours of time difference, a market that builds its own product rather than buying one, and the BFSG applying to it.
- Working day overlap
- Seven hours. Berlin is one hour behind Ankara in winter and the same in summer, so a question asked at 10:00 is answered the same morning
- Who buys here
- Product companies with their own engineers, rather than agencies buying delivery
- What that changes
- Your team reviews our pull requests from week one; we do not hand over at the end
- Local specifics
- The BFSG applies, and an Impressum needs a real route with a real canonical
Berlin buys engineering differently from the rest of Germany, and the difference is worth naming before anything technical.
The companies here mostly have their own engineers. They are not looking for a supplier to take a specification away and come back in three months - they want a specific gap closed inside a team that already exists, with their people in the pull requests. That shapes what an engagement looks like far more than anything about the framework.
Seven hours of overlap, which is the whole argument for remote
Berlin is one hour behind Ankara. Our working days overlap almost entirely.
This sounds like a small thing and it is the difference between remote work that functions and remote work that people quietly resent. A question asked at ten in the morning is answered that morning. A review requested before lunch is done before the end of the day. Nobody is waiting overnight for an answer that takes four minutes to give.
Compare it with the alternative that European teams usually have in mind when they say "offshore": six to eight hours of difference, where every exchange costs a day. The engineering is not better at one hour of difference. The project is, because the feedback loop is hours instead of days.
What gets built here
The work that arrives from Berlin clusters: SaaS product surfaces, marketplace front ends, dashboards that outgrew whatever they started as. Rarely brochure sites, which is a different market and a different kind of firm.
What those have in common is that the rendering strategy actually matters. An authenticated dashboard cannot be statically served, a marketplace listing page must be, and most applications that grew quickly have the two tangled together - a use client that crept upward until every page became dynamic and nobody noticed when.
That is the usual first conversation: not what to build, but which routes should render which way and why, which is a decision with a cost attached rather than a preference.
Working inside a team that already exists
Because the buyer here usually has engineers, the engagement shape that works is not the one most agencies sell.
We work in your repository, on your branch policy, through your review process. Your engineers review our pull requests from the first week, not at handover. If that sounds slower, it is - and it is the only version where the code is still maintainable after we leave, because the people who will maintain it have been disagreeing with it the whole time.
The handover at the end is then a formality rather than an event, which is how you want it.
The local obligations are build decisions
Two things apply here that do not everywhere, and both reach the code rather than the copy.
The BFSG made accessibility a shipping requirement, and for an App Router application the failures cluster in focus management on client-side navigation, loading states that announce nothing, and Server Action validation errors that are never associated with their inputs. None of that is alt text.
The Impressum needs a real route with a real canonical, not a modal. It is a content requirement with a routing consequence.
Both are covered properly on the Germany market page, which is where the regulatory ground belongs - repeating it here would make two pages out of one argument.