From Full-Stack Developer to AI Builder: Why I Built ApexMCP

Every few years in a technology career you face the same choice: adapt or become obsolete. I have faced that moment more than once, and each time the answer was the same — build something with the new technology until it stops being new to you.

I started out as a full-stack developer straight out of technical college. Frontend, CSS, HTML, JavaScript, backend in .NET, database design, deployments, BI and analytics — the expectation at the time was that one person covered all of it. Then the industry matured. Specialisation arrived. The generalist became a harder sell, and catching up meant building private projects late into the night: a custom CMS from scratch, experiments with different frontend and backend frameworks, deep dives into high-availability architecture. You built things nobody would ever use, because that was the only honest way to learn.

Now the moment has arrived again. This time the technology is AI.

The "vibe coding" experiment

For anyone in product or development circles, "vibe coding" has been the dominant conversation topic for the past year. The idea that you can describe what you want and have an AI build a meaningful part of it has shifted from novelty to genuine practice. I wanted to take a serious look at it — not as a toy, but as a production methodology. And I wanted to do it against a real problem, not a tutorial app.

The problem I chose was one I had been turning over for a while: enterprise AI governance around model context.

The problem: context without control

When organisations deploy AI tools for their people, they quickly run into a version of the same question: what data is the model actually seeing, who authorised that, and what happened as a result?

Today that problem is addressed in three main ways. First, through initial context and instructions — the system prompts and persistent memory that models like Claude or GPT carry into every conversation. Second, through skills and agents built for repeated tasks. Third, and most powerfully, through MCP servers: a standardised protocol that lets AI models query external data sources and execute actions on third-party systems.

MCP is the interesting one. It allows an agentic AI to reach into a database, call an API, read a document store, or trigger a workflow — all within a single conversation. That is genuinely transformative for productivity. It is also, without governance, a significant risk.

The context limit problem

Before we get to governance, there is a foundational constraint worth understanding. AI models have context limits — the total amount of information they can reason over in a single session. The industry is investing heavily in expanding those limits, but even with vastly larger context windows, the problem does not disappear. Enterprise knowledge grows continuously. The volume of data an organisation might want to feed an AI — from CRM records to database tables to internal documentation to live API responses — grows without bound.

MCP servers address this by making context dynamic rather than static. Instead of pre-loading everything into a prompt, an agentic model queries what it needs when it needs it. That is the right architectural answer. But each MCP connection an organisation maintains is itself a token cost, a credential to manage, a governance gap to fill.

The logical response is a single gateway: one MCP endpoint that aggregates every data source the organisation wants to expose to AI, with access controls determining what each user or team can actually reach through it.

The governance problem

RBAC — role-based access control — is the standard answer for permission management in third-party SaaS systems. It works well when the system itself enforces roles. But most organisations have custom databases, internal APIs, and document stores that have no built-in RBAC. Historically, software developers solved this by building APIs in front of those systems, with authentication and authorisation baked in. That works, but it is expensive and slow — and it was designed for human users, not AI agents making hundreds of queries per session.

There is also a subtler dimension to the governance question: the role of humans in the loop.

People brought into organisations to fill operational gaps will face pressure as AI covers more of that territory. But organisations will always need someone to own decisions and stand behind outcomes. You cannot hide behind "the AI did it." That means the governance layer needs to handle not just read access, but write access with appropriate friction.

Consider the scenario: an employee needs both read and write access to a system as part of their job. But when using AI assistance, the organisation only wants the AI to read — write operations should route back to the human, either for manual execution or through an approval workflow that creates an audit trail. That is not a technical limitation; it is a governance policy. And it needs to be configurable, not hardcoded.

What I built

ApexMCP is a platform — with a self-hosted option — that sits between all of an organisation's data sources and its agentic AI models. The architecture is a hub rather than a mesh.

An administrator connects data sources to the platform: databases, third-party SaaS systems, custom REST APIs, document stores, other MCP servers. The platform uses introspective techniques to discover the schema of connected databases — tables, columns, stored procedures — and exposes selected schemas as MCP tools. For REST APIs and SaaS connectors, it surfaces the operations the administrator has approved.

The result is a single, stable MCP endpoint that any MCP-compatible AI model can connect to. The administrator controls which tools are visible to which users or teams. Write tools can be switched off at the tool level, leaving read-only access. Approval workflows can be configured for specific operations, so that a write triggered by an AI assistant routes to a human for sign-off before it executes.

• One endpoint, many sources. Users configure one MCP connection in their AI client, not one per data source. Fewer connections means less context overhead, fewer credentials to manage, and simpler offboarding.
• Per-tool access control. Administrators can enable or disable individual tools for individual users or teams. A support agent gets read access to the CRM. A developer gets schema introspection on the test database. Neither gets write access unless explicitly granted.
• Approval gates. Configured write operations route to an approver before execution. The AI does the work of composing the action; a human makes the call to run it.
• Full audit log. Every tool call — who made it, which model, which tool, what arguments, what result — is recorded. Tamper-evident, queryable, exportable.
• Model-agnostic. The gateway speaks MCP. It does not care whether the client is Claude, GPT, Gemini, or something else. Switching models is a client configuration change, not a migration.

On building it alone

Part of what this project was designed to test is the realistic ceiling of what one person can build using AI-assisted development. The answer, in 2026, is significantly higher than I expected.

This is not a prototype. ApexMCP has a multi-service backend with a gateway, billing integration, a full auth stack including SSO and SCIM provisioning, HMAC-signed webhooks, a REST connector catalog, GraphQL schema discovery, MCP versioning with rollback, and a production security posture that survived a self-audit I ran before going live.

That does not mean AI did everything. Architecture decisions, domain modelling, debugging subtle race conditions, thinking through the governance model — those required real engineering judgment. What AI-assisted development changed was the ratio of thinking time to building time. The bottleneck shifted from implementation toward design, which is where it should be.

The broader point

AI will not make good software engineers redundant. It will change what the job looks like — more architecture, more governance thinking, more understanding of what systems need to do rather than just how to make them do it. The engineers who will struggle are those who were primarily valued for their ability to implement specifications without understanding them.

The same pattern applies across digital roles. AI raises the floor for everyone. It lowers the barrier to execution. What it cannot replace is judgment about what to build, why, and for whom — and accountability for the outcome.

ApexMCP is currently in beta. I am pushing it toward broader availability over the coming weeks and months, with the goal of making governed, safe AI access achievable for organisations that cannot afford to build it themselves — including small and medium enterprises that have as much to gain from AI as large ones, and currently far fewer tools designed for them.