Should you build your MCP server in-house? An honest decision framework | Portkeel
For roughly half of readers, the honest answer is build it in-house. If you have spare senior engineering time, a simple internal use case, and someone who will own the 2026-07-28 migration and the next one, building wins on cost and control. Buy when your engineers are the bottleneck, the server faces customers, or you do not want to own protocol migrations. Credibility here comes from naming the cases where we lose.
The five questions that decide it
Most build-vs-buy posts hedge. This one has a rule: answer these five, and the verdict falls out.
| Question | If yes, points to |
|---|---|
| Do your engineers have two spare weeks? | Build |
| Is the use case internal and static? | Build |
| Will someone own the next migration? | Build |
| Does the server face customers? | Buy |
| Do you want churn to be someone else’s problem? | Buy |
When in-house wins
A read-only tool over one internal database, built by a team with the time and the will to maintain it, is a genuinely good in-house project. Paying a vendor for it is buying insurance you do not need.
The maintenance question nobody costs
The build is the cheap part. The expensive part is the migration you will do every time the spec revises, and the 2026-07-28 revision showed that those revisions are not rare or gentle. A build-vs-buy analysis that ignores maintenance is comparing the wrong two numbers.
What we’d charge, for comparison
So the comparison is concrete: an internal build is $2,000 plus $250 per month, a product server is $4,500 plus $700. Whether that beats your own engineers’ time depends entirely on the five questions above. The whole “is MCP dead” question is worth settling first, and the numbers live on the pricing page.