u/Fabulous-Pea-5366

A few weeks ago I posted about building an AI research assistant for a German law firm. That post generated 3 warm leads through DMs. One of those leads turned into a paying client.

The new client runs a hotel management company. 500 properties. Around 15,000 customer emails per day. Their support team was manually reading every single one, figuring out what the guest was asking, finding the answer in their FAQ database, and typing a response.

At 15,000 emails per day even if each one takes 3 minutes to handle that's 750 hours of support labor daily. The math is insane.

What they wanted was straightforward in concept but tricky in execution:

Take their hotel FAQs, store them in a vector database so the AI can search through them. Build an agent that reads incoming customer emails, figures out what the guest is asking, matches it against the FAQ knowledge base, and generates a response.

The hard part was the email extraction. Hotel guests don't write clean one-question emails. They write long rambling messages with 4-5 different questions buried in paragraphs of context. Something like "Hi we're arriving on the 14th and wondering about late check-in, also is breakfast included in our rate, and can we get a crib for the baby, oh and is there parking nearby because we're driving from Munich."

That's four separate questions in one email. The system needs to pull each one out individually, find the relevant FAQ answer for each, and compile a response that addresses everything. If it only answers the first question the guest writes back asking about the other three and you've doubled your support load instead of reducing it.

So I built an extraction layer that breaks long emails into individual questions, searches the FAQ database for each one separately, and assembles a complete response covering everything the guest asked.

Charged €3,000 for the build. Took about two weeks.

Here's what's interesting about how this happened. The hotel company wasn't looking for an AI vendor. They saw my Reddit post about the legal RAG system and thought "if this guy can handle legal documents with all that complexity, hotel FAQs should be easy." They DM'd me, we had one call, and the deal closed within a week.

That's the power of posting real technical work publicly. I wasn't pitching hotel companies. I was sharing a legal AI case study. But someone in a completely different industry saw it and connected the dots themselves.

Two projects in two months. First one €2,700 (legal research assistant). Second one €3,000 (hotel email AI). Both came from being visible online with real work, not from cold outreach.

The other lesson: I still think I'm undercharging. At 15,000 emails per day even a 20% reduction in manual handling saves this company dozens of support staff hours daily. A €3,000 build fee is nothing compared to that. Third client is getting quoted €8,000+.

A few weeks ago I posted about building an AI research assistant for a German law firm. That post generated 3 warm leads through DMs. One of those leads turned into a paying client.

The new client runs a hotel management company. 500 properties. Around 15,000 customer emails per day. Their support team was manually reading every single one, figuring out what the guest was asking, finding the answer in their FAQ database, and typing a response.

At 15,000 emails per day even if each one takes 3 minutes to handle that's 750 hours of support labor daily. The math is insane.

What they wanted was straightforward in concept but tricky in execution:

Take their hotel FAQs, store them in a vector database so the AI can search through them. Build an agent that reads incoming customer emails, figures out what the guest is asking, matches it against the FAQ knowledge base, and generates a response.

The hard part was the email extraction. Hotel guests don't write clean one-question emails. They write long rambling messages with 4-5 different questions buried in paragraphs of context. Something like "Hi we're arriving on the 14th and wondering about late check-in, also is breakfast included in our rate, and can we get a crib for the baby, oh and is there parking nearby because we're driving from Munich."

That's four separate questions in one email. The system needs to pull each one out individually, find the relevant FAQ answer for each, and compile a response that addresses everything. If it only answers the first question the guest writes back asking about the other three and you've doubled your support load instead of reducing it.

So I built an extraction layer that breaks long emails into individual questions, searches the FAQ database for each one separately, and assembles a complete response covering everything the guest asked.

Charged €3,000 for the build. Took about two weeks.

Here's what's interesting about how this happened. The hotel company wasn't looking for an AI vendor. They saw my Reddit post about the legal RAG system and thought "if this guy can handle legal documents with all that complexity, hotel FAQs should be easy." They DM'd me, we had one call, and the deal closed within a week.

That's the power of posting real technical work publicly. I wasn't pitching hotel companies. I was sharing a legal AI case study. But someone in a completely different industry saw it and connected the dots themselves.

Two projects in two months. First one €2,700 (legal research assistant). Second one €3,000 (hotel email AI). Both came from being visible online with real work, not from cold outreach.

The other lesson: I still think I'm undercharging. At 15,000 emails per day even a 20% reduction in manual handling saves this company dozens of support staff hours daily. A €3,000 build fee is nothing compared to that. Third client is getting quoted €8,000+.

I've now either built or audited four AI systems for legal/compliance work. Different firms, different jurisdictions, different stacks. The failure modes when these systems break in production are weirdly consistent, almost to the point where I can predict which one will hit before I see the system. Writing this up because I think it's useful for anyone building in this space, and also because I keep getting asked the same questions and I'd rather link to one place than answer them piecemeal.

Failure mode one. The system treats all sources as equally credible.

Already wrote this up separately so I won't repeat it in detail. Short version: a legal corpus is a hierarchy, not a flat set of documents. If your retrieval doesn't encode the hierarchy, your system will confidently surface a commentary article over a binding court ruling on close calls, and the senior lawyer will clock the failure on day one and never use the system again. The fix is metadata-based authority weighting at the chunking and re-ranking layers.

Failure mode two. The system has no opinion when sources disagree.

This one is subtler and arguably more dangerous. Real legal questions often have two or more defensible answers depending on which court you're in or which interpretation prevails. A naive RAG system either picks one answer at random based on which chunk happened to retrieve higher, or it tries to synthesize them into a single answer that doesn't actually exist in the law.

Both failures destroy trust. The lawyer reads the answer, knows there are two positions, and either sees that the system picked the wrong one or sees a synthesized answer that no court has ever held. Either way the lawyer learns the system can't be trusted with any question that has nuance, which is most of them.

