Your data is in nine systems. Your AI can reach one.
I consolidate your systems into one store you own, then put an AI gateway in front of it that logs every call. The gateway is designed to answer in ten to thirty seconds, depending on the call. The log also tells you how each one was produced, and who asked.
Written for firms of 20 to 300 people with no data engineer. A $9.5K readiness map comes first, and its fee comes off the build. No build is quoted without one.
Why your data is on other people's computers
The last 20 years of software was SaaS, that means storing all of your business data on somebody else’s computer, servers run by special companies like CRMs, payroll systems, internal wikis, ticketing systems, ERPs, code storage. The list goes on. Now to use AI you need to consolidate the data, because it needs to understand permission, who has access to what temporarily or permanently, it needs to understand context because even some small fraction of missing context will lead to the job getting done incorrectly, and this is typically what humans did in the pre-LLM era.
So the job now is to consolidate your data, make it available via MCP, create MCP gateways, create access controls, and here’s the hardest part, consolidating down across vendors in a central place like a database or a data warehouse. There’s no linkages between data. There’s no relationships between data, so you may have a person record in multiple different places and it might be phrased differently, or may have a different email address, and for that you need the evals. The evals will make sure that your data pipeline is properly joining your records.
It’s not a one time job. You have to set it up and monitor it and tweak it, improve it over time as your data changes, and it’s different for every business. An eval suite and an LLM prompt for one law firm or one financial services firm, it’s going to perform differently than for another.
Why joining your data on demand stops working
The current status quo is to use MCPs from all your vendors, connect them to your Claude or OpenAI accounts, and the agents and the LLMs end up joining the data on demand in real time. And it works. It’s working for you today. The problem is that it’s brittle, doesn’t always work, and wastes employee time as they wait for the agent to do repetitive work each time.
Let’s say you ask who is our best performing partner or salesperson. It has to go into at least two or three different systems to understand customer retention, customer acquisition cost, sales cycle, and join that data in real time using very expensive tokens. If that question comes up often, and it does, it’s much more efficient to pre-join the data in your database and deliver that in any form, whether it’s a dashboard, an LLM conversation or an internal report. That artifact generation becomes free. So it’s a trade-off between doing things upfront or doing things on demand. Doing things on demand works today, but it doesn’t scale and it’s very expensive.
Hiring a senior staff engineer to handle this for you is an expensive affair. It’ll cost you at least $400,000 to $500,000 per year all in, and you’ll have the same result, but it comes at a high cost. Without one there are many questions the firm can’t answer now, not without staffing a data scientist for at least four hours to spin up a custom script or a notebook.
Fivetran and Airbyte are excellent pieces of software that excel at moving data in a deterministic way. What they don’t provide is a way for you to fix your data and to enrich it properly. They don’t know your business. Only you know your business.
Two other reasons to do the upfront work
Most companies I talk to have existing systems with imperfect data. You combine these two situations, where you have distributed data and it’s not groomed, so it’s inaccurate or poorly formatted, and that amplifies the problem for an LLM that you’re talking to today. It has to clean up data, cross reference it and join it. But that’s not the ultimate reason why you want to do the upfront work to consolidate and organize your data.
There are two other primary reasons. One is you can build proprietary edges in your business, or advantages in your business, based on clean organized data. So if you’re a law firm looking to organize your client contact to understand what is the next best step for each client, you can build a system that can prioritize client touch points.
If you have all the context correctly put together you can even build proprietary models in the future, once costs come down more significantly. Doing it on demand doesn’t set you up well for a future where the LLMs and the agents do real work. And the benefit of consolidating your data is that questions become much faster and easier to ask.
Three steps, priced before you commit
Each step qualifies the next, and the first one is cheap on purpose. A fixed-fee build quoted without looking at your data is a guess, and you would be paying for the guess.
Readiness map
A document you can hand to your partners. It tells you what is actually true about your data, and what the build will cost. Book that build within thirty days and the whole fee comes off it.
- Every system of record, its owner, and what it holds
- A join map, naming each place your keys disagree and counting the rows
- Data-quality findings as counts, not adjectives
- A go or no-go per source on whether export is permitted, and whether it will still work next year
- Three AI uses reachable in 90 days, and what blocks each one
- A fixed price for the build
Foundation sprint
The build. The sources, the shape the data is joined into, and the tool list are all named in the contract before it starts. That is what makes the fixed fee survivable for both of us.
- One consolidated store in your own cloud account
- Two to four sources extracted, joined and cleaned
- A gateway with authentication, a tool registry and a per-call audit log
- Two or three working tools against real data
- A set of questions with known answers per tool, so accuracy has a number
- Runbook, schema docs, and every credential in your own vault
Run retainer
Keeping it working, and adding to it. Each tier buys a stated number of hours and a response window, because open-ended support is how a monthly fee turns into a second job.
- Pipelines monitored and repaired
- A monthly answer-quality report, from the eval sets
- A monthly report on what the system costs to run
- A new tool or source each quarter from the middle tier up
- Overage at $325 an hour, agreed in writing first
- No data is better than wrong data. I aim for 100% on your top 500, and anything that cannot be matched with confidence goes to a review queue instead of being guessed.
- 24 months of history per source. Deeper backfill is $7,500 a source.
- You procure API credentials and pay any vendor interface fees. Time spent waiting on them moves the schedule day for day instead of eating the budget.
- The build detects and reports data-quality defects. Fixing records inside your source systems stays with you.
- Tools are listed in the contract. Additional ones are $8,500 each.
- Half on signature, 40% at the midpoint, and the last 10% on an acceptance test we write together at kickoff. Not on whether anyone feels satisfied.
You pay to find out what the build costs, then you decide. Nothing about the first step commits you to the second.
Why not just…
…wait for your software vendor to ship this?
Some will. But a vendor's layer only reaches that vendor's own data, and the questions that hurt span two or three systems at once. Where your system of record already has a good data layer, the readiness map says so and the build gets cheaper.
…get an agency to do it?
For a large project an agency is the right call. It will cost several times this and put a junior on your data. The trade here runs the other way: one experienced person at a fixed price, two builds a year. If you need a team, you need an agency.
How you know the answers are right
The ultimate answer is to measure the performance of the system via evals. Enriching data, joining data, having data accessible by the right people at the right time: those are all metrics that can be calculated and shown on a continuous basis.
The evals run continuously, some daily, some weekly. They’re checked by different stakeholders. The first line of attack to get evals in a good place is using a high-quality model in the first place to collect true ground truth data. After that it really depends on the context. If it’s sales data, the sales team should handle or support the evals and the ground truth. If it’s marketing, marketing needs to take care of their side of the house. I build the tools to make that happen.
Heads of IT demand observability, and it’s important to know where data goes to and how. Most firms have data obligations of some sort, and nobody wants to be in the headlines for a data breach.
Clean data does increase model performance. It does unlock real work. This is a must for all small businesses in the new post-AI world.
Who you would be buying this from
I’m Ilya. Mega Labs is me, in the Bay Area.
My day job is AI engineer at a venture firm, where I built the MCP gateway and the pipelines that join and clean the firm’s own data. Before any of that I priced fixed income at Thomson Reuters, then sat on the client coverage desk at Goldman Sachs REDI. That is where I learned what a regulated firm’s controls actually ask for, and in my experience that is rarely what a vendor’s security page claims. I founded Celery, a bitcoin wallet and dealer, and ran it until 2017. From 2018 to 2022 I was a senior engineer at Voyager, a crypto brokerage, and then a senior technical program manager at Cruise.
- It runs in your cloud account, under a role you grant and can revoke whenever you want
- You own the data, the entity model, the tool definitions and the eval cases
- I do not train on your data, and nothing from your systems gets quoted to another client
- Credentials end up in your vault, not just mine
- I check export and retention rights per source before building on them, because a source you cannot legally keep is one the build has to route around
- The price is fixed. The scope is in the contract, including what it excludes
- This is a side practice. Two builds a year, and the schedule says so in business days rather than calendar weeks.
- No business-hours service level and no on-call. Response windows are next business day, best effort. A firm that needs same-hour response should not buy this.
- No SOC 2 report, and no date for one. Your data stays in your account, which is the closest I can get today.
- No named client references yet. The design-partner rate exists to fix that, and it trades a lower price for a case study and reference calls.
- No PHI and no cardholder data. A practice this size cannot carry that scope honestly.
Security questions and architecture review go to ilya@megalabs.co. I answer those myself.
Find out what your data is actually like before you budget for it.
A $9,500 readiness map, delivered in ten business days. The fee comes off the build if you book one within thirty days, and if the map says the build is a bad idea it will say so.
- Days one to fourSystems in, keys checked
We walk each system of record together, then run the join analysis against your top 500 clients, projects or matters. The count of places two systems disagree about the same thing is what decides the build price.
- Days five to tenVerdict, uses, price
A go or no-go per source on whether export is permitted and durable, which protects you from building on an API your vendor can close. Then a fixed price for the build, naming the exact sources, records and tools it covers.
- Read access only, or a guided screen share if you would rather not issue credentials. Nothing is changed in any source system.
- Your data stays in your systems. Only summary statistics and counts appear in the document.
- No training on your data, no benchmarking on it, and nothing from it quoted to anyone else.
- Sign a mutual NDA before the kickoff call. If your terms differ from mine, send yours.
- If the map concludes you should not do the build, that is what it will say, and you keep the document.