Systems / Decision Layer
Map the stack before you build.
Most “we need to build this” problems are already solved by a tool you're paying for. The job is knowing what you own — then deciding: use it, prove it, buy a seat, or build. In that order.
Know what you own
Start with procurement
Procurement holds the real list: every contract, license, renewal date, and usually the system owner. That list is your map. You can't reason about a stack you can't see.
Point AI at your own stack first
When a problem shows up, search what you already pay for before scoping a build. AI can read the stack and surface candidates far faster than a human can — turning “let's build it” into “we already have it.”
Know the owners
If it's documented somewhere in your systems, you can point AI at it. If ownership is fragmented or informal, that's where a GTM engineer helps — whether that's standing up a process, organizing the data, or building a lightweight GUI that gives everyone a clean interface into something like Ariba. AI proposes; the owner disposes.
Field example — a config away, not a build away
I built a GUI to push new hires into Salesforce with the right role, profile, and field defaults. Then found out Workday has this built in — automated provisioning into SFDC with the correct fields on day one. I can't confirm we own Workday, but now that I know it exists, the next step is pulling the full tech stack and checking whether we have Workday or something equivalent that already solves this. If I had checked procurement first, I might never have built it. Now I know the order: stack first, build last.
The decision ladder
Search what you own
Point AI at the stack you already pay for. The capability is often a config away, not a build away.
POC on top of it
Improve what exists before replacing it. Prove the cheapest existing path first.
Buy a seat / turn it on
A licensed feature or one extra seat beats a custom system you have to maintain forever.
Build custom
Last resort. Only the 20% no tool covers, only after a seat-and-config attempt fails.
Run every request through this before writing a line of code
People before process, pain before solution, measure before you commit. The solution may be a seat away.
Three lenses on “should we build custom?”
Optimist
Build it. Custom fits our exact workflow, no vendor lock, we own the roadmap and ship exactly what the team needs.
Pessimist
Don't. You own maintenance forever, it rots the day you ship it, and procurement already bought three tools that do 80% of this.
Realist — the GTM engineer
Define the problem and measure it. Search the stack. Prove the cheapest existing path with a POC. Build only the slice no tool covers — and only after a seat-and-config attempt fails.
Same lens, real category. You need a CRM — or AI on the one you already have. Three options sit at different points: Salesforce, HubSpot, Aurasell. They aren't the same product at different prices. They're different bets on where AI lives: built into the core, or added on top.
The first case study was a choose-a-system decision. This one is the more common job: you already run a system that works, and the move is to enhance it, not replace it. Take account deduplication — a perfect example of layering tools instead of ripping anything out.