What to build instead. A disagreement-detection step that runs after retrieval and before generation. If the top retrieved chunks contain materially different positions, the system should explicitly surface that fact. "Two positions exist on this question. The Federal Court of Justice held X. The Munich Higher Regional Court has gone the other way in Y line of cases. Here is the analysis on each." That output is genuinely useful to a lawyer because it matches how they actually think. A confident single answer that papers over the disagreement is worse than no answer at all.

Failure mode three. The system has no way to learn the firm's interpretation.

Every law firm and compliance team has internal positions that aren't in any public source. "We always read this clause to mean X." "Last year we got a regulator question on this and the answer that worked was Y." "Partner Z disagrees with the consensus reading of this regulation and his read has been more accurate in our practice." This knowledge lives in three people's heads and partially in old emails, and it never makes it into a public corpus.

A system that only retrieves from public sources is missing 30 to 60 percent of the actual reasoning the firm uses. So the system gives generic answers and the firm keeps doing the real work in their heads. Adoption stalls within a month because the senior lawyers correctly clock that the system is just a faster version of a public legal database, and they already have those.

What to build instead. An annotation layer where senior lawyers can flag a source with the firm's interpretation, override generic answers with firm-specific guidance, and build up institutional reasoning over time. The annotation layer is the thing that separates a tool from a piece of the firm's actual decision-making infrastructure. It's also the thing that compounds in value: every interpretation a senior lawyer adds today is worth more next year because it's available to every junior associate forever.

The pattern across all three.

Naive legal RAG fails because the legal domain isn't a corpus, it's a hierarchy of trust with disagreements and firm-specific overlays on top. Any system that treats the corpus as flat will pass the demo and fail in real use. Systems that explicitly model hierarchy, disagreement, and firm-specific interpretation tend to stick.

If you're building one of these or evaluating someone else's, the test I'd run is simple: hand it three queries that you know have nuanced answers in your firm's practice, and watch what it does. If it returns confident single answers without surfacing the nuance, the system isn't ready. If it surfaces the disagreement and the firm's prior position on it, you have something worth deploying.

I've now either built or audited four AI systems for legal/compliance work. Different firms, different jurisdictions, different stacks. The failure modes when these systems break in production are weirdly consistent, almost to the point where I can predict which one will hit before I see the system. Writing this up because I think it's useful for anyone building in this space, and also because I keep getting asked the same questions and I'd rather link to one place than answer them piecemeal.

Failure mode one. The system treats all sources as equally credible.

Already wrote this up separately so I won't repeat it in detail. Short version: a legal corpus is a hierarchy, not a flat set of documents. If your retrieval doesn't encode the hierarchy, your system will confidently surface a commentary article over a binding court ruling on close calls, and the senior lawyer will clock the failure on day one and never use the system again. The fix is metadata-based authority weighting at the chunking and re-ranking layers.

Failure mode two. The system has no opinion when sources disagree.

This one is subtler and arguably more dangerous. Real legal questions often have two or more defensible answers depending on which court you're in or which interpretation prevails. A naive RAG system either picks one answer at random based on which chunk happened to retrieve higher, or it tries to synthesize them into a single answer that doesn't actually exist in the law.

Both failures destroy trust. The lawyer reads the answer, knows there are two positions, and either sees that the system picked the wrong one or sees a synthesized answer that no court has ever held. Either way the lawyer learns the system can't be trusted with any question that has nuance, which is most of them.

What to build instead. A disagreement-detection step that runs after retrieval and before generation. If the top retrieved chunks contain materially different positions, the system should explicitly surface that fact. "Two positions exist on this question. The Federal Court of Justice held X. The Munich Higher Regional Court has gone the other way in Y line of cases. Here is the analysis on each." That output is genuinely useful to a lawyer because it matches how they actually think. A confident single answer that papers over the disagreement is worse than no answer at all.

Failure mode three. The system has no way to learn the firm's interpretation.

Every law firm and compliance team has internal positions that aren't in any public source. "We always read this clause to mean X." "Last year we got a regulator question on this and the answer that worked was Y." "Partner Z disagrees with the consensus reading of this regulation and his read has been more accurate in our practice." This knowledge lives in three people's heads and partially in old emails, and it never makes it into a public corpus.

A system that only retrieves from public sources is missing 30 to 60 percent of the actual reasoning the firm uses. So the system gives generic answers and the firm keeps doing the real work in their heads. Adoption stalls within a month because the senior lawyers correctly clock that the system is just a faster version of a public legal database, and they already have those.

What to build instead. An annotation layer where senior lawyers can flag a source with the firm's interpretation, override generic answers with firm-specific guidance, and build up institutional reasoning over time. The annotation layer is the thing that separates a tool from a piece of the firm's actual decision-making infrastructure. It's also the thing that compounds in value: every interpretation a senior lawyer adds today is worth more next year because it's available to every junior associate forever.

The pattern across all three.

Naive legal RAG fails because the legal domain isn't a corpus, it's a hierarchy of trust with disagreements and firm-specific overlays on top. Any system that treats the corpus as flat will pass the demo and fail in real use. Systems that explicitly model hierarchy, disagreement, and firm-specific interpretation tend to stick.

If you're building one of these or evaluating someone else's, the test I'd run is simple: hand it three queries that you know have nuanced answers in your firm's practice, and watch what it does. If it returns confident single answers without surfacing the nuance, the system isn't ready. If it surfaces the disagreement and the firm's prior position on it, you have something worth deploying.

I've now either built or audited four AI systems for legal/compliance work. Different firms, different jurisdictions, different stacks. The failure modes when these systems break in production are weirdly consistent, almost to the point where I can predict which one will hit before I see the system. Writing this up because I think it's useful for anyone building in this space, and also because I keep getting asked the same questions and I'd rather link to one place than answer them piecemeal.

