Go-to-market engineer for WooCommerce plugins, Shopify apps and Mautic

#Why features stopped being enough in 2026

Copying a feature now takes days. Agencies build their own small tools for clients, and the visual parts of a plugin or app are the easiest to copy. What stays hard to copy is distribution: a listing that answers the buyer’s question, onboarding that reaches the first result quickly, data that shows which feature paying users need, and follow-up that does not depend on somebody remembering to write an email.

Mat De Sousa, who runs the Shopify app WideBundle, described the same shift from interviews with Shopify agencies: purely visual apps struggle, and the ones that grow add a service layer (setting the app up for the merchant) and a data layer (A/B tests and analytics the agency cannot build itself). I see the same on the WooCommerce side: since 2019 I have run A/B tests, recommendations and dynamic content in Dynamic Yield for e-commerce clients, and the data layer is the part clients keep asking for.

#Who go-to-market engineering is for

Three kinds of clients ask for this work, and each starts in a different place.

• Plugin and app makers. You have a WooCommerce plugin on WordPress.org or a Shopify app in the App Store, a free and a paid tier, and installs that do not turn into revenue. The work starts with the listing and the path from install to the first result.
• Shops with a marketing stack that grew by accident. GA4, Google Tag Manager, a newsletter tool, a CRM and a few Zapier or Make.com scenarios, each set up by someone else. Nobody can say which channel brings paying customers. The work starts with the measurement and the data flow between those tools.
• B2B service companies and agencies. Leads arrive through forms and e-mail, and the follow-up depends on who has time. The work starts with Mautic or the CRM: one place where a contact, its consent and its history live, and automation that does the follow-up.

If none of the three fits, the problem is probably the product or the site itself, and WooCommerce development or business process automation is the better starting point.

#What you get in the first weeks

Every engagement produces files you keep, whoever works on them later.

The procedure behind these files, with the measurement table, the listing fields and the event names, is in my article on growing a WooCommerce plugin or Shopify app.

#Tools I work with in production

I list only tools I have used on real projects. If your stack has something else, I say so before quoting.

#What I need from you

• Read access to the analytics, the directory or Partner Dashboard statistics, and the CRM or Mautic instance.
• The changelog or release notes of the last few versions.
• Your own sentence about what a buyer installs or contacts you for. I check it against the data; I do not invent it.
• One person who decides when two goals conflict, for example more installs against fewer support tickets.
• Graphic design, if the listing or landing pages need new visuals. Design comes from your side; I implement and measure it.

#How I report

In writing, in the repository or a shared document, never only in a call. Each report has the same table as the baseline, what changed since the last one, and what I recommend removing. If a change did not move its number, the report says so. I do not promise rankings, installs or revenue, because neither the plugin directory nor the App Store publishes how it ranks, and your results depend on the product as much as on its distribution.

#What usually breaks first, on my own site too

The first audit usually finds a tool that runs and records nothing useful. Three examples from this site, all found and fixed in 2026:

• Campaign parameters lost on redirect. A rule meant to remove duplicate URLs sent every address with utm_*, gclid or fbclid to the bare URL with a 301. The canonical tag already handled duplicates, so the rule only did harm: from July to October the hidden UTM fields in the contact form stayed empty, and the source of those enquiries is unknown. The fix was to leave tracking parameters alone and let the canonical tag and the No-Vary-Search header do their job. The test is one request: an address with a fresh utm_source must return 200, not 301.
• A consent switch that controlled nothing. The cookie banner had a “functional” category, ticked by default, and no code listened to the user’s choice. YouTube embeds loaded either way, while the description promised that switching it off would block them. Unticking the box alone would have made it worse: the banner would then ask and lie about the effect. The order is always the mechanism first, then the default.
• A newsletter form with no confirmation and no exit. The form posted the address straight to a mail service. There was no double opt-in, no unsubscribe link, and the privacy policy did not mention the newsletter. The fix was a signed confirmation link valid for seven days and a permanent unsubscribe link. The address reaches the list only after confirmation, the first moment it may legally be added.

