Technologyfor your idea
Some problems have no boxed product behind them: what you need either nobody builds, or nobody builds the way you need it. Work here starts not with a layout but with the question of what exactly this thing must do and how we'll know it works. Then architecture, a prototype on real data, and only then full development.
What's included
Turning an intention into a specification: system boundaries, scenarios, data in and out, a measurable definition of done
Service and storage design, background job queues, idempotent operations, a plan for every external dependency failing
LLM integration: search across your document base via embeddings and a vector store (RAG), streamed responses, function calling, defence against prompt injection
Schema, migrations, parsing and normalising whatever you have — tables, exports, documents, other systems' responses
Talking to external systems: REST and webhooks, retries with backoff, a log of every exchange so disputes can be settled
Logs, metrics, failure alerts, tracking of model spend and request rate limits — so the invoice doesn't surprise you
How the work runs
- 013–5 days
Scoping
We turn the intention into boundaries: what the system does, what it deliberately doesn't, where its data comes from and by what test it counts as working. This is also where we check honestly whether an off-the-shelf service at thirty dollars a month already solves it — sometimes it does, and I'll say so.
- 022–3 weeks
Prototype on real data
The crudest possible version, but running on your actual data rather than invented samples. It's the only way to learn early that the model stumbles on your phrasing, or that half the fields in the export are empty. A cheap check instead of an expensive surprise in month four.
- 032–3 weeks
Architecture
Service and storage design, background queues, how repeats are handled, a plan for each external dependency failing. The boring step that later decides whether the service falls over on Saturdays.
- 04from 4 weeks
Development
Work runs in two-week blocks: each one ends with something you can open and use, not a progress report. Priorities are revisited at the block boundary, so changing your mind mid-way doesn't mean rewriting the contract.
- 052 weeks
Pilot
We open it to a limited group, watch logs and metrics, and measure what the model calls actually cost. We fix what surfaces, and only then open it to everyone.
What moves the price
"on request" is the floor, not bait. Here's what pushes the number up, so you can place your own case before we talk.
An understood process saves weeks. 'I want something with AI' isn't a problem statement yet, and the first stage goes on defining it
A clean export versus a hundred inconsistent files with typos — a difference of several times
Someone else's by subscription is cheaper to build and billed monthly. Your own on your server costs more up front and less later
An internal tool for ten people and a service people pay for downtime on are priced differently
Who it's for
- →The idea is clear to you, but not how to build it
- →Off-the-shelf services almost fit — and 'almost' is the problem
- →An internal tool: calculations, documents, requests, reporting
- →Working with text and documents through a language model: search, extraction, drafts
- →A prototype to show investors or test on first users
Questions
Why is the price on request rather than a range like everything else?
Because a range here would be a lie. A landing page is a known quantity: so many pages, so many blocks. A 'service for an idea' can turn out to be a three-week prototype or six months of development — and that emerges during scoping, not before it. So it works like this: a free scoping conversation, then a fixed-price estimate for the first stage. If we part ways after it, you leave with a working prototype and documentation rather than promises.
What is search over documents with an LLM, and why would I want it?
A language model on its own doesn't know your contracts, policies or correspondence — and when asked about them, it invents. The fix is called RAG: your documents are cut into fragments, each is turned into a set of numbers (an embedding) and stored in a vector database. A question first retrieves the relevant fragments, and those go to the model as the basis for its answer. You get an answer with a link to the source, so it can be verified. That's what you want if you've accumulated a knowledge base nobody can find anything in.
What will the model cost to run each month?
It's a separate cost line from development, and it's estimated in advance rather than discovered later. Billing is by volume of text processed: a typical internal assistant for a hundred staff runs somewhere between $50 and $200 a month, document search less, a stream of customer enquiries more. During the prototype I measure the real consumption on your data and show you the figure before you commit to development. The service ships with rate limits and spend tracking, so a bug or someone else's bot can't run up a month's invoice.
Can we start small?
That's how it should start, and I suggest it myself. The first stage is a prototype on your data in two to three weeks at a fixed price. It answers the thing that matters: whether the problem is solvable at all, and what a full version would cost. If we part ways after the prototype, you leave with working code, measurements and documentation — material you can take forward yourself or to another contractor.
What if I don't understand the technology?
You shouldn't have to — that's my part of the job. What I need from you is domain knowledge: how the process works today, where it breaks, what a good outcome looks like. Technical choices I explain in plain language, and I always say what we give up by choosing one thing over another. If an off-the-shelf service solves it for a few thousand a month, I'll tell you that instead of selling you development.
Who owns the result, and will I be locked in?
Code, diagrams, documentation and every credential are yours from day one — the repository is created under your account. I pick a mainstream stack so a replacement developer can be hired rather than hunted. Being locked to a contractor is a risk I'm supposed to remove, not create.
Shall we talk?
Half an hour on a call and you'll have an estimate and a plan. Free, and it commits you to nothing.