Failure mode one. The system treats all sources as equally credible.

Already wrote this up separately so I won't repeat it in detail. Short version: a legal corpus is a hierarchy, not a flat set of documents. If your retrieval doesn't encode the hierarchy, your system will confidently surface a commentary article over a binding court ruling on close calls, and the senior lawyer will clock the failure on day one and never use the system again. The fix is metadata-based authority weighting at the chunking and re-ranking layers.

Failure mode two. The system has no opinion when sources disagree.

This one is subtler and arguably more dangerous. Real legal questions often have two or more defensible answers depending on which court you're in or which interpretation prevails. A naive RAG system either picks one answer at random based on which chunk happened to retrieve higher, or it tries to synthesize them into a single answer that doesn't actually exist in the law.

Both failures destroy trust. The lawyer reads the answer, knows there are two positions, and either sees that the system picked the wrong one or sees a synthesized answer that no court has ever held. Either way the lawyer learns the system can't be trusted with any question that has nuance, which is most of them.

What to build instead. A disagreement-detection step that runs after retrieval and before generation. If the top retrieved chunks contain materially different positions, the system should explicitly surface that fact. "Two positions exist on this question. The Federal Court of Justice held X. The Munich Higher Regional Court has gone the other way in Y line of cases. Here is the analysis on each." That output is genuinely useful to a lawyer because it matches how they actually think. A confident single answer that papers over the disagreement is worse than no answer at all.

Failure mode three. The system has no way to learn the firm's interpretation.

Every law firm and compliance team has internal positions that aren't in any public source. "We always read this clause to mean X." "Last year we got a regulator question on this and the answer that worked was Y." "Partner Z disagrees with the consensus reading of this regulation and his read has been more accurate in our practice." This knowledge lives in three people's heads and partially in old emails, and it never makes it into a public corpus.

A system that only retrieves from public sources is missing 30 to 60 percent of the actual reasoning the firm uses. So the system gives generic answers and the firm keeps doing the real work in their heads. Adoption stalls within a month because the senior lawyers correctly clock that the system is just a faster version of a public legal database, and they already have those.

What to build instead. An annotation layer where senior lawyers can flag a source with the firm's interpretation, override generic answers with firm-specific guidance, and build up institutional reasoning over time. The annotation layer is the thing that separates a tool from a piece of the firm's actual decision-making infrastructure. It's also the thing that compounds in value: every interpretation a senior lawyer adds today is worth more next year because it's available to every junior associate forever.

The pattern across all three.

Naive legal RAG fails because the legal domain isn't a corpus, it's a hierarchy of trust with disagreements and firm-specific overlays on top. Any system that treats the corpus as flat will pass the demo and fail in real use. Systems that explicitly model hierarchy, disagreement, and firm-specific interpretation tend to stick.

If you're building one of these or evaluating someone else's, the test I'd run is simple: hand it three queries that you know have nuanced answers in your firm's practice, and watch what it does. If it returns confident single answers without surfacing the nuance, the system isn't ready. If it surfaces the disagreement and the firm's prior position on it, you have something worth deploying.

I've now either built or audited four AI systems for legal/compliance work. Different firms, different jurisdictions, different stacks. The failure modes when these systems break in production are weirdly consistent, almost to the point where I can predict which one will hit before I see the system. Writing this up because I think it's useful for anyone building in this space, and also because I keep getting asked the same questions and I'd rather link to one place than answer them piecemeal.

Failure mode one. The system treats all sources as equally credible.

Already wrote this up separately so I won't repeat it in detail. Short version: a legal corpus is a hierarchy, not a flat set of documents. If your retrieval doesn't encode the hierarchy, your system will confidently surface a commentary article over a binding court ruling on close calls, and the senior lawyer will clock the failure on day one and never use the system again. The fix is metadata-based authority weighting at the chunking and re-ranking layers.

Failure mode two. The system has no opinion when sources disagree.

This one is subtler and arguably more dangerous. Real legal questions often have two or more defensible answers depending on which court you're in or which interpretation prevails. A naive RAG system either picks one answer at random based on which chunk happened to retrieve higher, or it tries to synthesize them into a single answer that doesn't actually exist in the law.

Both failures destroy trust. The lawyer reads the answer, knows there are two positions, and either sees that the system picked the wrong one or sees a synthesized answer that no court has ever held. Either way the lawyer learns the system can't be trusted with any question that has nuance, which is most of them.

What to build instead. A disagreement-detection step that runs after retrieval and before generation. If the top retrieved chunks contain materially different positions, the system should explicitly surface that fact. "Two positions exist on this question. The Federal Court of Justice held X. The Munich Higher Regional Court has gone the other way in Y line of cases. Here is the analysis on each." That output is genuinely useful to a lawyer because it matches how they actually think. A confident single answer that papers over the disagreement is worse than no answer at all.

Failure mode three. The system has no way to learn the firm's interpretation.

Every law firm and compliance team has internal positions that aren't in any public source. "We always read this clause to mean X." "Last year we got a regulator question on this and the answer that worked was Y." "Partner Z disagrees with the consensus reading of this regulation and his read has been more accurate in our practice." This knowledge lives in three people's heads and partially in old emails, and it never makes it into a public corpus.

A system that only retrieves from public sources is missing 30 to 60 percent of the actual reasoning the firm uses. So the system gives generic answers and the firm keeps doing the real work in their heads. Adoption stalls within a month because the senior lawyers correctly clock that the system is just a faster version of a public legal database, and they already have those.

What to build instead. An annotation layer where senior lawyers can flag a source with the firm's interpretation, override generic answers with firm-specific guidance, and build up institutional reasoning over time. The annotation layer is the thing that separates a tool from a piece of the firm's actual decision-making infrastructure. It's also the thing that compounds in value: every interpretation a senior lawyer adds today is worth more next year because it's available to every junior associate forever.

