Nadia Mohamed
Discovery
The problem in your team's words, the constraints (stack, infrastructure, security), the success criteria. A short written brief comes back from this — what we're building and what we're not.
Service · Marketing engineering
Full-Stack Development — implementation that doesn't need a separate developer
React, Python, WordPress, API integrations. The marketing-engineering hybrid that ships what consultants usually only recommend. Built into your codebase, documented for your team, designed to outlive the engagement.
When this is the right call
Marketing engineering work tends to follow recognisable shapes. The pattern that signals this is the right engagement:
- Marketing has a roadmap, dev has no capacityThe technical work you need isn't going to be prioritised against the product backlog any time soon — and waiting another quarter isn't an option.
- Custom WordPress at scaleMultilingual, multi-domain, headless or otherwise non-trivial WordPress that's outgrown what a theme + plugin stack can deliver.
- An integration that's "just" connecting two APIsIt never is. Webhooks, idempotency, retry logic, schema mapping, error handling — engineered, not glued.
- A headless front-end buildNext.js or similar on top of a headless CMS, with the technical SEO discipline that most front-end agencies don't bring.
- A marketing-facing internal toolLead scoring, content scoring, brief generation, attribution dashboards — the kind of thing the marketing ops team would build if they had an engineer.
- Migration work that's bigger than a pluginCustom data shapes, redirect maps, structured-data preservation — the kind of migration that needs engineering, not a checklist.
What you get
Every engagement produces the same five artefacts so the work is maintainable after handover, not a one-person dependency.
-
Technical specification
The problem, the chosen architecture, the trade-offs taken. Written before the build so we agree what good looks like, not after when scope has drifted.
-
Production-quality code
In your repository, following your conventions, integrated with your CI. Reviewed and merged like any other change to your codebase — no parallel branch that quietly diverges.
-
Tests
Unit and integration coverage proportional to the surface area. Tests are the documentation that doesn't lie about what the system actually does.
-
Documentation
Architecture overview, key decisions, operational runbook, how to extend, how to debug. Written for the engineer who inherits it six months from now without context.
-
Handover & first-month support
A walkthrough session with the team that will own the code, plus availability for the first month if something breaks or needs a small extension.
How it works
Four phases. Elapsed time depends entirely on scope — small integrations land in a week or two, larger builds take longer.
Spec
The technical specification: architecture, data shapes, integration contracts, the trade-offs taken. Reviewed by your dev team before any code lands.
Build
Production-shaped code, in your repo, reviewed as it goes. Tests alongside the implementation. No surprise reveal at the end of the phase.
Ship & handover
Deploy, documentation, walkthrough with the team that will own it. First-month support window opens.
How this works alongside your team
Marketing engineering work sits at the intersection of three teams — the engagement is shaped to be additive to all of them.
Your dev team stays in the loop
Architecture decisions are reviewed by your engineering leads. PRs go through the same review process as in-house work. I write code your team will read — and inherit cleanly when the engagement ends.
Marketing owns the requirements
The people who'll use the thing define what "done" means. Discovery is shaped so marketing's needs translate into engineering decisions without lossy hand-offs.
If you don't have an engineering team
Smaller builds can run on managed infrastructure your team can operate without a dedicated developer — runbook-driven, with a maintenance shape that fits the team you actually have.
Async-first, no daily standups
Async progress updates, one scheduled mid-build sync, the rest documented as it happens. PRs and design docs are the artefacts — meetings are the exception.
What this actually moves
The honest version
This service moves the thing most marketing teams find hardest: turning the roadmap into shipped code without waiting for a product engineering team that has its own priorities.
The compounding effect is real. Each shipped piece — the schema rollout, the integration, the internal tool, the headless front-end — unlocks the marketing work that depends on it. The audit you ran six months ago becomes implemented infrastructure rather than a PDF that's still waiting for a sprint.
Common questions
If yours isn't here, drop a line — I'll answer directly and add it.
Which stacks do you actively work in?
Primary: React / Next.js on the front end, Python (FastAPI, Django) and PHP on the back end, WordPress at custom-template depth, n8n for automation flows. Integrations across most major CMS, CRM and analytics platforms. For stacks I haven’t shipped recently (Rails, Java, .NET) the engagement either looks different or isn’t the right fit — happy to say so up front.
Do you work from our codebase or build separately?
From your codebase. The point of this service is that the work lives where the rest of your code lives — same repo, same review process, same conventions. A parallel build that gets merged at the end is the recipe for code that quietly rots.
What about ongoing maintenance after the engagement?
The build is designed so your team can own it without me — that’s why the spec, tests and documentation are part of the deliverable. The first-month support window covers anything that breaks immediately or needs a small extension. If you want ongoing engineering capacity beyond that, a small retainer is possible — typically a day or two per month for specific projects.
Will the code follow our conventions?
Yes. Linting rules, test conventions, naming patterns, commit-message style — I match what your team already uses. The discovery phase covers this so there are no surprises at PR review time.
Can you handle the technical SEO side of a headless build?
That’s the strongest version of this engagement. Most front-end agencies don’t bring technical SEO depth; most SEO consultants can’t ship code. The combination — structural SEO discipline baked into the front-end build from the start — is where the work compounds the hardest.
What’s the typical engagement size?
Small integrations: one to two weeks. Internal tools and mid-size builds: three to eight weeks. Larger applications (headless front-ends, multi-system integrations): two to four months. The discovery phase produces an honest estimate before commitment.
Do you handle deployment and infrastructure?
Yes, within reason — usually deploying into infrastructure you already use rather than introducing new platforms. If the project genuinely needs new infrastructure (Cloudflare Workers, AWS Lambda, a managed Postgres) that’s part of the spec and the documentation.
Have a build that's been sitting in the backlog?
Get in touch with a short description — what you're trying to ship, what's currently blocking it, the stack you work in. I'll come back within 24 hours with whether this is the right engagement and what the next step looks like.