From GTM to Software Engineering: Borrowing Process Over Models
I'm not a software engineer. My background is GTM. So now I'm a GTM Engineer I guess. I've spent years helping SaaS founders figure out how to get from founder-led execution to scalable growth. Today, though, I see GTM more as a code problem and spend a surprising amount of time shipping software.
- Cloudflare Workers
- Internal tools
- Lead scoring systems
- Client microsites with databases behind them
The most interesting concept to borrow was the engineering process.
Programming and engineering are different jobs.
The Process Matters More Than the Model
Everything I work on starts as a Linear issue.
Whether it's a GTM workflow, an internal tool, or a client feature, it goes through the same pipeline:
Backlog → Todo → In Progress → Review → Done
When an issue is ready, an orchestrator agent picks it up:
- One agent builds it
- Another reviews it
- A third only deploys if the reviewer explicitly approves
The interesting part isn't that there are three agents—it's that every stage leaves its reasoning behind. Each handoff becomes a comment in Linear explaining what changed, what was tested, and what still looks risky. The ticket itself becomes the audit trail.
That completely changed how I work and pushed me toward separating everything into small tasks.
Grilling Ideas Before Code
I borrowed almost directly from Matt Pocock's workflow: grilling ideas before writing code. Since only 20% of my time is coding, I had to adapt it to work.
My flow looks like this:
/grill-me— Pushes back on every assumption, looks for missing requirements, edge cases, and contradictions
/to-prd— Turns the conversation into a proper specification and publishes it as a checklist of implementation tasks in Linear
Code — By the time an agent starts writing code, it's working from a document, not a prompt
Checklists work exceptionally well for LLMs—they force the model not to skip steps.
This has probably improved quality more than switching models ever did.
Frontier Models Should Make Decisions
Reserve expensive thinking for Claude Code:
- Orchestration
- Architecture decisions
- Code review
- Business logic
- Anything where judgment matters
Everything else runs on open models:
- Bulk enrichment
- Classification
- Scraping
- High-volume work
These don't need frontier intelligence—they need throughput. Moving that work onto DeepSeek also let me remove a paid search API because agents could perform the same discovery directly.
Context is Infrastructure
I stopped thinking about prompting as the important part. Most quality comes from context.
Everything important about my business lives inside the repository:
CLAUDE.md— Business rules- Architecture notes
- Reference documentation
Every new session starts with this context already loaded—lean and on-demand. That means I'm no longer explaining my business over and over. I'm onboarding agents the same way I'd onboard a new teammate, with core context and pointers to their systems (CRM, email, transcripts, etc.).
How My Days Break Down
GTM work — Lead sourcing, enrichment, ICP scoring, outbound systems
Client software — Small production apps, review microsites, internal tools
Content — LinkedIn posts, newsletters, articles
Internal tooling — Tools only I use
Plumbing — APIs, automations, integrations
This is a very different workflow from what I imagined AI-assisted development would look like a year ago.
Final Thoughts
I still don't think of myself as a software engineer. But I also don't think that's the point anymore.
For me, the most interesting thing was that it gave me access to an engineering process. I'm curious whether other people without a traditional engineering background are converging on something similar.
What parts of software engineering have you borrowed? Which open models have earned your trust for high-volume work? My guess is that a lot of us are independently reinventing the same operating system.
SOCIAL SHARE CARD GENERATOR