The pattern across all three.

Naive legal RAG fails because the legal domain isn't a corpus, it's a hierarchy of trust with disagreements and firm-specific overlays on top. Any system that treats the corpus as flat will pass the demo and fail in real use. Systems that explicitly model hierarchy, disagreement, and firm-specific interpretation tend to stick.

If you're building one of these or evaluating someone else's, the test I'd run is simple: hand it three queries that you know have nuanced answers in your firm's practice, and watch what it does. If it returns confident single answers without surfacing the nuance, the system isn't ready. If it surfaces the disagreement and the firm's prior position on it, you have something worth deploying.

Quick lesson from a project I finished recently that I want to write up because I keep seeing other people make the same mistake.

I built a research tool for a professional services firm. Took me about two weeks. I quoted €2,700 and they said yes immediately, no negotiation. Felt great at the time. A friend who runs a small agency looked at the numbers afterwards and told me I underpriced by 4-5x. The more I sat with it the more obvious it was that he was right. So here's the math I should have run before I sent the quote.

What I did wrong was straightforward. I priced based on what felt like a lot of money to me. I'm in Tbilisi. €2,700 for two weeks of work felt amazing. The problem is that "feels like a lot to me" has nothing to do with what the thing is worth to the buyer. It's just cost-plus pricing wearing a confidence costume.

Here's the math I should have run.

For a professional services firm this is unusually easy because they already think in billable hours. Their team was spending roughly 30 minutes per query doing manual research, somewhere between 8 and 15 queries per day across the team. Call it 50 hours a week of search time. Loaded hourly rate for that kind of specialist is conservatively €60-80, probably higher, but fine. That's €3-4k per week of labor going into manual document search.

The tool brought each query down to under a minute. Even if you assume only 70% of those recovered hours actually convert into billable client work (because not all of it does, some just gets absorbed back into the day), you're still looking at €2,000+ per week the system pays back. Annualized that's north of €100k.

Now put €2,700 next to that number. The build pays itself off in a week and a half. No wonder they didn't push back. I handed them a 35x first-year ROI and acted surprised when they signed.

The general lesson, the way I'd write it up for myself.

Step one is figuring out the annual value the buyer gets. Hours saved a week times their loaded hourly rate times 52. That's the only number that matters when pricing.

Step two is sanity-checking your quote against that number. Anywhere from 10-25% of year-one value is probably reasonable for a build, depending on how much risk you're taking on and how clean the deliverable is. Below that range and you're basically donating margin to the client.

The gut check that I think is the most useful part of all this: if the buyer doesn't push back at all, you priced too low. Some friction is the signal you're at the right number. Total absence of negotiation usually means you were never close to their walk-away price.

One nuance worth mentioning because it came up when I talked this through with people.

Underpricing your first big client isn't always a mistake. €2,700 sails past procurement, doesn't need approval, gets signed off on someone's personal authority. €12k probably triggers three meetings and a budget cycle and an "are we sure" email thread. When you need the case study more than the cash, the cheap-and-fast yes can be the right call. The actual mistake is letting that first price anchor what you quote everyone after.

The one-line version:

If you're building anything where the value to the buyer is measurable in time saved, and you're pricing off what feels like a lot to you, you're almost certainly leaving 3-5x on the table. Buyers aren't pricing your effort. They're pricing what your work gives them back.

Quick lesson from a project I finished recently that I want to write up because I keep seeing other people make the same mistake.

I built a research tool for a professional services firm. Took me about two weeks. I quoted €2,700 and they said yes immediately, no negotiation. Felt great at the time. A friend who runs a small agency looked at the numbers afterwards and told me I underpriced by 4-5x. The more I sat with it the more obvious it was that he was right. So here's the math I should have run before I sent the quote.

What I did wrong was straightforward. I priced based on what felt like a lot of money to me. I'm in Tbilisi. €2,700 for two weeks of work felt amazing. The problem is that "feels like a lot to me" has nothing to do with what the thing is worth to the buyer. It's just cost-plus pricing wearing a confidence costume.

Here's the math I should have run.

For a professional services firm this is unusually easy because they already think in billable hours. Their team was spending roughly 30 minutes per query doing manual research, somewhere between 8 and 15 queries per day across the team. Call it 50 hours a week of search time. Loaded hourly rate for that kind of specialist is conservatively €60-80, probably higher, but fine. That's €3-4k per week of labor going into manual document search.

The tool brought each query down to under a minute. Even if you assume only 70% of those recovered hours actually convert into billable client work (because not all of it does, some just gets absorbed back into the day), you're still looking at €2,000+ per week the system pays back. Annualized that's north of €100k.

Now put €2,700 next to that number. The build pays itself off in a week and a half. No wonder they didn't push back. I handed them a 35x first-year ROI and acted surprised when they signed.

The general lesson, the way I'd write it up for myself.

Step one is figuring out the annual value the buyer gets. Hours saved a week times their loaded hourly rate times 52. That's the only number that matters when pricing.

Step two is sanity-checking your quote against that number. Anywhere from 10-25% of year-one value is probably reasonable for a build, depending on how much risk you're taking on and how clean the deliverable is. Below that range and you're basically donating margin to the client.

The gut check that I think is the most useful part of all this: if the buyer doesn't push back at all, you priced too low. Some friction is the signal you're at the right number. Total absence of negotiation usually means you were never close to their walk-away price.

One nuance worth mentioning because it came up when I talked this through with people.

Underpricing your first big client isn't always a mistake. €2,700 sails past procurement, doesn't need approval, gets signed off on someone's personal authority. €12k probably triggers three meetings and a budget cycle and an "are we sure" email thread. When you need the case study more than the cash, the cheap-and-fast yes can be the right call. The actual mistake is letting that first price anchor what you quote everyone after.

