The AI integration gap
Customers’ expectations of SaaS products changed fast. Buyers now ask whether a product works with their AI assistant, whether it has an AI feature, and whether it integrates with the rest of their stack. “MCP server” went from niche to mainstream search in a matter of months, and teams that already have one show up in agent workflows that their competitors miss.
Meanwhile, most SaaS teams are fully booked on the core roadmap. AI and integration work keeps slipping, and so does the cleanup of the parts of the codebase that were rushed to hit an earlier deadline.
What I build for SaaS teams
- MCP server development. Typed tools that map to your API, OAuth and per-tenant scopes, rate limits, audit logging, documentation and directory listings.
- In-product AI features and RAG assistants. Answers grounded in your docs and the customer’s own data, with citations, evaluations and cost controls.
- Integrations. Bidirectional sync, webhooks, retries, idempotency and the dull details that keep integrations from breaking at 2 a.m.
- Vibe-code rescue. An audit of AI-generated or rushed code, then targeted fixes to security, performance, data model and tests.
- Cloud and DevOps. CI/CD, observability and sensible cloud bills.
Senior full-stack capacity, on demand
I’ve built and run a complete SaaS on my own: a game-network product with a Rust engine, a NestJS API, Stripe billing, a Next.js portal, a desktop app and a CI-deployed server fleet. I know what it takes to ship features that hold up in production, and how to do it inside someone else’s codebase without leaving a mess behind.
How engagements usually work
- Fixed-scope builds. An MCP server, a specific integration or a defined AI feature, with a fixed price, a timeline and clear acceptance criteria.
- Audits. One to two weeks reviewing a codebase, architecture or AI feature, ending in a written, prioritised report your team can act on, whether or not I implement it.
- Embedded sprints. Two to six weeks working inside your team on a specific outcome: same standups, same repo, same review process.
Whatever the format, the deliverables are the same. You get code in your repository, tests, documentation and a handover session. I write code the way I’d want to inherit it: typed, readable and boring in the right places.
Questions to answer before building an AI feature
Before writing a line of code, we agree on three things:
- what a correct answer looks like
- what the feature costs per user at your expected usage
- what happens when the model is wrong
Teams that skip this step ship impressive demos that churn customers. Teams that answer it ship features customers trust and pay for.