WordPress development for Wrocław companies, done remotely
I am Mariusz Szatkowski and I have built WordPress sites since 2006. Companies in Wrocław and the rest of Lower Silesia hire me for the technical work their own people have no time for: themes built from their design, plugins, WooCommerce stores that sell into Poland and Germany, performance work and maintenance. I work alone from Gdynia, so the code you receive is code I wrote, and nobody else sees your access details.
You bring the wireframes and graphic design, as a Figma file or as a filled-in template where you mark which element goes where on each view. I turn that into a responsive WordPress theme.
Who I am
WPPoland is the name I work under as a WordPress developer. One senior developer, no agency layer, no account managers, no subcontractors. If you were looking for a WordPress freelancer, that is what this is.
What I build
Websites from your design
A block theme built from the layout you supply, with patterns for the content types your editors actually publish.
WooCommerce stores
Payments, delivery and VAT set up for the countries you sell to, with a checkout that stays fast during a campaign.
Plugins
Custom code only where no maintained plugin covers the job: integrations, REST endpoints, admin tools.
Care for running sites
Monitoring, backups in the EU and updates tested on staging, under an Art. 28 GDPR agreement.
A custom theme here means code written for your content, not a licensed theme with new colours. Anything functional (custom post types, integrations, an invoicing bridge) goes into a plugin, so it survives the next redesign. Every theme and plugin follows the WordPress Coding Standards and is checked by PHP_CodeSniffer in the pipeline, which lets your own developers, or the next freelancer, pick it up without a rescue project.
Who this fits, and who should not hire me
It fits a company in Wrocław or Lower Silesia that has marketing and content in house and needs someone to write the code: a manufacturer whose site has to work in Polish, German and often Czech, a shop that sells across the border into Saxony, a business-services firm whose old CMS no longer gets security updates, an engineering team that wants WordPress as a content service behind its own frontend.
It does not fit if your site is a handful of pages that rarely change and has no integrations. A well-maintained ready-made theme and a few chosen plugins will serve you, and paying a developer for custom code you will never need is wasted money. The same goes when the real problem is content or marketing: code does not bring visitors to a site nobody searches for.
Custom code is also a commitment. A bespoke plugin needs an owner and a maintenance budget, and an orphaned plugin nobody understands is worse than the off-the-shelf one it replaced. I suggest custom work when what you need and what assembly can give really diverge: a content model that does not fit, an integration that has to be correct, a performance target a page builder cannot reach, or inherited code that needs saving.
Selling from Lower Silesia into Germany with WooCommerce
Lower Silesia borders both Germany and the Czech Republic, and a store selling across those borders has to handle two tax and payment cultures at once. In practice that means:
- Languages: WPML or Polylang with clean language relationships, so the German catalogue is a real translation and not a set of orphaned pages.
- VAT: USt-ID validation at checkout for German business buyers, reverse charge on B2B invoices, and OSS handling for cross-border sales to consumers in the EU.
- Payments: Przelewy24 or BLIK for Polish shoppers, and a provider German buyers trust, such as Mollie or PayPal. Each has its own callbacks and reconciliation, which I test against the provider’s sandbox before launch.
- Delivery: InPost parcel lockers with a proper locker picker on the Polish side, DHL or another carrier with a working API on the German side.
When the shop side grows large enough to be a project of its own, the WooCommerce developer page covers it in full.
Migrating an old CMS to WordPress
Older Drupal installs and proprietary CMSs are common on corporate sites, and their security updates get harder to come by every year. On a migration the WordPress build is rarely the slow part. The slow parts are the content audit, the redirect map from every old URL to its new address, and teaching editors who have never used the block editor. I script the export and import so that legacy content lands in clean custom post types and fields, carry over canonical tags and structured data, and check the redirects against the old sitemap before the switch.
Headless WordPress, when it pays
Headless means WordPress as the editorial back end and a separate frontend, usually React or Next.js, rendering the site. It pays when a frontend team already exists and will maintain it: an app-like interface, a design system shared with a native app, an internal portal behind single sign-on. Then I build the WordPress side (REST or WPGraphQL endpoints, blocks exposed as JSON, preview that works with your staging) and stay out of the React code.
For a content site it adds cost without benefit. It doubles the moving parts and the deployments, and the seam between CMS and frontend tends to break in predictable places, such as previews after a token rotation or forms that lose their consent record. The headless WordPress service and the Next.js and Astro migration page cover the architecture in more detail.
Performance under real traffic
A WordPress site that is fast in the demo and slow during a campaign almost always has the same causes: uncached database queries that multiply under load, plugins loaded on every request whether the page needs them or not, and an options table full of autoloaded data. I start with Query Monitor and server timings, and the first pass usually removes work instead of adding cache. Once the query count is reasonable, object cache and page cache do their job. Cart and checkout cannot be cached whole, so on a WooCommerce store those paths get the most attention. At the end a performance budget goes into the project, measured on field data from real visitors, so the next plugin install does not quietly undo the work.
Security, GDPR and maintenance
Security in the code is unglamorous: escaping and sanitising every input and output, nonces on forms, least-privilege database and file permissions, dependencies updated through Composer, and code a reviewer can read. GDPR decides what personal data a plugin stores, how consent is collected for forms and analytics, and how access and erasure requests are handled without someone digging through the database by hand.
Maintenance covers uptime checks every 1 to 5 minutes, backups kept at least 30 days in EU countries, and updates tested on staging before they reach production. Before I get access to a site with personal data, you and I sign a processing agreement under Art. 28 GDPR. I use no sub-processors of my own. I do not run hosting: you choose the provider and I work with the stack you have. There is no 24/7 on-call service and no guaranteed response time.
Contracts, invoices and communication
- Contract: a B2B contract under Polish law with your company, with a confidentiality agreement and an Art. 28 GDPR agreement where needed.
- Invoice: issued with my EU VAT ID PL7393037445; for business clients in other EU countries under reverse charge.
- Communication: in writing, by email, in shared documents and in the repository. If you need a call, ask for one.
- Acceptance: every change goes to staging first, with a written note on what changed. Production is updated only after your sign-off.
How a project runs
- Brief: you describe what should be built or changed, what the site runs on today and who will edit it.
- Questions in writing: I check the existing site and ask about scope, languages, hosting and your design.
- Proposal: scope, assumptions and schedule are written down before any code exists.
- Build: the code lives in a private Git repository, each push lands on staging, and you review there.
- Launch: before go-live I run Lighthouse and axe-core checks and test by hand in current Firefox, Chrome, Safari and Edge, plus mobile Safari and Chrome on Android.
Send your brief through the contact form. You get the next steps in writing and a proposal that lists the assumptions it rests on.
WordPress development in other Polish cities
If you are comparing Polish cities before choosing someone, see WordPress developer in Warsaw and WordPress developer in Gdansk. The developer is the same on every page: Gdynia, where I work, is part of the Tricity with Gdansk.