The one-line version:

If you're building anything where the value to the buyer is measurable in time saved, and you're pricing off what feels like a lot to you, you're almost certainly leaving 3-5x on the table. Buyers aren't pricing your effort. They're pricing what your work gives them back.

Quick lesson from a project I finished recently that I want to write up because I keep seeing other people make the same mistake.

I built a research tool for a professional services firm. Took me about two weeks. I quoted €2,700 and they said yes immediately, no negotiation. Felt great at the time. A friend who runs a small agency looked at the numbers afterwards and told me I underpriced by 4-5x. The more I sat with it the more obvious it was that he was right. So here's the math I should have run before I sent the quote.

What I did wrong was straightforward. I priced based on what felt like a lot of money to me. I'm in Tbilisi. €2,700 for two weeks of work felt amazing. The problem is that "feels like a lot to me" has nothing to do with what the thing is worth to the buyer. It's just cost-plus pricing wearing a confidence costume.

Here's the math I should have run.

For a professional services firm this is unusually easy because they already think in billable hours. Their team was spending roughly 30 minutes per query doing manual research, somewhere between 8 and 15 queries per day across the team. Call it 50 hours a week of search time. Loaded hourly rate for that kind of specialist is conservatively €60-80, probably higher, but fine. That's €3-4k per week of labor going into manual document search.

The tool brought each query down to under a minute. Even if you assume only 70% of those recovered hours actually convert into billable client work (because not all of it does, some just gets absorbed back into the day), you're still looking at €2,000+ per week the system pays back. Annualized that's north of €100k.

Now put €2,700 next to that number. The build pays itself off in a week and a half. No wonder they didn't push back. I handed them a 35x first-year ROI and acted surprised when they signed.

The general lesson, the way I'd write it up for myself.

Step one is figuring out the annual value the buyer gets. Hours saved a week times their loaded hourly rate times 52. That's the only number that matters when pricing.

Step two is sanity-checking your quote against that number. Anywhere from 10-25% of year-one value is probably reasonable for a build, depending on how much risk you're taking on and how clean the deliverable is. Below that range and you're basically donating margin to the client.

The gut check that I think is the most useful part of all this: if the buyer doesn't push back at all, you priced too low. Some friction is the signal you're at the right number. Total absence of negotiation usually means you were never close to their walk-away price.

One nuance worth mentioning because it came up when I talked this through with people.

Underpricing your first big client isn't always a mistake. €2,700 sails past procurement, doesn't need approval, gets signed off on someone's personal authority. €12k probably triggers three meetings and a budget cycle and an "are we sure" email thread. When you need the case study more than the cash, the cheap-and-fast yes can be the right call. The actual mistake is letting that first price anchor what you quote everyone after.

The one-line version:

If you're building anything where the value to the buyer is measurable in time saved, and you're pricing off what feels like a lot to you, you're almost certainly leaving 3-5x on the table. Buyers aren't pricing your effort. They're pricing what your work gives them back.

Quick lesson from a project I finished recently that I want to write up because I keep seeing other people make the same mistake.

I built a research tool for a professional services firm. Took me about two weeks. I quoted €2,700 and they said yes immediately, no negotiation. Felt great at the time. A friend who runs a small agency looked at the numbers afterwards and told me I underpriced by 4-5x. The more I sat with it the more obvious it was that he was right. So here's the math I should have run before I sent the quote.

What I did wrong was straightforward. I priced based on what felt like a lot of money to me. I'm in Tbilisi. €2,700 for two weeks of work felt amazing. The problem is that "feels like a lot to me" has nothing to do with what the thing is worth to the buyer. It's just cost-plus pricing wearing a confidence costume.

Here's the math I should have run.

For a professional services firm this is unusually easy because they already think in billable hours. Their team was spending roughly 30 minutes per query doing manual research, somewhere between 8 and 15 queries per day across the team. Call it 50 hours a week of search time. Loaded hourly rate for that kind of specialist is conservatively €60-80, probably higher, but fine. That's €3-4k per week of labor going into manual document search.

The tool brought each query down to under a minute. Even if you assume only 70% of those recovered hours actually convert into billable client work (because not all of it does, some just gets absorbed back into the day), you're still looking at €2,000+ per week the system pays back. Annualized that's north of €100k.

Now put €2,700 next to that number. The build pays itself off in a week and a half. No wonder they didn't push back. I handed them a 35x first-year ROI and acted surprised when they signed.

The general lesson, the way I'd write it up for myself.

Step one is figuring out the annual value the buyer gets. Hours saved a week times their loaded hourly rate times 52. That's the only number that matters when pricing.

Step two is sanity-checking your quote against that number. Anywhere from 10-25% of year-one value is probably reasonable for a build, depending on how much risk you're taking on and how clean the deliverable is. Below that range and you're basically donating margin to the client.

The gut check that I think is the most useful part of all this: if the buyer doesn't push back at all, you priced too low. Some friction is the signal you're at the right number. Total absence of negotiation usually means you were never close to their walk-away price.

One nuance worth mentioning because it came up when I talked this through with people.

Underpricing your first big client isn't always a mistake. €2,700 sails past procurement, doesn't need approval, gets signed off on someone's personal authority. €12k probably triggers three meetings and a budget cycle and an "are we sure" email thread. When you need the case study more than the cash, the cheap-and-fast yes can be the right call. The actual mistake is letting that first price anchor what you quote everyone after.

The one-line version:

If you're building anything where the value to the buyer is measurable in time saved, and you're pricing off what feels like a lot to you, you're almost certainly leaving 3-5x on the table. Buyers aren't pricing your effort. They're pricing what your work gives them back.

