AI integration for existing Ruby on Rails applications
OpenAI, Anthropic, RAG, vector search, function calling, multi-model routing.
Why AI features fail in production
Most AI features fail in production for boring reasons. The API call sits in the request cycle. Nobody budgeted the tokens. There is no retry path. The feature was bolted on by someone who did not know the codebase.
I add AI to Rails applications the way I have built Rails applications for 18 years: as part of the system, with tests, background jobs and a cost you can predict.
I have designed the platform architecture for an AI writing product running agentic OpenAI and Anthropic workflows at 5,000 parallel requests a minute, improved RAG and search for a Shopify AI sales chatbot, and built model routing and vector search into existing products.
I work in your repository, follow your review process, and leave the code in a state your team can maintain without me.
What gets built
Three shapes of engagement. Each one starts with a review of your app and your use case, and ends with a written document you keep.
Feasibility review
A short review of your app and your use case.
- A use-case review
- A model choice: OpenAI or Anthropic
- A cost projection at your volume
- An architecture sketch
- A written report with a build estimate
You keep the report whether or not you continue, including if the recommendation is “don't build this”.
One production feature
Everything in the review, then one feature built end to end in your Rails app.
- API integration
- Prompt design
- Background processing
- Error handling and retries
- Tests
- Deployment notes
Retrieval or multi-model pipeline
Everything above, for a feature that answers from your own data or spans models.
- A retrieval pipeline with vector search over your data
- Multi-model routing with fallback
- Monitoring and cost controls
- Handover documentation
How it goes
- 1
Review
I read the relevant parts of your codebase and your description of the feature, and write up the use case, the model choice and a cost projection.
- 2
Design
An architecture note: where the calls live, what runs in background jobs, how failures and retries work, and what it will cost at your volume. You approve it before any code.
- 3
Build
The feature in your Rails app, with tests, in a branch under your review process. For retrieval and routing: vector search over your data, multi-model routing with fallback, monitoring and cost limits.
- 4
Handover
Deployment notes, a short document on how the feature works and how to change it, and a walkthrough call.
Two of these in production
Grafo
A new product that had to run agentic AI workflows against two model providers at high concurrency, with pipelines that scraped, processed and generated in stages.
5K+ parallel AI requests a minute in production.
Read the Grafo case study →Zipchat
A live chatbot whose answers depended on retrieval quality, and whose admin dashboard and request path needed to get faster.
Faster answers and better retrieval.
Read the Zipchat case study →Konstantin has been an invaluable leader to our team at GrafoAI. He possesses a remarkable depth of technical knowledge and expertise and has consistently delivered high-quality code. Konstantin has a remarkable ability to analyze and solve complex problems, often seeing them before they appear. His ability to meet deadlines and manage tasks efficiently is second to none. K is extremely forward-thinking; always suggesting and implementing innovative ideas and showing his commitment to our mission and goals. He's absolutely invaluable and an all-around great person to work with. I look forward to continuing our partnership with Konstantin well into the future
Questions
- Which models do you work with?
- OpenAI and Anthropic primarily; both are in production in projects I have built. Other providers on request. I recommend the model that fits your cost and quality needs rather than a default.
- Does my app need to be on a recent Rails version?
- No. I have worked with Rails 2 through 8. If the app is old enough that the integration would be fragile, I say so in the review and give you an estimate for the upgrade path.
- Can you work with our existing data for RAG?
- Yes. PostgreSQL with pgvector is usually enough; a dedicated vector database only if the volume needs it. The review tells you which.
- What if the review says the feature is not a good fit for AI?
- You get the written report and a recommendation, including “don't build this”.
- Who owns the code and prompts?
- You do. Everything is delivered in your repository under your account.
- How do you handle API keys and data privacy?
- Keys stay in your credentials store; I never hold them outside your environment. For regulated data — I have built HIPAA-scoped healthcare systems — we agree on what may be sent to a model before the design step.
Send me the feature you have in mind
Describe what the user should be able to do, and the Rails and Ruby versions you are on. I reply with whether it is worth building and what the review would cover.
Full overlap with European business hours, and 9am–6pm US Eastern.
43 clients, 21,500+ hours, 100% Job Success — the reviews are on Upwork.