Like a lot of you, I have some side projects that I started and got shelved.

Thanks to Claude Code, it has been a lot easier to pick those side projects back up and keep working on them. But I recently discovered something else that has forever changed how we should all think about building software.

Last year I built an internal tool called EngagePath that analyzes my own LinkedIn engagement. (BTW, thanks if you are one of the 80,000!)

The project eventually stalled. It was great at pulling in all of my data and giving me some unique insights. The challenge was all the weird rules I wanted to add into the product but were difficult to figure out or explain to a software developer how to build. The ambiguity around what to do next was at the maximum level.

Like a lot of projects, figuring out what to do with all the data we collected was the difficult part.

Then Claude Cowork came out and it opened my eyes to the power of MCP servers as I tried them from various vendors. Now all of a sudden I could ask Claude to just query Quickbooks for me and show me which customers haven't paid their invoices all from Claude.

Claude is now a Swiss army knife for querying data across various systems that exposed MCP servers.

Now I had the perfect solution to play around with all the data and build all the weird rules I could dream up... and I didn't even have to change the software itself.

That was the aha moment.

If you haven't run into the term, an MCP server is how you let AI use your product.

My example internal tool now does two things: it collects the data, and it exposes a set of actions through that API.

That's the whole product.

All the other features live in Claude now.

For example, I wrote my own skill to analyze my pending connection requests to evaluate which ones to ignore or accept. I have another that reviews new followers for people I should send a connection request to.

I took the brains out of the software and moved them into Claude, where I can change it whenever I want. The product collects data and exposes key features via an API. The intelligence lives outside it.

I'm building my own features in the product.

If you are thinking that an MCP sounds just like a standard REST API, you wouldn't be completely wrong.

The difference is that an MCP server explains how to use it, so the AI model can easily discover and access it.

My LinkedIn tool is one small example. The bigger one is how we run Full Scale. We're using over a dozen MCP servers across the business. Including QuickBooks, Hubspot, Ramp, Ahrefs plus four of our own internal systems. Now Claude can reach into any of them and do our unique analysis and business rules.

Now we can use Claude to be the command center to access a lot of different kinds of data across our entire business.

"Show me our revenue from last month" is a lot easier to do than logging into QuickBooks.

Even if you don't need to add an MCP server to your own product, I guarantee your business would greatly benefit from using MCP servers internally just as we are. It is creating amazing insights we never had access to before.

We are effectively building new "features" on top of other people's products.

The best example is how we analyze the risk of our client accounts. Claude pulls from four different systems to do it: whether the client is behind on their bill, what their recent feedback has been like, what the developers' quarterly reviews say, and the mood inside the team. It analyzes all of this and tells us which accounts it thinks are at risk and why.

That used to be a person opening four systems, copying numbers into a doc, and hoping they didn't miss anything. (Let's be honest, we didn't really do it very well at all before.)

Not one of those vendors tried to build a client risk dashboard, and not one of them ever will, because it's a problem that only exists inside my company. Intuit has no idea I compare their billing data against our own team sentiment. They shipped an MCP server, and I built what I needed on top of it at no cost to them.

I'm their customer, and I built my own features.

The move is to open your product up so people can build on top of it with their own AI.

You build core stuff that you're great at like the data and key actions. Then you give it an MCP server and let your customers wire it into whatever they're already doing. They'll connect it to their other tools, write their own logic against it, and turn it into something specific to them.

This isn't much different than exposing an API in the past. But now you have a lot more non-technical users, like my COO, using Claude Cowork to build things nobody would have ever done before.

Here is another example from Stripe.

Stripe shipped an MCP server, and a company called Dust used it to build a refund agent. It reads the customer's history, checks the charge in Stripe, applies Dust's own refund policy, and drafts the email explaining the decision. That used to take about an hour per request. Now it takes seconds.

None of that logic is Stripe's. They have never seen Dust's refund policy and they don't need to. The rules that decide who gets money back live on Dust's side, on an API that took a few minutes to plug in.

Your customers will build the features you never planned for, and you stop having to guess what they need.

Does every product need an MCP server? Probably not.

Are all your users technical enough to use one? Probably not.

One of our customers is building an MCP server for a product that services car dealerships. The average salesperson at the dealership is not going to use the MCP server. But the marketing manager that works at the dealership group level might.

This is definitely advanced functionality for now. It shows you're on the leading edge and innovating which is a good signal to send customers.

People will also be selecting products based on these new integration capabilities.

We actually canceled Zoho CRM and moved to Hubspot for this exact reason. While people think you can vibe code your own CRM and cancel Hubspot, we did the opposite. We stepped up to Hubspot because we appreciated its robust integration capabilities so we could build on top of it.

And perhaps the best use of an MCP server is using it not to build features at all that some clients might want.

Here is another great example.

We're building a new product right now called ProductWave. It takes in feedback from your customers, your prospects, and your own team, and it tells you what you should actually build next.

Most product teams are guessing at what their customers actually want. It is hard to piece together dozens of client conversations and find the signal in the noise. Or, somebody already knows exactly what they want to build and lacks the evidence they need to convince upper management to build it.

Like most startups, we are feeling pulled in multiple directions by potential customers. Beta testing is going great!

Do we focus on helping people find the insights around what to build, or do we focus on taking those insights and turning them into work items and how they do the work?

From our own internal usage, we have found that exposing the insights via an MCP server made the work item part of it easy to do in Claude itself. Maybe not perfect, but it absolutely works and provides tons of value.

We decided to focus on finding the insights and not building the features to turn the insights into code. Our MCP is good enough for now.

As a startup trying to get this product launched, being able to use an MCP server to essentially skip working on major product features right now is a massive boost. Not to mention the MCP server integrated in their local codebase actually makes our insights 10x more valuable!

I'll be honest about my own timeline here. Maybe some of you figured this out a long time ago. MCP servers as a concept came out at the end of 2024.

At the time I didn't understand the use case for them. It is just an API is what I thought.

Then I found my own use case that could take advantage of them.

That is how we learn when and how to use most tools in our life. The overall market adoption of MCPs and Claude Cowork also made a huge difference.

I'd push you to do two things.

#1. If you build software, consider adding MCP to it. Then let your customers build the features they need on top of what you made. It might save you a lot of time.

#2. And whether you build software or not, start using MCPs in your own company.

MCP servers are unlocking a whole new ability for non technical users to build advanced reporting, dashboards and workflows. Across not only one system, but multiple systems.

Let them do the hard work.

Let your customers build the features now.

It will just make them more sticky. The more they build on top of your software, the less likely they are to go anywhere.