A lot of people in my last post asked how I found the German compliance firm. Honestly the answer is pretty boring and that's exactly why I want to write it up. I think most people skip this channel and it's one of the highest converting things I've done.

I didn't run cold email. I didn't write LinkedIn posts that went viral. I didn't have inbound from a website.

I saw a LinkedIn post from an ex lawyer running a small AI agency. He was looking for a developer to help build an internal AI tool for a compliance team that was his client. It wasn't a job listing on a board, just a post in his feed asking if anyone was around to help.

I commented. Then I DM'd him. Two calls later I had the build.

Here's what I think actually mattered.

The first thing was speed. His post had been up for maybe two hours when I saw it. My DM wasn't "interested, here's my portfolio." It was something like "I've built RAG systems for document search before, here's the stack I'd use for this specific problem, here's what I'd watch out for since it's compliance work, happy to hop on a call." That alone filters past everyone who replies with a generic pitch. By the time we got on the call he already trusted I knew what I was talking about.

The second thing was framing. He wasn't hiring an employee, he was trying to solve his client's problem and look good doing it. So I sold to his incentive, not to a job description. "Here's how I'd make this work and make you look credible in front of your client" is a different conversation than "here's my resume."

The third thing was that I had one real reference point. I'd built a smaller RAG project before this one. So I could talk about what worked, what broke, what I'd do differently. One real story is enough. You don't need ten case studies to start. You just need one you can tell with specifics.

What I'd do differently now.

I'd treat LinkedIn job shaped posts as a real channel and check it deliberately. Founders post these constantly. "Looking for someone who can build X for a client", "need a dev for a small AI project", that kind of thing. Response quality is usually low because most people treat it like a job application. If you reply like a freelancer who already understands the problem you're competing against almost nobody.

I'd also keep a saved search for phrases like "looking for a developer", "need help building", "anyone available to build", paired with "AI" or "RAG" or whatever your niche is. These posts decay fast. Speed is most of the win.

So the takeaway isn't "post on Reddit" or "do cold email". Both of those are slower channels with longer feedback loops. The takeaway is that right now, today, there are people on LinkedIn posting that they need someone to build the exact thing you build, and they're getting mediocre responses. Show up fast and specific and you skip prospecting entirely.

Build was €2,700. Retainer is €1,300/month. Acquisition cost was basically zero, plus an hour of writing the DM and the proposal.

Happy to answer questions. Going to write up the pricing mistake separately because it deserves its own thread. Short version: I should have charged €10 to €12k, not €2,700, and the math behind it is pretty simple.

A lot of people in my last post asked how I found the German compliance firm. Honestly the answer is pretty boring and that's exactly why I want to write it up. I think most people skip this channel and it's one of the highest converting things I've done.

I didn't run cold email. I didn't write LinkedIn posts that went viral. I didn't have inbound from a website.

I saw a LinkedIn post from an ex lawyer running a small AI agency. He was looking for a developer to help build an internal AI tool for a compliance team that was his client. It wasn't a job listing on a board, just a post in his feed asking if anyone was around to help.

I commented. Then I DM'd him. Two calls later I had the build.

Here's what I think actually mattered.

The first thing was speed. His post had been up for maybe two hours when I saw it. My DM wasn't "interested, here's my portfolio." It was something like "I've built RAG systems for document search before, here's the stack I'd use for this specific problem, here's what I'd watch out for since it's compliance work, happy to hop on a call." That alone filters past everyone who replies with a generic pitch. By the time we got on the call he already trusted I knew what I was talking about.

The second thing was framing. He wasn't hiring an employee, he was trying to solve his client's problem and look good doing it. So I sold to his incentive, not to a job description. "Here's how I'd make this work and make you look credible in front of your client" is a different conversation than "here's my resume."

The third thing was that I had one real reference point. I'd built a smaller RAG project before this one. So I could talk about what worked, what broke, what I'd do differently. One real story is enough. You don't need ten case studies to start. You just need one you can tell with specifics.

What I'd do differently now.

I'd treat LinkedIn job shaped posts as a real channel and check it deliberately. Founders post these constantly. "Looking for someone who can build X for a client", "need a dev for a small AI project", that kind of thing. Response quality is usually low because most people treat it like a job application. If you reply like a freelancer who already understands the problem you're competing against almost nobody.

I'd also keep a saved search for phrases like "looking for a developer", "need help building", "anyone available to build", paired with "AI" or "RAG" or whatever your niche is. These posts decay fast. Speed is most of the win.

So the takeaway isn't "post on Reddit" or "do cold email". Both of those are slower channels with longer feedback loops. The takeaway is that right now, today, there are people on LinkedIn posting that they need someone to build the exact thing you build, and they're getting mediocre responses. Show up fast and specific and you skip prospecting entirely.

Build was €2,700. Retainer is €1,300/month. Acquisition cost was basically zero, plus an hour of writing the DM and the proposal.

Happy to answer questions. Going to write up the pricing mistake separately because it deserves its own thread. Short version: I should have charged €10 to €12k, not €2,700, and the math behind it is pretty simple.

A lot of people in my last post asked how I found the German compliance firm. Honestly the answer is pretty boring and that's exactly why I want to write it up. I think most people skip this channel and it's one of the highest converting things I've done.

I didn't run cold email. I didn't write LinkedIn posts that went viral. I didn't have inbound from a website.

I saw a LinkedIn post from an ex lawyer running a small AI agency. He was looking for a developer to help build an internal AI tool for a compliance team that was his client. It wasn't a job listing on a board, just a post in his feed asking if anyone was around to help.

I commented. Then I DM'd him. Two calls later I had the build.

Here's what I think actually mattered.

