The Default Reflex: "It's a Graph, So You Need Neo4j"
When you set out to build a tool that maps microservices, API routes, database tables, and message queues to give AI coding assistants architecture awareness, the immediate reaction from almost every engineer or architecture forum is unanimous:
"You have microservices communicating with each other. That is a graph problem. You need a dedicated graph database like Neo4j, paired with PostgreSQL for structured metadata, and maybe Elasticsearch or Meilisearch for keyword retrieval."
On paper, that sounds textbook correct. Microservices form a directed network of dependencies. Calling services are nodes, HTTP routes and message queues are edges, and database tables are data sinks. Reaching for Cypher queries, graph traversals, and multi-node clusters seems like the standard, professional thing to do.
The problem starts the exact second you think about developer adoption.
The quickest way to kill a developer tool is to demand that engineers set up infrastructure before they can even try it. If running ArchMCP requires a developer to install Docker, pull a 1.5 GB Neo4j image, configure Java memory heaps, stand up a PostgreSQL container, run schema migrations, and configure connection strings, 95% of developers will close the tab and never look back.
I wanted ArchMCP to feel like ripgrep or jq—you point it at a folder of code, run a command, and it just works in two seconds flat. That single constraint ruled out external database servers completely.
"The fastest way to kill a developer tool's adoption is to make engineers configure three databases before they can run a simple CLI scan."