Who does the work
WPPoland is one senior software developer, Mariusz Szatkowski, working on the web and e-commerce side of software: the server code, the integrations between systems and the front ends that sit on top of them. The work has been WordPress-anchored since 2006 and has grown outward from there into WooCommerce, TypeScript and Node.js, headless front ends in Astro and Next.js, and edge code on Cloudflare Workers.
That is a narrower definition than “software developer” in general, and it is deliberate. There is no mobile team here, no design department and no bench of juniors. What you get is the person who writes the code, reads your existing code, and answers for it.
What a web and e-commerce software developer builds
Most requests fall into five kinds of work. They overlap, because real systems do.
- Integrations between systems. A WooCommerce store that has to agree with an ERP, a wholesaler’s price feed, an accounting package or a warehouse. The hard part is rarely the API call; it is deciding which system is the source of truth for stock, prices and order status, and what happens when two of them disagree at two in the morning.
- Headless and edge front ends. Astro or Next.js on top of WordPress or WooCommerce, deployed to Cloudflare Workers or Pages. Worth it when the content model is stable and speed or security matters more than the editor’s visual builder. Not worth it for a brochure site that changes twice a year.
- Store engineering. Checkout logic, payment and shipping integrations, performance work measured against field data rather than a lab score, and the plugin code that holds a store’s business rules.
- Custom WordPress software. Plugins with a real data model, background jobs, REST and WP-CLI interfaces, and admin screens that editors can use without a manual.
- AI and MCP integrations. Connecting a site or store to AI agents in a way that is read-only by default, logged and reversible. The public WooCommerce MCP server described below is an example of that approach.
The stack, and where each part earns its place
A stack is a set of trade-offs, not a badge collection. This is the working set and the reason each part is in it.
| Layer | Tool | Picked when | Not picked when |
|---|---|---|---|
| Server | PHP 8 on WordPress | The system needs editors, users, a plugin ecosystem and cheap hosting | The workload is a long-running service with no content model |
| Commerce | WooCommerce | Catalogue, checkout and order data must stay in your own database | A hosted platform’s limits are acceptable and nobody wants to run servers |
| Scripting and services | TypeScript on Node.js | Integration workers, CLI tools, MCP servers, anything with a typed contract | A ten-line job that WP-CLI already does |
| Data services | Kotlin and Spring Boot | Long-running imports and identity resolution over millions of records, with a queue and typed domain model | The client’s team only maintains PHP |
| Local AI | Ollama via Spring AI | Classification where client data must never leave the premises | A task that plain rules or a lookup table already solve |
| Front end | Astro | Content-heavy pages where most of the page is static | The interface is a dense, stateful application |
| Front end | Next.js | Application-like front ends with a lot of client state | The site is mostly documents |
| Edge | Cloudflare Workers and Pages | Caching, redirects, small APIs and static builds close to the visitor | The job needs a database connection held open for minutes |
| Tooling | Python | Data checks, document analysis, one-off migrations | Anything the client’s team will maintain in PHP |
The language matters less than the boundaries. A good piece of software here is one where you can say which system owns which data, which code runs where, and how to undo last Tuesday’s release.
Public proof you can check before you write
Claims about skill are cheap. These can be verified without a call.
- wppoland/woocommerce-mcp: a read-only Model Context Protocol server for WordPress and WooCommerce, written in TypeScript, MIT licence. It exposes five tools (products, a single product, orders, a sales report and public post search) and nothing that can change the store. Read-only by default is the design decision worth looking at.
- wppoland/hidden-text-detector: a Python tool that finds hidden text and prompt injection in PDF and DOCX files, such as white-on-white text, sub-legible fonts, text placed off the page and invisible Unicode characters. It exists because contracts and requests for quotation now arrive with instructions meant for an AI reader rather than a human one.
- Plogins and the wordpress.org profile motylanogha: Plogins is a WooCommerce extension suite of 45 plugins with free and pro tiers, built on PHP 8.1 with PHPStan, PHPCS and automated releases to wordpress.org and Freemius. 21 plugins in the official directory list the profile (checked on 26 September 2026), including the Polish store compliance plugin Polski (GPSR, Omnibus, GDPR) and the community events plugin GatherPress.
- This website. wppoland.com is an Astro 7 build on Cloudflare Pages with six languages and about 13 600 prerendered pages. Every change passes about fifty automated quality checks before release, from broken links and schema conflicts to a sitemap check that fails when a page marked for indexing is missing from every sitemap. HTML minification was moved onto worker threads in September 2026 and dropped from 910 seconds to 199 seconds on the same 13 610 files, with byte-identical output.
Track record
Twenty years of web work, most of it inside other people’s systems. The roles below are public on LinkedIn; client names inside those engagements stay confidential.
| Period | Role | What it involved |
|---|---|---|
| Since Oct 2025 | Full-stack engineer (contract), WP-Stars, Vienna | A subscription media and commerce platform: a Composer monorepo describing the whole WordPress application, CI with two independent release gates, Stripe subscription flows, and a Kotlin and Spring Boot service consolidating ERP, CleverReach and address data into Mautic, with a local LLM (Ollama via Spring AI) as a constrained classifier running on-premise over millions of records |
| Since Oct 2025 | Co-organiser, CMSConf, Gdynia | A conference about content management systems, organised on site in Gdynia |
| Since Jan 2021 | WordPress, WooCommerce and PHP developer (contract), Equiqo, Berlin | Custom WordPress, WooCommerce, HubSpot and Shopify development on the Roots stack (Bedrock, Sage), performance and structured data work |
| 2020 | WordPress developer, Itineris, Ipswich (UK) | Custom WordPress on Sage and Bedrock, CircleCI, performance and SEO |
| 2019 to 2020 | WordPress developer (freelance), what., Zurich | Custom WordPress, performance and structured data |
| 2016 to 2019 | WordPress developer and team pilot, AirHelp | Multilingual, AMP and performance work on a high-traffic consumer site, liaison between departments |
| 2007 to 2015 | Web developer and internet marketing specialist, Vector Group, Gdynia | Web development, B2B commerce sites and search marketing |
| Since 2007 | WPPoland | The brand under which all independent work runs |
Typical engagements
The client work itself is under NDA, so the case studies are anonymised and say so. Each one describes the problem, the approach and what could and could not be measured.
- A slow WooCommerce store for a B2B seller, recovered by profiling the checkout and the database rather than adding a cache plugin: WooCommerce performance recovery.
- A German-speaking organisation moving from TYPO3 to WordPress without losing its URL structure or its editors’ habits: TYPO3 to WordPress migration.
- A publisher connecting its editorial workflow to AI agents through a controlled MCP server: MCP server for an editorial workflow.
- A headless WooCommerce build on Cloudflare prepared for agent-based shopping: headless WooCommerce on Cloudflare.
- A written migration plan for moving a WordPress site to a headless front end, including the parts that should stay as they are: headless migration plan.
- An AI content operations integration with human review built into every step: AI content operations integration.
For stack-specific detail, the service pages go deeper: WordPress developer, WooCommerce developer, PHP developer, Astro developer, Next.js developer, Cloudflare edge and MCP server development.
Freelancer, agency or software house
The honest answer depends on the size of the problem and on what happens after launch. A single senior developer is not always the right choice.
| Situation | Senior freelancer | Agency | Software house |
|---|---|---|---|
| An integration or rescue with a clear owner on your side | Strong fit: one person holds the whole problem | Often slower to start | Usually too heavy |
| A new product that needs design, front end and back end at once | Only with your own designer | Strong fit | Strong fit |
| Six or more developers needed within a month | Not a fit | Possible | Strong fit |
| Long-term maintenance of a WordPress or WooCommerce system | Strong fit, with a written continuity plan | Strong fit | Rarely their focus |
| A mobile app | Not a fit here | Depends on the agency | Strong fit |
| You need to talk to the person who wrote the code | Always | Sometimes | Rarely |
The real risk with a freelancer is continuity: illness, holidays, or the day they stop answering. Ask for it to be handled in writing. Here that means code in your repository from the first commit, documentation next to the code, credentials held by you, and a handover procedure that another developer could follow.
How to evaluate any software developer
Whoever you hire, these questions separate people who ship from people who present.
- Where does the code live? It should be in your repository, under your organisation, from the first day. A developer who keeps the code until the invoice is paid is holding it hostage.
- How is a change tested before it reaches production? Look for a staging environment, automated checks and a named person who approves releases. “I test it on the live site” is a warning.
- How is a release undone? Ask for the rollback path, not the release path. Anyone can deploy; fewer people have rehearsed going back.
- What was measured before the work started? Performance, error rates and conversion claims mean nothing without a baseline taken the same way.
- What will you not do? A developer with no stated limits either has not thought about them or will discover them on your budget.
- Can I read something you wrote? Public code, a technical article or a design document. Style shows up quickly: whether the author names trade-offs or only benefits.
Working on code someone else wrote
Most engagements start inside an existing system, not on an empty repository. The first week is spent reading, not rewriting.
- Map before touching. Which plugins and services hold business logic, which cron jobs and webhooks run, which data lives outside the database (files, caches, third-party dashboards). The map goes into the repository as a short document.
- Reproduce the problem on a copy. A staging copy with production-like data, anonymised where it holds customer records, so that a fix can be proven before it ships.
- Keep what works. A rewrite is the most expensive way to fix a system and the easiest to recommend. Code that is ugly but correct and covered by a test stays; code that is wrong gets replaced in small, reviewable steps.
- Leave it more readable. Every change comes with the context a stranger would need: why it was made, what was measured and how to undo it.
The same rule applies in reverse. If another developer inherits the work later, they should be able to continue from the documentation in the repository without calling anyone.
Security and the data you hand over
A developer with access to your servers and databases holds real risk, so the handling is agreed in writing before access is granted.
- Credentials stay yours. Access is created per person in your systems and revoked at the end of the engagement; no shared admin passwords sent by email.
- Production data is copied only when needed, kept encrypted on the developer’s machine, anonymised for staging where it holds personal data, and deleted when the work ends. Under the GDPR this is data processing, so a data processing agreement is part of the paperwork, not an afterthought.
- Changes to production are traceable. Every release maps to a commit, and every commit to a reason.
- Incoming documents are checked. Contracts and requests for quotation are scanned for hidden text and prompt injection before anyone, human or AI, acts on them. That is what the hidden-text-detector mentioned above is for.
How an engagement runs
The process is written down so that nobody has to remember it.
- Brief in writing. The system, the problem, the deadline, existing repositories and hosting, and who decides on your side.
- Scope with assumptions. What is included, what is excluded and what has to be true for the estimate to hold. Design, wireframes and content come from the client and are listed as such.
- Baseline. Access, a staging copy and measurements before any change, so that “better” has a number attached.
- Weekly iterations. Commits you can review, a demo on staging every week, and decisions recorded in the repository rather than in a chat thread.
- Release and handover. A rehearsed rollback, documentation and, if your team takes over, a handover session with the person who wrote the code.
Payment terms are part of the written scope, with dates rather than “on completion”. Work starts once the agreed deposit has arrived.
What is not on offer
Being clear about limits saves both sides a month.
- Graphic design, wireframes and UX design. The layout is provided by the client, often as a simple spreadsheet mapping elements to each view. The implementation into a working, responsive interface is the job.
- Native mobile apps. iOS and Android are a different discipline and are better served by a specialist.
- 24/7 on-call support. Monitoring and fast response in working hours, yes; a pager at three in the morning, no.
- Pretending to be a team. One person means one calendar. Large parallel workloads belong with an agency or a software house.
Where the work happens
Gdynia, on the Polish Baltic coast, in Central European Time. Clients are mostly in Poland, Germany, Austria, Switzerland, the Nordics and the rest of the EU, and work is remote with weekly demos. Outside client work, Mariusz has been part of the WordCamp Europe organising team since 2024 on the budget track, for the 2025 edition in Basel and the 2026 edition in Krakow, and co-organises CMSConf in Gdynia.
If the problem you have is a web or e-commerce system that has to work reliably and be understood by the next person who opens it, describe it in writing. A reply with questions or a first scope usually follows within one working day. More background is on the about page.
