#What a senior WordPress developer does that a page-builder shop cannot
Most WordPress work in Łódź, as everywhere, is not development. It is assembly: a licensed theme, a page builder, a stack of plugins to paper over the gaps, and a designer arranging it all inside the browser. For a brochure site that is often the right answer, and a good WordPress developer will tell you so rather than sell you a build you do not need. The line gets crossed the moment your requirements stop fitting inside a visual editor: a content model that a page builder cannot express, a WooCommerce checkout that has to talk to KSeF and a warehouse, a media library heavy enough that page weight becomes the problem, or simply code a second developer can open in a year and understand.
That is where a senior WordPress developer earns the title. The work is writing code rather than clicking through settings: custom themes and plugins built to a standard, a data model designed on purpose instead of accreted from whatever plugin was installed that week, integrations that hold up when the third-party API changes, and a review trail so nothing ships that only one person understands. The output is not prettier admin screens. It is a system your team can operate, extend and hand to the next developer without a rescue project.
Łódź has a particular relationship with this distinction, because the city has rebuilt itself around exactly this kind of disciplined work twice over. The textile mills that once defined it are now creative quarters and business-service floors, and the engineering habit that comes with running a shared-services centre for a bank or a global consultancy, code review, testing, documentation, release process, is simply part of how the city operates. Two audiences meet on this page: Western companies looking for a senior WordPress developer in Łódź as nearshore capacity, and Łódź companies that want senior WordPress work carried out in English against international standards. Both are comparing providers on how the work is done, not just on how the mock-up looks.
#Custom themes and plugins, built to WordPress Coding Standards
A custom theme is not a licensed theme with the colours changed. It is a code base authored for your content, and on a new build the sensible default now is a block theme built on the editor APIs: theme.json for the design system, block patterns for the reusable layouts your editors actually use, and block variations where a pattern needs options. The reward is an editing experience that fits how your team writes, without a page builder loaded on every request to make it work.
The theme-versus-plugin boundary is where a lot of inherited Łódź projects have gone wrong, particularly on sites that a marketing team grew organically before anyone thought about maintenance. The rule is plain: if a feature is functional rather than presentational, it belongs in a plugin so it survives a theme switch. Custom post types that outlive the design, REST endpoints, integration logic, admin tools, the invoicing bridge that talks to your accounting system, the connector that syncs stock from a warehouse, all of it lives in a plugin with its own version history. Themes describe presentation and editorial structure and nothing more. When that boundary is respected, a redesign is a redesign; when it is ignored, a redesign becomes a data-recovery exercise because the last agency buried a custom post type and a carrier callback inside functions.php.
WordPress Coding Standards are not a badge, they are what makes a second developer productive on day one, and they matter more when the team is distributed across cities and companies. Consistent formatting, proper escaping and sanitisation on every input and output, nonce verification on forms, internationalised strings so the same code base can serve Polish and English, and PHP that a linter can check in the pipeline. On top of that sits the practice that separates development from assembly: code review on every branch, an architecture decision record for the non-obvious choices, and small reviewable changes with preview links rather than a single monolithic drop at the end. This is not an imported ideal in Łódź; it is the working culture of the city’s business-service floors, and it carries directly into how WordPress gets built here.
#WooCommerce for Polish and cross-border commerce with a logistics lean
Łódź sits at the geographic centre of Poland, where the A1 and A2 motorways cross, and that single fact has turned the city and its surroundings into the country’s main warehousing and distribution corridor. Large logistics parks ring the city, and a great many of the commerce projects that land here are not really catalogue projects, they are fulfilment projects. A Polish WooCommerce store already carries requirements a generic international build ignores; a Łódź one usually adds a warehouse behind the checkout.
KSeF, the national e-invoicing system, is the clearest of the Polish requirements. Structured invoices have to be generated in the correct XML shape and exchanged with the government platform, and a shop that treats invoicing as an afterthought discovers the gap the hard way at go-live. Omnibus is the second: when you show a promotional price, the law requires displaying the lowest price from the prior thirty days, and getting that right in WooCommerce is a data and display problem, not a checkbox. Then there is the delivery and payment texture that Polish shoppers take for granted. InPost parcel lockers are the default fulfilment expectation, not an exotic add-on, and the checkout needs a proper locker selector rather than a plain address field. Payments run through Przelewy24, PayU or BLIK far more than through a bare card form, and each has its own callback and reconciliation behaviour to handle correctly.
The logistics lean is where a Łódź engagement differs from a Kraków or Warsaw one. Because the store often ships from a distribution centre nearby, the interesting code is behind the order: real-time stock synchronisation so the site never sells what the warehouse cannot pick, carrier integrations that print labels and return tracking, shipping rules that split a basket across parcels sensibly, and a data model that keeps orders, stock and invoices consistent through a campaign spike. Cross-border adds the second half: OSS VAT registration and the rate logic that follows, multi-currency and multi-language storefronts, and shipping rules that behave one way inside Poland and another across the EU border, which matters when the goods leave a central-Poland hub aimed at buyers across the continent. Where the shop side of an engagement grows large enough to stand on its own, the WooCommerce developer service covers it in full.
Editorial and commerce WordPress fails in a specific way: it is fine in the demo and falls over when a campaign lands or a story spikes. In Łódź there is a second, local version of the same failure, because the city produces a lot of media-heavy sites, portfolios, film and animation studios, cultural venues, and those fall over on their own weight before traffic is even a factor. A page carrying uncompressed hero video and a gallery of full-resolution stills is slow for one visitor, never mind a thousand.
Performance engineering on WordPress starts with a profiler, not an opinion. On the media side, the first pass is an honest image and video pipeline: modern formats, correct responsive sizes, lazy loading below the fold, and posters instead of autoplaying video where it earns nothing. On the traffic side, Query Monitor and server-side timing show which queries run, how many, and how long they take, and the first move is usually deleting work rather than adding cache: a plugin that runs a query on every request to render something used on one page, a meta query with no index behind it, an autoloaded option that should never have been autoloaded. Once the query count is honest, object caching earns its place, and a page cache in front of anonymous traffic absorbs the spike that a premiere or a viral post creates. On a WooCommerce store the cart and checkout are dynamic and cannot be cached whole, so the work shifts to keeping those paths lean while everything around them is served fast. The last step is a performance budget written into the project so the next editor who uploads a 12-megabyte hero image does not silently undo the work, measured against real user field data rather than a single flattering lab run.
#Security and compliance: GDPR, NIS2 and a code base you can audit
For a growing number of Łódź companies, and for the Western clients they build for, security is no longer a nice-to-have paragraph. In development terms it is concrete and unglamorous: disciplined escaping and sanitisation on every input and output, nonce verification on forms, hardened configuration, least-privilege database and file permissions, dependencies kept current through Composer, and code a reviewer can actually read rather than a plugin pile nobody has looked inside.
GDPR shapes what personal data a plugin stores, how consent is captured on forms and analytics, and how export and erasure requests are served without a manual database dig. NIS2, now transposed into national law across the EU, pulls more mid-sized companies into a formal cybersecurity regime than the old rules did, and it lands with particular force in Łódź because logistics operators and shared-services centres are exactly the kind of connected, supply-chain-adjacent organisations the directive is aimed at. WordPress is rarely the core system in scope, but a public-facing site wired into internal order, stock or CRM systems still needs patch discipline, logging, access control and a documented update path. In a city where a good share of clients are themselves the back-office or security arm of a larger group, this language is familiar and the bar is set accordingly. We build those controls into the handover rather than leave them as a policy document that nobody implemented. The point is not to sell fear; it is that a site put together as assembly cannot pass this bar, and one written as engineering can.
#When headless is the right call, and when it is scope creep
Headless WordPress, keeping WordPress as the editorial back end while a separate front end renders the site, is genuinely the right answer for a slice of projects: an app-like interface, a design system shared with a native application, or a media and publishing operation that wants a static front end sitting in front of a busy editorial back end. When one of those requirements is real, the work is worth doing and we do it, and where a static rebuild is the honest fix for a heavy front end rather than a slow origin, that is the Next.js and Astro migration path, with the broader headless WordPress service covering the architecture in full.
It becomes scope creep when it is chosen for a content site that a well-built block theme would serve at a fraction of the cost and half the ongoing maintenance surface. Headless doubles the number of moving parts, the number of deployments, and the number of things that can break at the seam between the CMS and the front end. Łódź has a real supply of React and Node talent, fed by two large universities and a front-end community with strong creative roots, which cuts both ways: the skills to build headless well are here, but so is the temptation to reach for a framework because the team enjoys it rather than because the project needs it. The recommendation is almost always to sequence: get the WordPress build right first, prove it against real numbers, and only reach for headless when a specific requirement is paying for the extra complexity.
#Three Łódź engagements from the workbench
The names and figures are withheld; the shapes recur, which is why they are worth describing.
The distribution company whose catalogue had outgrown its site. A firm operating out of one of the logistics parks on the edge of Łódź ran a large product catalogue on a WordPress site that had been built as a brochure years earlier and never rebuilt for the volume it now carried. Search was slow, the product data lived half in the page builder and half in a spreadsheet nobody trusted, and every new product line meant a developer copying a template by hand. The work was a proper content model: products and categories as first-class data with a clean import from the company’s own systems, a fast faceted search that could survive thousands of items, and an editorial workflow the internal team could run without touching code. The site stopped being a bottleneck between the warehouse and the buyer.
The film and animation studio with a media problem, not a design problem. A Łódź creative studio, the kind that grows out of the city’s long film and animation tradition, had a portfolio site that looked right and performed badly, because it was carrying showreels, high-resolution stills and case-study galleries with no real media pipeline behind them. The brief was not a redesign, the design was fine; it was engineering. We built a media handling layer that transcoded and sized video properly, served modern image formats at the right dimensions, and lazy-loaded the heavy assets so the first view was fast, then wrapped it in a block theme the studio’s own people could publish new work into. The portfolio kept its look and stopped losing visitors on the first scroll.
The commerce build that leaned on the warehouse corridor. A direct-to-consumer brand fulfilling orders from a central-Poland distribution centre needed a WooCommerce store that treated the warehouse as the source of truth, not an afterthought. The visible shop was the easy half. The real work was behind it: stock synchronisation so the site never oversold, a carrier integration for parcel-locker and courier delivery with labels and tracking, KSeF invoicing wired into the order flow, and shipping logic that split baskets and priced delivery correctly for domestic and cross-border orders. It shipped built to standards the brand’s own reviewer could sign off, and the operations team got a store that stayed consistent with the warehouse through a seasonal surge.
#The Łódź context: textile heritage, film school, shared services and the logistics corridor
Łódź is a city that has reinvented itself more than once, and each reinvention left a talent pool behind. The textile industry that built it is gone, but the mills themselves became something else: Manufaktura, a former factory complex turned cultural and commercial quarter, and the OFF Piotrkowska creative hub off the city’s iconic main street are the visible face of a wider shift into creative industries. That shift rests on a genuine heritage. The Łódź Film School has trained generations of directors, cinematographers and animators, and the city’s animation tradition, from the Se-ma-for studio behind internationally awarded shorts to the newer EC1 film-culture centre, keeps a strong seam of visual, media and front-end talent in the city. It is why so many of the WordPress projects here are media-heavy and design-led.
The second reinvention is economic and quieter. Łódź has become one of Poland’s biggest business-service and shared-services locations, with delivery centres for companies such as Accenture, Infosys and Fujitsu and a large technology operation anchored by mBank, whose headquarters sit in the city. English is the working language of those floors, and the disciplines they run on, review, documentation, release management, are the same ones good WordPress work depends on. Underneath both stories is the geography: sitting where the A1 and A2 motorways meet, at the centre of the country, Łódź and its surroundings have become the natural warehousing corridor for goods moving across Poland and the EU, which is why commerce work here so often turns into logistics work. The two large universities, the Łódź University of Technology and the University of Łódź, keep the pool topped up, and a lower cost base than Warsaw or Kraków is a genuine draw for clients without being the reason to choose the city. None of these buyers, creative studios, distribution operators, shared-services centres, is well served by a page builder and a plugin pile, which is precisely why senior WordPress development has a market here.
#When you do not need a dedicated WordPress developer
The section most agency pages leave out. If your site is a handful of pages, your content changes rarely, and you have no integrations or performance pressure, you do not need a dedicated WordPress developer and hiring one is money spent on capability you will never use. A reputable theme, a small number of well-chosen plugins and a designer who keeps it tidy will serve you, and a good developer will point you there rather than invent a build. The same applies when your real problem is content or marketing rather than code: no amount of custom development fixes a site that nobody visits.
There is a second, quieter case for declining. Custom code is a commitment, because a bespoke plugin needs an owner and a maintenance path. If a project cannot fund its own upkeep, an orphaned custom plugin that nobody understands is worse than the off-the-shelf one it replaced. The honest trigger for dedicated development is a genuine mismatch between what you need and what assembly can deliver: a content model that does not fit, a WooCommerce integration with KSeF or a warehouse that has to be built correctly, a media operation heavy enough that performance becomes engineering, a multilingual publishing operation that has to stay consistent across languages, or an inherited code base that needs rescuing. Where none of those is present, the recommendation is to save the budget.
#How the nearshore engagement works
We are a Łódź-based team and we build for Western European and US clients remotely, both directly and as white-label overflow for agencies, working in English. The mechanics are unremarkable, which is the point: standard B2B contracts, cross-border invoicing as a Polish company inside the EU single market with reverse-charge VAT handled the normal way, and everything shipped through version-controlled pipelines you can inspect. Central European Time is the quiet advantage; the working day overlaps UK and continental office hours completely and reaches into US morning hours, so reviews, standups and releases happen inside your day rather than overnight.
The way in is deliberately small: a codebase audit and a written scope that separates real requirements from the wish list, followed by staged delivery where the first reviewed branch is also the first point at which you can judge the work and decide how much further to go. Pricing is individual and tied to the scope the audit justifies, not to your company size or location. The exit is built in from the start, with living documentation and a handover session, so whether the project moves to your own developers, stays with an agency, or continues on an optional maintenance retainer, you own the result rather than depending on us to read our own code. If a broader engineering brief emerges from the audit, the WooCommerce developer service covers shop work in depth, and the headless WordPress service covers the front-end architecture when a specific requirement justifies it.
Last updated: 12 July 2026