Quién hace el trabajo
WPPoland es un único desarrollador de software sénior, Mariusz Szatkowski, que trabaja en la parte web y e-commerce del software: el código de servidor, las integraciones entre sistemas y los front ends que se apoyan en ellos. Desde 2006 el trabajo gira en torno a WordPress y a partir de ahí se ha ido ampliando hacia WooCommerce, TypeScript y Node.js, front ends headless en Astro y Next.js, y código en el edge con Cloudflare Workers.
Es una definición más estrecha que la de “desarrollador de software” en general, y lo es a propósito. Aquí no hay un equipo de móvil, ni departamento de diseño, ni una cantera de juniors. Lo que obtiene es a la persona que escribe el código, lee el código que ya tiene y responde de él.
Qué construye un desarrollador de software web y e-commerce
La mayoría de los encargos encajan en cinco tipos de trabajo. Se solapan, porque los sistemas reales también lo hacen.
- Integraciones entre sistemas. Una tienda WooCommerce que tiene que cuadrar con un ERP, la tarifa de un mayorista, un programa de contabilidad o un almacén. Lo difícil casi nunca es la llamada a la API; es decidir qué sistema manda sobre el stock, los precios y el estado de los pedidos, y qué pasa cuando dos de ellos no coinciden a las dos de la madrugada.
- Front ends headless y en el edge. Astro o Next.js sobre WordPress o WooCommerce, desplegados en Cloudflare Workers o Pages. Compensa cuando el modelo de contenido es estable y la velocidad o la seguridad pesan más que el constructor visual del editor. No compensa para una web corporativa que cambia dos veces al año.
- Ingeniería de tiendas. Lógica del checkout, integraciones de pago y envío (en España suelen ser pasarelas como Redsys o Bizum), trabajo de rendimiento medido con datos de campo y no con una puntuación de laboratorio, y el código de plugins que contiene las reglas de negocio de la tienda.
- Software a medida para WordPress. Plugins con un modelo de datos real, tareas en segundo plano, interfaces REST y WP-CLI, y pantallas de administración que los editores pueden usar sin manual.
- Integraciones de IA y MCP. Conectar una web o una tienda con agentes de IA de forma que por defecto sea de solo lectura, quede registrada y se pueda revertir. El servidor MCP público para WooCommerce que se describe más abajo es un ejemplo de ese enfoque.
El stack, y dónde se gana su sitio cada pieza
Un stack es un conjunto de compromisos, no una colección de insignias. Este es el conjunto de trabajo y el motivo por el que está cada pieza.
| Capa | Herramienta | Se elige cuando | No se elige cuando |
|---|---|---|---|
| Servidor | PHP 8 sobre WordPress | El sistema necesita editores, usuarios, un ecosistema de plugins y alojamiento barato | La carga es un servicio de larga duración sin modelo de contenido |
| Comercio | WooCommerce | El catálogo, el checkout y los datos de pedidos deben quedarse en su propia base de datos | Los límites de una plataforma alojada son aceptables y nadie quiere gestionar servidores |
| Scripts y servicios | TypeScript sobre Node.js | Workers de integración, herramientas CLI, servidores MCP, cualquier cosa con un contrato tipado | Una tarea de diez líneas que WP-CLI ya resuelve |
| Servicios de datos | Kotlin y Spring Boot | Importaciones de larga duración y resolución de identidades sobre millones de registros, con una cola y un modelo de dominio tipado | El equipo del cliente solo mantiene PHP |
| IA local | Ollama mediante Spring AI | Clasificación en la que los datos del cliente nunca deben salir de sus instalaciones | Una tarea que ya resuelven unas reglas simples o una tabla de consulta |
| Front end | Astro | Páginas con mucho contenido en las que casi todo es estático | La interfaz es una aplicación densa y con mucho estado |
| Front end | Next.js | Front ends tipo aplicación con mucho estado en el cliente | La web son sobre todo documentos |
| Edge | Cloudflare Workers y Pages | Caché, redirecciones, APIs pequeñas y builds estáticos cerca del visitante | La tarea necesita una conexión a base de datos abierta durante minutos |
| Herramientas | Python | Comprobaciones de datos, análisis de documentos, migraciones puntuales | Cualquier cosa que el equipo del cliente vaya a mantener en PHP |
El lenguaje importa menos que los límites. Aquí, un buen software es aquel en el que se puede decir qué sistema es dueño de qué datos, qué código se ejecuta dónde y cómo deshacer la publicación del martes pasado.
Pruebas públicas que puede comprobar antes de escribir
Hablar de habilidades sale barato. Esto se puede verificar sin una llamada.
- wppoland/woocommerce-mcp: un servidor Model Context Protocol de solo lectura para WordPress y WooCommerce, escrito en TypeScript, con licencia MIT. Expone cinco herramientas (productos, un producto concreto, pedidos, un informe de ventas y la búsqueda de entradas públicas) y nada que pueda modificar la tienda. La decisión de diseño que merece la pena mirar es que sea de solo lectura por defecto.
- wppoland/hidden-text-detector: una herramienta en Python que detecta texto oculto e inyección de prompts en archivos PDF y DOCX, como texto blanco sobre blanco, fuentes demasiado pequeñas para leerse, texto colocado fuera de la página y caracteres Unicode invisibles. Existe porque los contratos y las solicitudes de oferta llegan ya con instrucciones pensadas para un lector de IA y no para una persona.
- Plogins y el perfil motylanogha en wordpress.org: Plogins es una suite de 45 extensiones para WooCommerce con versión gratuita y versión pro, desarrollada en PHP 8.1 con PHPStan, PHPCS y publicaciones automáticas en wordpress.org y Freemius. 21 plugins del directorio oficial incluyen este perfil (comprobado el 26 de septiembre de 2026), entre ellos Polski, el plugin de localización de tiendas para el mercado polaco (GPSR, Omnibus, RGPD), y GatherPress, el plugin comunitario de eventos.
- Esta web. wppoland.com es un build de Astro 7 en Cloudflare Pages con seis idiomas y unas 13 600 páginas prerenderizadas. Cada cambio pasa unas cincuenta comprobaciones de calidad automáticas antes de publicarse, desde enlaces rotos y conflictos de schema hasta una comprobación de sitemaps que falla cuando una página marcada para indexar no aparece en ningún sitemap. La minificación del HTML se pasó a worker threads en septiembre de 2026 y bajó de 910 segundos a 199 segundos con los mismos 13 610 archivos, con una salida idéntica byte a byte.
Trayectoria profesional
Veinte años de trabajo web, la mayor parte dentro de sistemas ajenos. Los puestos siguientes son públicos en LinkedIn; los nombres de los clientes dentro de esos encargos se mantienen confidenciales.
| Periodo | Puesto | En qué consistió |
|---|---|---|
| Desde oct. 2025 | Ingeniero full-stack (por contrato), WP-Stars, Viena | Una plataforma de medios y comercio por suscripción: un monorepo de Composer que describe toda la aplicación WordPress, CI con dos controles de publicación independientes, flujos de suscripción con Stripe y un servicio en Kotlin y Spring Boot que consolida datos de ERP, CleverReach y direcciones en Mautic, con un LLM local (Ollama mediante Spring AI) como clasificador acotado que se ejecuta on-premise sobre millones de registros |
| Desde oct. 2025 | Coorganizador, CMSConf, Gdynia | Una conferencia sobre sistemas de gestión de contenidos, organizada presencialmente en Gdynia |
| Desde ene. 2021 | Desarrollador WordPress, WooCommerce y PHP (por contrato), Equiqo, Berlín | Desarrollo a medida en WordPress, WooCommerce, HubSpot y Shopify con el stack Roots (Bedrock, Sage), trabajo de rendimiento y datos estructurados |
| 2020 | Desarrollador WordPress, Itineris, Ipswich (Reino Unido) | WordPress a medida con Sage y Bedrock, CircleCI, rendimiento y SEO |
| 2019 a 2020 | Desarrollador WordPress (freelance), what., Zúrich | WordPress a medida, rendimiento y datos estructurados |
| 2016 a 2019 | Desarrollador WordPress y piloto de equipo, AirHelp | Trabajo multilingüe, AMP y de rendimiento en un sitio de consumo con mucho tráfico, enlace entre departamentos |
| 2007 a 2015 | Desarrollador web y especialista en marketing online, Vector Group, Gdynia | Desarrollo web, sitios de comercio B2B y marketing en buscadores |
| Desde 2007 | WPPoland | La marca bajo la que se desarrolla todo el trabajo independiente |
Proyectos típicos
El trabajo para clientes está bajo NDA, así que los casos de estudio están anonimizados y lo dicen. Cada uno describe el problema, el enfoque y qué se pudo medir y qué no.
- Una tienda WooCommerce lenta de un vendedor B2B, recuperada perfilando el checkout y la base de datos en lugar de añadir un plugin de caché: recuperación del rendimiento de WooCommerce.
- Una organización de habla alemana que pasa de TYPO3 a WordPress sin perder su estructura de URLs ni las costumbres de sus editores.
- Un editor que conecta su flujo editorial con agentes de IA a través de un servidor MCP controlado.
- Un WooCommerce headless sobre Cloudflare preparado para las compras mediante agentes.
- Un plan de migración por escrito para llevar una web WordPress a un front end headless, incluidas las partes que conviene dejar como están.
- Una integración de IA en las operaciones de contenido con revisión humana en cada paso.
Para el detalle de cada tecnología, las páginas de servicio profundizan más: desarrollador WordPress, desarrollador WooCommerce, desarrollador PHP, desarrollador Astro, desarrollador Next.js, Cloudflare edge y desarrollo de servidores MCP.
Freelance, agencia o software house
La respuesta honesta depende del tamaño del problema y de lo que ocurra después del lanzamiento. Un único desarrollador sénior no siempre es la opción correcta.
| Situación | Freelance sénior | Agencia | Software house |
|---|---|---|---|
| Una integración o un rescate con un responsable claro por su parte | Encaja muy bien: una persona abarca todo el problema | Suele tardar más en arrancar | Normalmente demasiado pesada |
| Un producto nuevo que necesita diseño, front end y back end a la vez | Solo con su propio diseñador | Encaja muy bien | Encaja muy bien |
| Seis o más desarrolladores necesarios en un mes | No encaja | Posible | Encaja muy bien |
| Mantenimiento a largo plazo de un sistema WordPress o WooCommerce | Encaja muy bien, con un plan de continuidad por escrito | Encaja muy bien | Rara vez es su foco |
| Una app móvil | Aquí no encaja | Depende de la agencia | Encaja muy bien |
| Necesita hablar con la persona que escribió el código | Siempre | A veces | Rara vez |
El riesgo real con un freelance es la continuidad: una enfermedad, las vacaciones o el día en que deja de contestar. Pida que quede resuelto por escrito. Aquí eso significa código en su repositorio desde el primer commit, documentación junto al código, credenciales en sus manos y un procedimiento de traspaso que otro desarrollador pueda seguir.
Cómo evaluar a cualquier desarrollador de software
Contrate a quien contrate, estas preguntas separan a quien entrega de quien presenta.
- ¿Dónde vive el código? Debe estar en su repositorio, dentro de su organización, desde el primer día. Un desarrollador que se queda el código hasta cobrar la factura lo tiene de rehén.
- ¿Cómo se prueba un cambio antes de llegar a producción? Busque un entorno de staging, comprobaciones automáticas y una persona concreta que aprueba las publicaciones. “Lo pruebo en la web en vivo” es una señal de alarma.
- ¿Cómo se deshace una publicación? Pregunte por el camino de vuelta, no por el de ida. Cualquiera sabe desplegar; menos gente ha ensayado la marcha atrás.
- ¿Qué se midió antes de empezar? Las afirmaciones sobre rendimiento, tasa de errores o conversión no significan nada sin un punto de partida medido de la misma manera.
- ¿Qué no va a hacer? Un desarrollador sin límites declarados o no ha pensado en ellos o los descubrirá con su presupuesto.
- ¿Puedo leer algo que haya escrito? Código público, un artículo técnico o un documento de diseño. El estilo se nota enseguida: si el autor nombra los compromisos o solo las ventajas.
Trabajar sobre código que escribió otra persona
La mayoría de los proyectos empiezan dentro de un sistema existente, no en un repositorio vacío. La primera semana se dedica a leer, no a reescribir.
- Mapear antes de tocar. Qué plugins y servicios contienen lógica de negocio, qué cron jobs y webhooks se ejecutan, qué datos viven fuera de la base de datos (archivos, cachés, paneles de terceros). El mapa se guarda en el repositorio como un documento breve.
- Reproducir el problema en una copia. Una copia en staging con datos parecidos a los de producción, anonimizados cuando contienen registros de clientes, para poder demostrar una corrección antes de publicarla.
- Conservar lo que funciona. Reescribir es la forma más cara de arreglar un sistema y la más fácil de recomendar. El código feo pero correcto y cubierto por un test se queda; el código erróneo se sustituye en pasos pequeños y revisables.
- Dejarlo más legible. Cada cambio va acompañado del contexto que necesitaría un desconocido: por qué se hizo, qué se midió y cómo deshacerlo.
La misma regla vale a la inversa. Si más adelante otro desarrollador hereda el trabajo, debe poder continuar a partir de la documentación del repositorio sin llamar a nadie.
Seguridad y los datos que entrega
Un desarrollador con acceso a sus servidores y bases de datos supone un riesgo real, así que el tratamiento se acuerda por escrito antes de dar acceso.
- Las credenciales siguen siendo suyas. El acceso se crea por persona en sus sistemas y se revoca al terminar el proyecto; nada de contraseñas de administrador compartidas por correo.
- Los datos de producción solo se copian cuando hace falta, se guardan cifrados en el ordenador del desarrollador, se anonimizan para staging cuando contienen datos personales y se borran al acabar el trabajo. Según el RGPD esto es un tratamiento de datos, así que el contrato de encargado del tratamiento (artículo 28 del RGPD) forma parte de la documentación desde el principio, no se añade al final. En España el RGPD se complementa con la LOPDGDD y la autoridad de control es la Agencia Española de Protección de Datos (AEPD).
- Los cambios en producción son trazables. Cada publicación corresponde a un commit, y cada commit a un motivo.
- Los documentos entrantes se revisan. Los contratos y las solicitudes de oferta se analizan en busca de texto oculto e inyección de prompts antes de que nadie, persona o IA, actúe sobre ellos. Para eso sirve el hidden-text-detector mencionado más arriba.
Cómo se desarrolla un proyecto
El proceso está por escrito para que nadie tenga que recordarlo.
- Encargo por escrito. El sistema, el problema, el plazo, los repositorios y el alojamiento existentes, y quién decide por su parte.
- Alcance con supuestos. Qué se incluye, qué se excluye y qué tiene que cumplirse para que la estimación se mantenga. El diseño, los wireframes y los contenidos los aporta el cliente y así consta.
- Punto de partida. Accesos, una copia en staging y mediciones antes de cualquier cambio, para que “mejor” lleve un número asociado.
- Iteraciones semanales. Commits que puede revisar, una demostración en staging cada semana y decisiones registradas en el repositorio y no en un hilo de chat.
- Publicación y traspaso. Una vuelta atrás ensayada, documentación y, si su equipo toma el relevo, una sesión de traspaso con la persona que escribió el código.
Las condiciones de pago forman parte del alcance por escrito, con fechas concretas y no “a la entrega”. El trabajo empieza cuando se ha recibido el anticipo acordado.
Lo que no se ofrece
Tener claros los límites ahorra un mes a ambas partes.
- Diseño gráfico, wireframes y diseño UX. La maquetación la aporta el cliente, a menudo como una hoja de cálculo sencilla que asigna los elementos a cada vista. El trabajo es convertirla en una interfaz funcional y responsive.
- Apps móviles nativas. iOS y Android son otra disciplina y los atiende mejor un especialista.
- Soporte de guardia 24/7. Monitorización y respuesta rápida en horario laboral, sí; un busca a las tres de la madrugada, no.
- Hacerse pasar por un equipo. Una persona significa una agenda. Las cargas de trabajo grandes y en paralelo corresponden a una agencia o una software house.
Dónde se hace el trabajo
En Gdynia, en la costa báltica de Polonia, en hora central europea (CET). Los clientes están sobre todo en Polonia, Alemania, Austria, Suiza, los países nórdicos y el resto de la UE, y el trabajo es en remoto con demostraciones semanales. Fuera del trabajo con clientes, Mariusz forma parte desde 2024 del equipo organizador de WordCamp Europe en el área de presupuesto, para la edición de 2025 en Basilea y la de 2026 en Cracovia, y es coorganizador de CMSConf en Gdynia.
Si su problema es un sistema web o de e-commerce que tiene que funcionar de forma fiable y que la próxima persona que lo abra debe poder entender, descríbalo por escrito. Normalmente recibirá en un día laborable una respuesta con preguntas o un primer alcance. Hay más contexto en la página sobre nosotros.
