The engineering decision that made the product affordable
The defining constraint in the client engagement was concrete: a US-based startup with $2 million in funding, a six-week delivery window, and $50,000 available for a complete parsing iteration over a corpus of more than one million financial documents.
The first high-accuracy approach used LlamaParse and was estimated at $120,000 for that iteration. The move to Mistral models reduced the equivalent cost by 60%, to approximately $48,000, with a modest accuracy trade-off that was acceptable for the initial release.
The product combined financial document retrieval with source-grounded answers and paragraph-level inspection. The client subsequently raised further funding, with this product part of the startup’s progress.
This is the business story behind the architecture. It is also a useful way to judge whether technical work is solving the right problem.
The result has three different dimensions
First, there was a delivery result: a hedge fund equity analyst platform was built around a large financial corpus and an analyst’s need to inspect evidence.
Second, there was an economic result: the parsing estimate was brought within the iteration budget. The reduction was $72,000 relative to the original estimate for the same document set.
Third, there was a product capability: answers could be connected to specific passages and displayed through a document viewer. That capability addresses the cost of verifying an answer, which matters even when the retrieval and generation services are fast.
Keep these outcomes separate. A parsing saving is not recurring revenue. A successful funding round is not a measured model-quality score. A citation interface is not proof that every generated claim is correct. Each outcome has its own evidence and its own next measurement.
Affordability changes the iteration loop
A $120,000 parsing iteration against a $50,000 budget does more than create a procurement problem. It limits the team’s ability to change the corpus, improve extraction rules or recover from a mistake.
At approximately $48,000, the iteration became feasible. The remaining $2,000 still required discipline. Artifact reuse, incremental processing and controlled retries are therefore business capabilities expressed through engineering.
A useful product budget separates:
| Cost category | Main driver | Engineering control |
|---|---|---|
| Source acquisition | Coverage and provider agreements | Incremental sync, deduplication |
| Parsing | Pages, complexity, retries | Routing, cached artifacts, selective reparse |
| Embedding | Tokens and model execution | Batch inference, reuse, versioned migrations |
| Search infrastructure | Vector count, payloads, replicas | Chunk policy, storage/index choices |
| Interactive answers | Queries, evidence tokens, tool calls | Task routing, bounded context and agents |
| Review and operations | Failures, regressions, incidents | Evaluation, observability, runbooks |
Optimising one line can move cost to another. Cheaper parsing may increase review. Smaller chunks may improve retrieval but increase vector count. A more capable agent may answer difficult questions while consuming several retrieval and model calls.
The system should be evaluated on the cost of a completed, supported task.
Measure analyst value where work happens
The relevant business question is whether the analyst can complete a research task with less effort while retaining confidence in the evidence.
A practical measurement plan records:
- Time from question to first useful source.
- Time to a completed answer that passes review.
- Time spent verifying citations.
- Number of manual source searches still required.
- Fraction of tasks completed without material correction.
- Coverage of required issuers, periods and document types.
These should be measured on comparable tasks with a defined baseline. Do not infer “hours saved” from a faster API response. An answer that arrives in seconds but requires extensive correction can increase total work.
A paired workflow study can have analysts complete similar tasks with and without the tool, counterbalancing order and reviewing the final research output. Collect both timing and error categories. Record where the system helps and where manual reading remains faster.
A cost-per-accepted-task model
Suppose a worked monthly scenario costs $6,000 to operate and produces 20,000 answers. The raw cost is $0.30 per answer. If only 75% meet the task acceptance standard, the infrastructure cost per accepted answer is $0.40 before analyst review time.
from decimal import Decimal
def cost_per_accepted_task(monthly_cost, answers, acceptance_rate):
cost = Decimal(str(monthly_cost))
rate = Decimal(str(acceptance_rate))
if cost < 0 or answers <= 0 or not Decimal("0") < rate <= Decimal("1"):
raise ValueError("Invalid cost or task volume")
return cost / (Decimal(answers) * rate)
assert cost_per_accepted_task(6000, 20000, "0.75") == Decimal("0.4")
This is an illustration of the accounting method, not a client operating result. It shows why throughput alone is an incomplete business metric. Improving acceptance can matter as much as reducing model price.
For a full total-cost view, include amortised ingestion, storage, support and review. If the corpus is refreshed frequently, a low query price can coexist with a large ongoing ingestion bill.
Keep the funding story precise
The client went on to raise further funding. The product formed part of that progress: a working analyst platform, a large financial corpus, inspectable evidence and an ingestion approach that could fit the available budget.
That is a meaningful outcome without inventing an investment amount, a valuation or a claim that one engineering change caused the financing. The earlier $2 million describes the startup’s funding context during the work; it is not the amount of the later round.
For a portfolio reader, the valuable signal is the connection between customer requirements, technical decisions and a viable product. The architecture is stronger when the reason for each component is visible.
What deserves priority in a new iteration
A new build in September 2026 should retain the evidence-first architecture while evaluating current components. The highest-value next steps are concrete:
| Improvement | Why it matters | Evidence required before release |
|---|---|---|
| Parser output with native source regions | Less fragile citation alignment | Span and table accuracy on financial pages |
| Selective parsing escalation | Control corpus cost without uniform quality loss | Routing recall and cost/quality curves |
| Better chunk and embedding contracts | Prevent truncation and representation mismatch | Task-complete retrieval recall |
| Bounded agentic research | Support multi-step analyst questions | Gain over fixed RAG within time and cost limits |
| Stronger temporal and access scope | Correct source availability and entitlements | Negative tests and historical-query cases |
| Evidence-chain evaluation | Diagnose regressions before promotion | Paired results by failure category |
These improvements should not all be introduced in one unmeasured release. Establish a baseline, change one major component, inspect regressions and preserve rollback.
A reusable delivery framework
The sequence from this project is useful beyond financial research:
- Define the end user and the task they need to finish.
- Translate that task into evidence and acceptance requirements.
- Build a complete path from source to inspectable answer.
- Measure the expensive and unreliable stages.
- Change the component that limits feasibility.
- Review the quality trade-off with the customer.
- Make the result repeatable through versioning, evaluation and operations.
For the client, the limiting component was initially the parsing economics. Solving it required understanding the role of parsing in the entire evidence chain. Choosing a cheaper model in isolation would not have been enough if it broke tables, citations or the analyst’s ability to verify the answer.
My contribution
My contribution covered the client-facing requirements, architecture and implementation across the RAG pipeline and source-inspection experience. The work connected a six-week delivery constraint with a million-document product, including the move from a $120,000 parsing estimate to approximately $48,000 and the quality trade-off needed for an acceptable initial release.