How fast can you start?

A Discovery sprint runs 2 weeks and ends with architecture + execution plan. A pilot in real production lands in 4 to 8 weeks. Full systems in 3 to 6 months. We discuss timelines case by case before committing.

How does pricing work?

Discovery is fixed price (clean way to validate fit). Pilot and Production are scoped. Fractional CTO is a monthly retainer. Engagements in BRL for Brazil-based clients or USD for international. No open-ended hourly billing, no open-ended scope.

Does my data leave my infrastructure?

Not unless you want it to. We do on-prem deployments, dedicated instances in your VPC, or sovereign models running in Brazil. LGPD / GDPR aware by default. We frequently run with models via Bedrock or Vertex AI inside your own cloud account.

What stack do you work with?

Anthropic Claude and OpenAI for LLMs. Vector stores (pgvector, Pinecone, Turbopuffer). Orchestration via LangGraph, Inngest, or custom agentic loops. Next.js / React for frontends. Postgres, MongoDB, or whatever you already run for data. MCP for client integration (Claude Desktop, Cursor, etc). No stack religion.

And shipping to production?

Vercel, Cloudflare Workers, AWS, GCP, Railway, Fly, or bare metal. We handle infrastructure as code (Terraform), CI/CD, observability (logs, metrics, evals), and cost. The agent you see at /demo is a worked example: public stack, predictable cost, nightly reset via cron.

What happens after delivery?

Your call: full handoff (documented and we walk away), monthly support retainer (SLA + on-call), or Fractional CTO continuing as a senior virtual team. No lock-in.

MCP vs custom SQL chatbot: when each one wins

Every time a client asks us for an agent that "talks to the data," the same architectural fork appears.

Option A: build a custom SQL chatbot. Our frontend. Our backend. Direct DB connection. All ours.

Option B: expose the data via MCP (Model Context Protocol). Any MCP-aware client (Claude Desktop, Cursor, Claude Code, Cline) can connect. We focus on the MCP server, not the chat.

Both work. The wrong choice costs months. This post is about the criteria we use.

What MCP is, in one line

MCP is a standardized protocol for LLMs to talk to external tools. Your database becomes an MCP server. Any AI assistant talks to your MCP server using the same language.

Think "REST for LLMs". Claude Desktop has a native MCP client. So does Cursor. So does Claude Code. Instead of each one inventing their own way to "connect to the database," they all speak MCP.

When MCP wins

The users already live in an MCP-aware client. If your engineering team uses Cursor daily or your analysts use Claude Desktop, exposing your warehouse as MCP lets them "ask the data" without switching windows. No training needed. They open the client they already use.

You don't want to build chat UI. Building a decent chat is bigger than it looks. Streaming, visualized tool calls, inline table rendering, history, auth, mobile. If the UI isn't your differentiator, letting the user's MCP client handle that work saves months.

The use case is developer-heavy. Engineers, devops, technical analysts prefer staying in their editor / terminal. MCP serves that audience natively.

You want to compose with other sources. Claude Desktop can be connected to your warehouse + GitHub + Notion simultaneously. Cross-source questions ("list João's open PRs and how much his feature shipped") become trivial without you integrating anything. MCP composes.

You want to be openable by third parties. If your offering is a platform and clients will plug in their own AIs, MCP is the choice. It's the standard way to be AI-API-compatible in 2026.

When custom SQL chatbot still wins

The user isn't technical. Your aunt who runs a bakery isn't going to open Claude Desktop. She wants a simple mobile app with a big button. For her, you build dedicated UI and MCP stays as an optional implementation detail.

UX has to be contested. If your competitive differentiator is the chat experience (animations, custom charts, guided flows, multimodal), you need end-to-end control of the UI. MCP delegates UI control to the user's client.

The integration needs to be deep. If the agent needs to open an approval modal, update a field on another screen, fire a push notification - those flows live in YOUR app. You can't delegate that to Claude Desktop.

You want to track conversions. Who asked what, when, and what they did next? In your own chat you have analytics. In MCP the conversation lives on the client side; what you see is just "someone called my query tool."

Compliance forbids exposing. In some regimes (financial, healthcare), exposing an endpoint that external LLMs can call directly is forbidden without sign-off. Your own chat keeps everything inside your boundary.

The choice we make for the demo

The demo at zechim.com/demo has BOTH surfaces. By design.

The /demo page is a custom SQL chatbot. Streaming, visualized tool calls, inline table rendering, conversion CTAs. 100% our UX.

The /demo/connect page offers the MCP version. You grab a free key, paste it in Claude Desktop, and ask from inside your editor. Same data source, different client.

Why both? Because both audiences exist. The casual visitor who lands on the site wants the pretty chat that works in one click. The technical engineer evaluating whether we know what we're doing wants to plug into their Cursor in 30 seconds.

Both surfaces go through the same MCP server under the hood. /api/chat connects to /api/mcp via an internal-bypass header. Claude Desktop connects to /api/mcp via API key. Same port, same tool, same guardrails, same quota control.

That's MCP's quiet payoff: even when you build your own chat, exposing the engine as MCP costs little and gives you an additional surface for free.

How to decide in your case

Three questions:

Who's the primary user? Technical (Cursor / Claude Desktop) or general (mobile app)?
Is UX part of the product? If yes, custom chat. If no, MCP.
How much does compliance restrict? The more restrictive, the more custom.

It's almost never zero-sum. The sensible answer in most cases is: custom chat for the primary user, MCP exposed so the technical user can plug in. That's what we did for the demo. It's what we recommend in most projects.

If you're at this fork in your project, it's worth a conversation. We help design the architecture before the code goes the wrong way.