The first thing was speed. His post had been up for maybe two hours when I saw it. My DM wasn't "interested, here's my portfolio." It was something like "I've built RAG systems for document search before, here's the stack I'd use for this specific problem, here's what I'd watch out for since it's compliance work, happy to hop on a call." That alone filters past everyone who replies with a generic pitch. By the time we got on the call he already trusted I knew what I was talking about.

The second thing was framing. He wasn't hiring an employee, he was trying to solve his client's problem and look good doing it. So I sold to his incentive, not to a job description. "Here's how I'd make this work and make you look credible in front of your client" is a different conversation than "here's my resume."

The third thing was that I had one real reference point. I'd built a smaller RAG project before this one. So I could talk about what worked, what broke, what I'd do differently. One real story is enough. You don't need ten case studies to start. You just need one you can tell with specifics.

What I'd do differently now.

I'd treat LinkedIn job shaped posts as a real channel and check it deliberately. Founders post these constantly. "Looking for someone who can build X for a client", "need a dev for a small AI project", that kind of thing. Response quality is usually low because most people treat it like a job application. If you reply like a freelancer who already understands the problem you're competing against almost nobody.

I'd also keep a saved search for phrases like "looking for a developer", "need help building", "anyone available to build", paired with "AI" or "RAG" or whatever your niche is. These posts decay fast. Speed is most of the win.

So the takeaway isn't "post on Reddit" or "do cold email". Both of those are slower channels with longer feedback loops. The takeaway is that right now, today, there are people on LinkedIn posting that they need someone to build the exact thing you build, and they're getting mediocre responses. Show up fast and specific and you skip prospecting entirely.

Build was €2,700. Retainer is €1,300/month. Acquisition cost was basically zero, plus an hour of writing the DM and the proposal.

Happy to answer questions. Going to write up the pricing mistake separately because it deserves its own thread. Short version: I should have charged €10 to €12k, not €2,700, and the math behind it is pretty simple.

When I built an AI research assistant for a law firm, the feature I thought would be a nice-to-have turned out to be the one they use most.

The system has an annotation feature. Any user can select text in a document and leave a comment. Something like "this interpretation was overruled by ruling X in 2024" or "this applies only to NRW, not nationally" or "our firm's position differs, see internal memo Y."

Technically here's what happens. Comments are stored in PostgreSQL linked to the document ID, page number, and selected text. When a query comes in, the system does two things. First it fetches comments attached to the specific documents that were retrieved by vector search. Second it fetches ALL comments across ALL documents regardless of what was retrieved. Both get injected into the LLM's context.

The second part is important. If a senior lawyer annotated document A saying "this is outdated" but the query only retrieved documents B and C, the system still sees that annotation through the global comments injection. The cache refreshes every 60 seconds so new comments are picked up almost immediately.

The prompt tells the model to treat these annotations as authoritative expert notes and to prioritize them when they contradict the document text.

Why this matters more than I initially thought:

Legal knowledge goes stale. A court ruling from 2022 might be superseded by a 2024 decision. Without the annotation system you'd need to re-ingest documents, update metadata, maybe re-chunk everything. With annotations a senior lawyer just writes "superseded by X" and the system incorporates that knowledge on the next query. No engineering work needed.

It also captures institutional knowledge that doesn't exist in any document. Things like "our firm interprets this more conservatively than the standard reading" or "client X has specific requirements around this clause." That kind of knowledge lives in senior lawyers' heads and normally gets lost when they retire or leave.

The legal team started using it within the first week without any training. They were already used to annotating PDFs with comments. This just made those comments searchable and part of the AI's knowledge base.

If you're building RAG for any domain where expert interpretation matters (legal, medical, financial, academic), consider building an annotation layer. Better embeddings and fancier retrieval will improve your baseline. But letting domain experts directly correct and enrich the AI's knowledge is a multiplier that no amount of model improvement can replicate.

When I built an AI research assistant for a law firm, the feature I thought would be a nice-to-have turned out to be the one they use most.

The system has an annotation feature. Any user can select text in a document and leave a comment. Something like "this interpretation was overruled by ruling X in 2024" or "this applies only to NRW, not nationally" or "our firm's position differs, see internal memo Y."

Technically here's what happens. Comments are stored in PostgreSQL linked to the document ID, page number, and selected text. When a query comes in, the system does two things. First it fetches comments attached to the specific documents that were retrieved by vector search. Second it fetches ALL comments across ALL documents regardless of what was retrieved. Both get injected into the LLM's context.

The second part is important. If a senior lawyer annotated document A saying "this is outdated" but the query only retrieved documents B and C, the system still sees that annotation through the global comments injection. The cache refreshes every 60 seconds so new comments are picked up almost immediately.

The prompt tells the model to treat these annotations as authoritative expert notes and to prioritize them when they contradict the document text.

Why this matters more than I initially thought:

Legal knowledge goes stale. A court ruling from 2022 might be superseded by a 2024 decision. Without the annotation system you'd need to re-ingest documents, update metadata, maybe re-chunk everything. With annotations a senior lawyer just writes "superseded by X" and the system incorporates that knowledge on the next query. No engineering work needed.

It also captures institutional knowledge that doesn't exist in any document. Things like "our firm interprets this more conservatively than the standard reading" or "client X has specific requirements around this clause." That kind of knowledge lives in senior lawyers' heads and normally gets lost when they retire or leave.

The legal team started using it within the first week without any training. They were already used to annotating PDFs with comments. This just made those comments searchable and part of the AI's knowledge base.

If you're building RAG for any domain where expert interpretation matters (legal, medical, financial, academic), consider building an annotation layer. Better embeddings and fancier retrieval will improve your baseline. But letting domain experts directly correct and enrich the AI's knowledge is a multiplier that no amount of model improvement can replicate.

When I built an AI research assistant for a law firm, the feature I thought would be a nice-to-have turned out to be the one they use most.

