# 145: Marketing as Engineering > [!question] Lingering Questions > - What is the actual defect/incident rate of marketer-built production apps (like the Laracon photo tool) compared to engineering-built equivalents, six months out? > - Ian says he "didn't even read through" all the DSA orchestrator's suggestions yet has "yet to see one" he thought was bad — what governance catches a rare but costly bad suggestion before it lands in production code? > - Is the Linear-for-marketing pattern (cross-department drop-off + lightweight templates for recurring workflows) portable outside a team that already has Laravel's engineering-heavy tool culture? > [!tip] Article Ideas > - A "sloppy internals, good output" pilot writeup: run one bounded internal tool (thumbnail/OG-image generator) this way and report time saved vs. defect rate after two weeks. > - Draft an orchestrator/sub-agent audit prompt modeled on Ian's DSA pattern (catalog → parallel audit → dedupe/rank → linked to-dos), tested on one bounded section of a non-code corpus before wider use. > [!link] Cross Reference > - [[3. Resources/MOCs/DevRel MOC]] — direct developer-marketing case study of a marketing org restructuring around AI-agent self-serve tooling. > [!quote] Vocabulary > - **Marketing engineering** — Laravel's ~2-person specialist function that only handles last-mile integration (DNS, hosting, path routing) after a marketer's build is ~95% done. > - **DSA prompt** — Ian's "data structures and algorithms" audit prompt: asks an agent to find material simplifications (collapsing scattered booleans into enums, etc.) after a build session, now scaled into a catalog → parallel-audit → dedupe/rank → to-do-graph orchestrator pipeline. ## Bib capsule Ian Landsman & Aaron Francis, "145: Marketing as Engineering," *Mostly Technical* podcast, https://www.youtube.com/watch?v=zpjQLAoLR2w. ## Author's thesis (Q1+Q2) Aaron Francis (Laravel's VP of Marketing) describes his marketing team becoming "engineering-pilled": individual marketers now use AI coding agents to build real production apps and collateral — a Laracon photo-sharing tool, a prospect-facing slide generator, ad-copy pipelines — with marketing engineering brought in only for last-mile integration. The governing policy is that internal-tool code quality doesn't matter as long as the output is good and the team gets faster, which matters because it's a live case study of a marketing org restructuring itself around agent-assisted, self-serve tooling rather than filing tickets and waiting on engineering. ## Key arguments (≤3) 1. Marketers can take a build to ~95% completion themselves; engineering's role narrows to pushing it over the line, not building it. 2. Internal-tool implementation quality is deliberately not evaluated — only whether it produces a good final asset faster. 3. Codebase (and by extension prompt-driven build) cleanup should target the structural cruft left over from discovery-driven building, not individual bugs — the reasoning behind Ian's DSA prompt. ## Claim atoms ### Marketers can ship real apps without engineering > [!quote] ID:rw_atom1 > So Sam and Abby were able to build this whole thing out without involving, you know, uh, product engineering and then without involving our marketing engineers either Where/why: describes the Laracon photo-management app Sam Sappenfield and Abby built solo — the episode's most concrete evidence for the thesis. ### The marketing-engineering handoff model is "push it over the line" > [!quote] ID:rw_atom2 > The dream is the marketer has a good idea. >> They're able to get it 95% of the way there. >> They go to marketing engineering and say, "I'm almost there. Could you push it over the line?" Chip's like, "Sure, no problem. Let me push it over the line and we're done." Where/why: Aaron's explicit statement of the target operating model — 95% self-serve, 5% specialist handoff. ### Internal-tool code quality is irrelevant if output quality holds > [!quote] ID:rw_atom3 > I don't care if the internal tool is is sloppy. Like I just I just don't care if it produces a good final asset. That's the deliverable, >> right? >> So I don't I don't care if your your uh YouTube thumbnail generator is just a total mess under the hood. Does it make YouTube thumbnails? Does it make you faster? Then let's go. Move on. Let's be done with it. Where/why: Aaron's management directive — the permission structure behind every example in the segment. ### Codebase cleanup should target discovery-driven cruft, not bugs > [!quote] ID:rw_atom4 > look back over the work we've just done. Cuz as as we've talked about many times, building is always this tension between uh figuring out what you want along the way and then once you know what you want, like cleaning it up. Where/why: Ian explaining the origin of the DSA prompt — names the specific problem it solves, distinct from ordinary bug-fixing. ## Permanent candidates - **New**: Sloppy internals are an acceptable trade for output speed, within a bounded internal-tool scope — promoted below as [[3. Resources/Permanent Notes/Sloppy Internals Are an Acceptable Trade for Output Speed Within a Bounded Internal-Tool Scope]] ## Processing checklist - [x] Checked for existing Literature Note — none found - [x] Checked for existing Permanent Notes — related but non-duplicate coverage in [[3. Resources/Permanent Notes/Systems-First GTM Compounds Where Campaign-First GTM Does Not]] (systems-first GTM sequencing, not internal-tool quality tolerance) and [[3. Resources/Permanent Notes/Prompt-Driven Building Moves the Bottleneck to Messaging]] (bottleneck shift for prompt-driven builders, not the sloppy-internals policy); no note covers this episode's specific claim - [x] Connected into [[3. Resources/MOCs/DevRel MOC]] ## Links - [[3. Resources/MOCs/DevRel MOC]] — direct developer-marketing case study of AI-agent-assisted self-serve tooling inside a marketing org