Build Buy Wait

Every team faces the same question eventually.

Do we build it? Do we buy it?

In my view, the answer is simple: build what differentiates you.

Everything else? Buy it and move on. Focus where it matters.

At PortSwigger, that means building software for security professionals, not CRMs, not invoicing systems, not things that already exist in a thousand better forms. We’re never going to out-invest Salesforce in CRM and while we’ve got the engineering talent to build one, it’s not our core business. So we don’t try.

That mindset hasn’t changed, but recently something made me stop and think.

The seed for this post came from a conversation with Daf, our CEO, who first framed the idea as “build, buy or wait.” The more I sat with it, the more it resonated.

We were talking about some of the new AI integrations and he shared a story I kept coming back to. He’d been speaking to another colleague about hooking up Google Drive to ChatGPT. The options were the usual suspects: build a connector, buy one or hack something together.

Then came the punchline:

“Or we just wait. OpenAI will probably release it next week.”

And sure enough, they did.

That line stayed with me.

Build, buy or wait.

The speed of software is breaking our old decision models

Agentic AI means the cost of building things is dropping through the floor.

Need to stitch a few tools together, write a thin wrapper or automate a workflow?

That used to take a couple of weeks. Now it’s days, sometimes an hour.

Companies using agentic AI have picked up the pace and are releasing new capabilities at breakneck speed. What used to be a roadmap item might now show up in your product dashboard next week.

This is where “wait” comes in.

Not as a stall tactic, not because we’re unsure, but because it might not be worth doing the work if someone else ships it first.

The build vs buy question isn’t new but AI is making “wait” the right answer more often than it used to be. Things that once needed weeks of engineering now arrive as APIs, open source tools or integrations, often just in time to make your solution obsolete.

We had started to form plans around building MCP services to integrate our line of business tools but the speed at which vendors like JIRA and Notion are releasing them made us pause. It probably makes more sense to wait.

Whether you’re a software engineer trying to unblock your team or a CTO deciding where to place your bets, the real question isn’t “can we build this?” It’s “will someone else solve it faster and what’s the value in us maintaining it?”

You can build it. The question is whether you should.

Here’s how I’m starting to think about it

By “core,” I mean something that directly impacts your ability to differentiate.

For a company building developer tools, that might mean scanning and reporting. For a CRM, it’s workflow automation.

“Wait” doesn’t mean do nothing.

It means don’t sink time into solving a problem that’s about to be solved for you.

Think about where the market’s heading.

If the internal tool or capability you’re planning is likely to be useful to others, it’s probably on a vendor roadmap already.

In that case, wait. Don’t spend time solving a problem someone else is about to solve for you.

Waiting is a risk but so is solving the wrong problem

Sometimes the thing you’re waiting for doesn’t land. It might land late or it might not fit your needs.

The trade-off is worth thinking about.

You could burn two weeks building something that’s obsolete by the time it’s ready or you could use that time to invest in your product or improve your internal processes.

It isn’t about hesitation. It’s about timing, judgment and reading the market.

Final thought

The best engineers don’t just build fast. They know when not to build at all.