The system has an annotation feature. Any user can select text in a document and leave a comment. Something like "this interpretation was overruled by ruling X in 2024" or "this applies only to NRW, not nationally" or "our firm's position differs, see internal memo Y."

Technically here's what happens. Comments are stored in PostgreSQL linked to the document ID, page number, and selected text. When a query comes in, the system does two things. First it fetches comments attached to the specific documents that were retrieved by vector search. Second it fetches ALL comments across ALL documents regardless of what was retrieved. Both get injected into the LLM's context.

The second part is important. If a senior lawyer annotated document A saying "this is outdated" but the query only retrieved documents B and C, the system still sees that annotation through the global comments injection. The cache refreshes every 60 seconds so new comments are picked up almost immediately.

The prompt tells the model to treat these annotations as authoritative expert notes and to prioritize them when they contradict the document text.

Why this matters more than I initially thought:

Legal knowledge goes stale. A court ruling from 2022 might be superseded by a 2024 decision. Without the annotation system you'd need to re-ingest documents, update metadata, maybe re-chunk everything. With annotations a senior lawyer just writes "superseded by X" and the system incorporates that knowledge on the next query. No engineering work needed.

It also captures institutional knowledge that doesn't exist in any document. Things like "our firm interprets this more conservatively than the standard reading" or "client X has specific requirements around this clause." That kind of knowledge lives in senior lawyers' heads and normally gets lost when they retire or leave.

The legal team started using it within the first week without any training. They were already used to annotating PDFs with comments. This just made those comments searchable and part of the AI's knowledge base.

If you're building RAG for any domain where expert interpretation matters (legal, medical, financial, academic), consider building an annotation layer. Better embeddings and fancier retrieval will improve your baseline. But letting domain experts directly correct and enrich the AI's knowledge is a multiplier that no amount of model improvement can replicate.

When I built an AI research assistant for a law firm, the feature I thought would be a nice-to-have turned out to be the one they use most.

The system has an annotation feature. Any user can select text in a document and leave a comment. Something like "this interpretation was overruled by ruling X in 2024" or "this applies only to NRW, not nationally" or "our firm's position differs, see internal memo Y."

Technically here's what happens. Comments are stored in PostgreSQL linked to the document ID, page number, and selected text. When a query comes in, the system does two things. First it fetches comments attached to the specific documents that were retrieved by vector search. Second it fetches ALL comments across ALL documents regardless of what was retrieved. Both get injected into the LLM's context.

The second part is important. If a senior lawyer annotated document A saying "this is outdated" but the query only retrieved documents B and C, the system still sees that annotation through the global comments injection. The cache refreshes every 60 seconds so new comments are picked up almost immediately.

The prompt tells the model to treat these annotations as authoritative expert notes and to prioritize them when they contradict the document text.

Why this matters more than I initially thought:

Legal knowledge goes stale. A court ruling from 2022 might be superseded by a 2024 decision. Without the annotation system you'd need to re-ingest documents, update metadata, maybe re-chunk everything. With annotations a senior lawyer just writes "superseded by X" and the system incorporates that knowledge on the next query. No engineering work needed.

It also captures institutional knowledge that doesn't exist in any document. Things like "our firm interprets this more conservatively than the standard reading" or "client X has specific requirements around this clause." That kind of knowledge lives in senior lawyers' heads and normally gets lost when they retire or leave.

The legal team started using it within the first week without any training. They were already used to annotating PDFs with comments. This just made those comments searchable and part of the AI's knowledge base.

If you're building RAG for any domain where expert interpretation matters (legal, medical, financial, academic), consider building an annotation layer. Better embeddings and fancier retrieval will improve your baseline. But letting domain experts directly correct and enrich the AI's knowledge is a multiplier that no amount of model improvement can replicate.

I want to share how this works because I think a lot of people overlook professional services firms as clients.

A compliance company in Germany reached out to me. Their team was spending hours every day searching through legal documents manually. Court decisions, regulatory guidelines, internal memos. All PDFs, all searched by hand. Every time a client asked a GDPR question someone had to dig through folders trying to find the right answer.

So I built them an AI research assistant. Their team types a question in plain language and gets an answer pulled directly from their own documents with exact citations. Instead of 30-45 minutes of manual searching they get an answer in under a minute.

The part that made it actually useful for lawyers (and not just another ChatGPT wrapper) is that the system knows which sources matter more. A Supreme Court ruling carries more weight than a random legal commentary. When two courts disagree on the same question the system shows both positions instead of pretending there's one answer. Lawyers won't trust a tool that doesn't do this.

I also built a feature where senior lawyers can leave notes on documents and those notes become part of the AI's knowledge going forward. So if something is outdated or their firm interprets a rule differently they just annotate it and the system learns it permanently. That feature ended up being the one they use most.

Charged €2,700 for the build. Took about two weeks. Now I get €1,300/month for maintenance and updates.

Here's what I learned from this:

The client didn't negotiate on price at all. Multiple people on Reddit told me afterwards that I should have charged €8,000-15,000 for this scope. They're probably right. When your system saves someone thousands per month in labor costs your build fee is a rounding error to them. I priced based on what felt like a lot to me (I'm based in Eastern Europe) instead of pricing based on what it's worth to the client.

Professional services firms (lawyers, accountants, consultants) are great clients because they already understand ROI. You don't need to explain the value. They can calculate billable hours saved in their head during the first demo.

The system I built is reusable. Different firm, same architecture, just load their documents instead. So going from 1 client to 5 is mostly about finding the next client, not rebuilding the product.

My stack for anyone curious: Python, FastAPI, AWS for the AI models, vector database for document search. If you can code and you're looking for a niche, go talk to any professional services firm and ask how much time their team wastes searching through internal documents every week. That conversation usually leads somewhere.

Happy to answer questions if anyone wants to know more about the process.