Each of the three looked like a working feature, and each one would have made any report built on top of it wrong. That is why the first weeks go to the baseline table and the event plan, before any campaign or automation.

#What I do as a go-to-market engineer

#Where I have done this work

Every item below is work I did myself, described without client names.

#Mautic fed from an ERP, a newsletter tool and address data

Since October 2025 I work as full-stack engineer on a subscription media and commerce platform for a Vienna software engineering agency. I built a Kotlin and Spring Boot service that merges subscriber, company, address and campaign data from a legacy publishing ERP, CleverReach and address sources into Mautic over OAuth. Most of the work is identity resolution: matching companies, normalising email addresses and phone numbers, removing duplicates, honouring do-not-contact flags and keeping the source of every record traceable. Imports run in an asynchronous queue over millions of contact rows and custom objects. A local language model (Ollama via Spring AI) classifies records inside that queue with structured output, on the client’s own infrastructure, so contact data never leaves it.

#Why first payments fail

On the same platform I ran a read-only analysis of abandoned first payments across Stripe, Klarna, PayPal and invoice. It separated SCA and 3D Secure failure clusters from users who abort or hop between payment methods, and it became a repeatable monthly export that replaced manual review. For a subscription business that is the step between “a trial started” and “revenue arrived”, which is exactly where go-to-market work pays off.

#Experiments, tracking and CRM automation

• Experiments: A/B tests, recommendations and dynamic content in Dynamic Yield for e-commerce clients since 2019.
• Tracking: Google Tag Manager, GA4, Search Console and BigQuery, set up so that campaigns and conversions can actually be read.
• CRM: since January 2021 contract work for a Berlin client on WordPress, WooCommerce, HubSpot and Shopify, with Make.com and Zapier automations between the websites, the CRM and other tools.

#My own plugins as the test bench

• plogins: my WooCommerce plugins, free versions on WordPress.org and Pro versions sold directly, with PHPStan, PHPCS and automated releases. Conversion features include order bumps, abandoned cart recovery, follow-up emails, back-in-stock waitlists and tiered pricing; EU compliance includes the withdrawal button required by Directive (EU) 2023/2673 and Polski for WooCommerce (GPSR, Omnibus).
• Release feed: each release writes its new features into a public feed at plogins.com/features.json, and my press workflow takes them from there into the articles about the problems they solve.
• AI agents: I wrote an open-source MCP server, woocommerce-mcp, that exposes WooCommerce products, orders and sales data to AI agents.

Related services: Shopify developer, WooCommerce ERP integration and business process automation.

#What the App Store and the plugin directory actually reward

Shopify documents part of it. Apps with Built for Shopify status get a badge, a search filter and a ranking boost in App Store search, and the status depends on performance, ease of use and proven usefulness measured on installs, review count and rating (Shopify, Built for Shopify). The listing guide allows up to five search terms of complete words and says apps should not lower a store’s Lighthouse performance score by more than 10 points (Shopify, App Store best practices).

WordPress.org documents the readme format: 1 to 5 tags, tags unique to your plugin are not shown, and the short description should stay under 150 characters (Plugin Handbook, readme). Neither platform publishes its ranking weights, so I do not promise positions. I fix what is documented and measure the rest.

#Consent rules for the follow-up

Automated email to people who installed a free plugin or started a trial is marketing in most cases, and it needs a legal basis. In the UK, regulation 22 of the Privacy and Electronic Communications Regulations 2003 restricts unsolicited marketing email to individual subscribers; Ireland implements the same rule from article 13 of the ePrivacy Directive 2002/58/EC. I set Mautic up so that consent, its source and its date are stored per contact, and campaigns check that field instead of assuming it.

Send a short written brief through the contact page: the product, where it is sold, what data you already have, and the one number you want to move.