Founder's build log
A personal, chronological record of how the product is being built — the decisions, experiments, mistakes and moments that changed its direction. Written by me as the founder and originator of AR3S.
Timeline
Month headings provide the wider context. Full entries are shown directly on the timeline — read them in sequence or simply scroll past the ones that matter less to you.
The first concept was an LLM-based tool intended to help expert witnesses prepare more structured and complete opinions. Its working name was TRACTUS. The product was meant to help create better expert material rather than analyse someone else’s work.
After thinking it over for some time, I came to the conclusion that a far better idea than a system helping experts draft their reports would be software designed to analyse completed expert reports and identify errors in them. It seemed to me that such a system would not only be easier to build, but also much easier to commercialise.
From my own work, I knew that lawyers often struggled to find the right arguments against specialist medical expert reports. Sometimes they asked a doctor they knew for help, but more often they tried to do it on their own — with mixed results.
A tool for analysing completed reports also seemed easier to defend from a legal and regulatory perspective. An AI system helping an expert draft a report — the original TRACTUS concept — would almost certainly raise far more concerns than a tool supporting the assessment of a document that had already been prepared.
That is how the concept of AR3S emerged.
Meeting Bartek from WAIT (Wrocław AI Team) was my first serious confrontation with the realities of building a startup. We talked about pre-acceleration programmes, incubators, finding a CTO, and how the AI and startup ecosystem works in practice.
To my surprise, it turned out that Wrocław already had a fairly active AI community — something I had barely been aware of before. It was also through this conversation that I was introduced to Kuba, whom I was advised to contact for more detailed guidance on the technical side of the project and on finding a CTO.
I begin actively looking for a CTO and speaking with founders, developers, and people who support early-stage startups. In January, I also submit AR3S to its first pre-acceleration programme. It is a fairly busy month after weeks spent only planning the system in theory.
The contact from Bartek leads to a conversation with Kuba. I gain more practical information about recruiting a technical co-founder, the realities of software work and building a product at a very early stage. A few weeks later this contact will prove crucial to the story of AR3S.
Both Bartek and Kuba suggested that I should get in touch with Startup Wrocław. I was not entirely sure what kind of help I could expect from the organisation, but it quickly became clear that reaching out had been worthwhile.
My conversation with Maciej helped me organise the next steps. I received specific introductions, recommendations for relevant events, and a much clearer idea of where to look for people who could help move the project from an idea towards implementation.
Their friendly and enthusiastic response to my idea, together with the extent of the support I received, further strengthened my belief that the project might genuinely make sense. I still did not have a CTO, but the search was no longer random.
Maciej from Startup Wrocław gets me into AI Tinkerers Poland & GDG #2, which happens to be taking place in Wrocław at the time, so that I can look around for a potential CTO and get to know the AI community a little better.
The atmosphere surprises me: lively discussions, spontaneous conversations with complete strangers, and a quick exchange of contacts — completely different from the medical conferences I had attended up to that point.
I tell several developers about AR3S. Some of them claim that a prototype could be built over a weekend, which is very different from my earlier estimates of several weeks. Those estimates had mostly come from LLMs — I did not yet have enough technical knowledge to assess them properly myself.
Where did the difference come from? Most likely, everyone had a slightly different understanding of the word “prototype”.
Maciej from Startup Wrocław also arranges a short online meeting for me with Piotr from CTT (Catch The Tornado). The conversation gives me several concrete pointers on how to build the product: narrowing the initial scope, testing the most important assumptions with the simplest possible prototype, and avoiding the trap of trying to perfect everything at once too early.
Piotr also suggests an interesting idea involving the use of logic graphs in the system. At the pre-MVP stage, it sounds far too complex, but I make a note of it as something that may be worth returning to in the future.
Once again, I am impressed that a complete stranger is willing to give up his own time to help me work on AR3S.
A lot changes. In February, I finally manage to connect with a potential developer — perhaps even a future CTO. I tell Mateusz about the entire concept behind AR3S, the experiments I have carried out so far, and what I am actually trying to build. Together, we begin to organise the system’s assumptions, testing approach, and direction of development.
At the outset, I suggest signing a standard NDA. Mateusz is not particularly enthusiastic about the idea. He says that if he is going to join the project, he would prefer to feel like a co-founder rather than a subcontractor executing someone else’s concept. It makes me slightly nervous because, in practice, I have to place my trust in someone I have only just met. On the other hand, I was mainly looking for a developer who could help me build a prototype, and now it seems I may have found someone willing to consider joining AR3S as a co-founder. That is far more than I initially expected. We agree that intellectual property, equity, roles, and the rules of our future cooperation will eventually need to be formalised, but at this very early stage we begin with trust.
Interestingly, before the actual application even exists, we write down several principles that we want to follow from the start. Every analysis run should leave as complete a trace as possible: input data, intermediate outputs, the version of the instructions used, the model, parameters, and execution time. Prompts should be versioned in a similar way to code, so that we can determine why the system’s behaviour changed between successive tests. We also want to avoid permanently tying AR3S to a single model provider, even if the first MVP uses only one.
At the same time, we consciously try not to overcomplicate the architecture. The MVP should be as simple as possible, easy to improve, and resilient to common failures — not designed from day one to serve a million users. Individual stages should save their outputs so that, after an error, the analysis can be resumed rather than restarted from the beginning. We also validate input data and output structures so that one damaged element does not create silent errors later in the process.
From the outset, we also assume that AI-generated output should remain working material rather than an autonomous decision made by the system. AR3S is intended to support the human user, not take over their responsibility or pretend that the model is always right.
We decide to bootstrap the project up to the MVP stage before seeking larger-scale funding. We still do not know whether the entire idea will actually work, but for the first time we have not only a general concept, but also a team and a jointly agreed set of principles for building it.
Kuba introduces me to Mateusz — a programmer and potential CTO candidate. I tell him about the problem I am trying to solve, the experiments so far and the general idea for building the system.
Another in a series of meetings arranged by Maciej — this time with Michał from bards.ai. Michał shows me a somewhat different perspective on building an LLM-based system. In his view, it is worth simplifying the overall process and checking whether individual tasks can be handled in fewer steps, rather than automatically expanding the architecture.
This touches on one of the fundamental dilemmas in building AR3S. I am naturally drawn towards more complex systems. Breaking the analysis into smaller, controlled stages makes it easier to observe how the LLM behaves, identify the sources of errors, and limit situations in which the model is expected to complete an entire task in a single, opaque run.
On the other hand, every additional layer increases cost, processing time, the number of potential failure points, and the difficulty of maintaining the system. I begin to wonder where the right balance lies: how to preserve control, auditability, and analytical quality without building an architecture that is more complicated than the problem actually requires.
I do not yet have a good answer. This dilemma will return repeatedly over the following months.
I decide to write an article on WAD — whiplash-associated disorders, a group of symptoms occurring after an acceleration–deceleration injury to the cervical spine, most commonly associated with road traffic collisions. I am particularly interested in patients who continue to experience genuine functional limitations even though imaging does not reveal significant structural damage. The working title is “Between Structure and Function: Permanent Impairment Following Minor Spinal Injuries”.
The first objective is purely substantive. There has long been considerable conceptual confusion surrounding minor spinal injuries, permanent impairment and the significance of functional limitations. I want to organise my own position, bring together the medical arguments and confront them with the legal perspective.
I will not pretend, however, that there is no second objective. A strong publication in a legal journal could help me build recognition and credibility among lawyers handling personal injury cases — precisely the community that AR3S is intended to reach in the future.
For an article of this kind to be genuinely useful to lawyers, it would be best to write it together with someone who understands these cases from a procedural perspective. I therefore publish a LinkedIn post inviting potential collaborators, hoping that a lawyer interested in preparing the article together will come forward.
I decide to test whether the pipeline assumptions make sense before there is even a working system. Mateusz is still getting up to speed on the project, so at this stage there is no application, no automation, and no convenient interface. There is only a process design and the need to find out whether its individual steps can actually be connected into a coherent whole.
I run the entire process manually. Each stage is executed separately in a new LLM call, using its own prompt and prepared context. I copy the output from one step, organise it, and pass it on as input to the next. It is fairly tedious and takes several hours, but for the first time I can follow the entire process from beginning to end rather than assessing individual components in isolation.
The result is not yet a product, but it is useful enough to confirm the most important assumption: the successive stages of the analysis can be combined into a coherent pipeline that produces more than a single prompt sent to a model. For the first time, AR3S stops being just a diagram in my notes. It begins to work — manually, slowly, and very awkwardly, but it works.
Bartek introduces me to Sebastian, a VC investor. From the outset, I make it clear that this is not an investment conversation — there is barely a product yet, and what I am primarily looking for is guidance on what I should do next.
Sebastian very clearly shifts my thinking towards the market: the sooner I show even an imperfect version to potential customers, the better. In his view, I should not wait until everything is polished. The first step is to find out whether lawyers genuinely recognise the problem, want to use the solution and — most importantly — are willing to pay for it.
He also sends me specific materials and tools, including resources on Lean Startup and the Value Proposition Canvas. After this conversation, “traction” moves to the very top of the priority list for our work on AR3S.
I attend WAIT AI4LAW, a meetup co-organised by Bartek and devoted — as the name suggests — to the use of AI in legal practice. Since I am building a tool for lawyers, I need to better understand how they think about AI, implementation, and the risks involved.
One of the speakers is Maria, a lawyer specialising in the legal aspects of AI implementation. During the break, I manage to speak with her briefly about my idea, the future legal requirements surrounding it, and compliance. It quickly becomes clear that this area will require much deeper analysis.
The ever-reliable Maciej is there as well.
After several weeks of manual trials, the method is organised enough for Mateusz to begin implementation. From this point on, the assumptions can be tested not only in isolated experiments but through an increasingly repeatable system process. The project enters a stage of regular engineering work.
A small but important step: the first internal specification of the MVP pipeline is created. I map out the successive stages of the analysis, their goals, operating assumptions, expected inputs and outputs, as well as the prompts and the history of changes introduced over time.
The document is intended to serve as a map of the system for the CTO and as a shared point of reference: what each component is supposed to do, which assumptions are currently valid, and why particular changes were made in successive versions.
As a result, knowledge about AR3S is no longer scattered across conversations, notes, and isolated experiments. Proper product documentation begins to emerge, making it possible to translate my domain concept into a concrete implementation.
From today, I am no longer seeing patients on Thursdays. I need a regular block of time to work on AR3S, test successive versions, and prepare materials for Mateusz. I still devote part of the time I have freed up to my ongoing work on court expert reports, but for the first time I am deliberately reducing my medical practice to make room in the week for building the product.
It is a small change in the calendar, but a fairly significant decision. AR3S is beginning to cost me not only my free time and money burned on tokens, but also some of the income I am giving up so that the project can move forward faster.
Mateusz is building the first working parts of the application, while I find myself doing something I had not anticipated: spending less and less time designing the ideal system, and more and more time analysing its very specific failures. Every new test brings another round of corrections.
Sometimes the model fails to follow the expected format. At other times, it evaluates similar data differently depending on where they appear in the material. Repetitions emerge, along with edge cases and difficulties distinguishing between elements that look very similar but actually mean different things. It also becomes increasingly clear that an error made at the beginning of the analysis can affect the entire downstream result.
One of the first auxiliary evaluation mechanisms begins to create more noise than value in practice. Instead of trying to refine it indefinitely, we move it away from the main development path. We do not remove it completely — we continue collecting its outputs experimentally, because they may prove useful in the future. For now, however, we have more important problems to solve.
At the same time, it becomes clear just how important proper preparation of the source material is. If the system divides a document incorrectly, merges two separate problems, or overlooks an important fragment, it may later do an excellent job of analysing a badly defined problem. We therefore devote increasing attention to making the entire process traceable, comparing successive versions, and treating every change cautiously when it may affect the final result.
April is the point at which AR3S stops being a simple sequence of well-written prompts and begins to behave like a real product: regressions appear, compromises become necessary, dead ends emerge, and decisions increasingly have to be based on testing rather than intuition alone.
The first AR3S pitch deck begins to take shape. It is not yet ready to be sent to anyone, but it forces us to describe the project in the language of the market: the customer’s problem, the business model, our advantage and the go-to-market plan. For the first time, we are looking at AR3S not only as a system that needs to be built, but also as a potential company.
I find the first publicly available data on the number of legal proceedings involving expert opinions. We use it to make a rough top-down estimate of the potential market. It quickly becomes clear, however, that the number of cases alone tells us very little about how many analyses could actually be purchased.
We therefore begin to look at the market from the bottom up as well: how many law firms handle cases requiring the assessment of medical expert opinions, how many such cases each firm handles, and how often lawyers might realistically use AR3S. At this stage, these are still very preliminary estimates, but for the first time we are trying to turn the general belief that “the market should be large” into numbers that can later be tested.
I also begin to examine the potential competition more carefully. The legal AI market turns out to be crowded, but most tools focus on information retrieval, document analysis and summarisation, chronology building, research or drafting legal documents. Some products are more specialised in personal injury cases and medical records, but even there the emphasis is mainly on organising information and generating documents.
At this stage, I cannot find one obvious equivalent of AR3S. I am not yet sure, however, whether this really means there is no direct competition, or whether we simply have not searched thoroughly enough.
At this stage, there are clearly fewer meetings and interesting conversations, and considerably more tedious work on refining AR3S. The system now covers an increasingly large part of the planned analysis, but the cost of a single full run reaches several dozen dollars.
It therefore looks as though quality alone will not be enough. The product must also be stable, economically viable, and possible to sell at a price acceptable to law firms. A full analysis takes quite a long time, which we expected, but this seems to be the smaller problem. AR3S is not meant to be a chatbot, so even waiting several hours may be compatible with the way lawyers work (perhaps).
Alongside AR3S, I am also working this month on an article entitled “Between Independence and Procedural Caution: On the Systemic Incentives Influencing Court Experts’ Opinions”, intended for submission to the Polish journal “Problemy Współczesnej Kryminalistyki”. In theory, this is a separate project, but in practice the two subjects are closely connected. Writing about the systemic problems surrounding expert evidence makes me see even more clearly the difficult environment in which lawyers, expert witnesses and courts operate — and why a tool such as AR3S may be needed.
In May, I also begin cautiously confronting the idea with the market. I speak to several lawyers from my professional circle about the difficulties involved in assessing medical expert reports and ask whether they could see a use for a tool like this. The reactions are generally positive, but I quickly realise that these are not yet conversations conducted in the spirit of The Mom Test. I spend too much time talking about AR3S and asking what they think of the idea, and too little asking about their most recent cases, their current working methods, and situations in which they genuinely needed help. I therefore treat these conversations as an initial sign that the problem is recognisable — not as evidence of traction. But everyone has to start somewhere.
I also begin to consider changing the system’s name, but every sensible idea that comes to mind — including Adverso and Epistemic — turns out to have been taken for a long time. :/
After weeks of designing, building and testing individual components, we manage to run the full AR3S MVP for the first time.
The output is still very rough. There are repetitions, incorrect assessments, formatting problems and many sections that require improvement. Even so, the system completes the entire planned process and, for the first time, produces a result that can be assessed as a whole. Among the noise are specific weaknesses in the expert report that could genuinely matter to a lawyer.
The most important reaction, however, comes from Mateusz. Until now, he has approached the project cautiously — as an interesting idea that might just as easily fail. After seeing the first result, he says that he is beginning to genuinely believe that AR3S addresses a real problem and could succeed.
This is probably the first moment when the project no longer rests solely on my conviction and a set of promising assumptions. We still have an enormous amount of work ahead of us, but for the first time, something actually works.
As we get closer to working with real materials, another kind of risk becomes obvious: medical data, lawyers’ professional secrecy and the rules for using external models. We decide that legal compliance must be part of the product from the beginning and commission an external audit. At the same time, we shorten the testing loop so that sources of failure can be isolated without running the full analysis every time. I am still looking for a new name for the system.
After many iterations, several areas reach the limits of classic prompt engineering. The instructions become so long and elaborate that adding another rule can weaken adherence to earlier ones: the model omits requirements, applies them selectively or fixes one type of error at the expense of another.
Despite further attempts, it is difficult to find a stable sweet spot. We do not yet know whether a stronger model will solve the issue or whether the approach itself must change. It is the first clear signal that further development cannot rely solely on making instructions longer.
My conversation with Maria during AI4LAW does not end with a brief exchange during the break. We commission Lubasz i Wspólnicy to conduct a legal audit of AR3S.
We send the firm detailed materials describing how the system works, while I answer numerous questions concerning, among other things, the data being processed, the use of external models, file storage, the responsibilities of the parties, and the planned way in which the service will be made available to law firms. Each answer leads to further questions, and it quickly becomes clear that simply describing the product properly for the purposes of the audit is already quite a substantial task.
Mateusz is not initially convinced that, at such an early stage, it is worth spending a considerable amount of money on a legal audit — particularly for a project financed out of our own pockets. I understand his doubts. The audit does not add a new feature, improve the results, or accelerate the development of the MVP. The same money could have been spent on further product development.
Even so, I believe it is worth doing now. AR3S is intended to analyse materials containing sensitive medical data and to be used by lawyers. Postponing questions about data protection, the rules governing the use of models, contracts, and liability until the product is already finished could mean having to rebuild solutions that we are only now creating.
I do not yet know how complicated implementing all the recommendations will prove to be. I would rather identify the problems now, while many things can still be changed relatively easily, than discover them only shortly before the first pilot.
Besides, without properly addressing the legal issues, we cannot responsibly begin even preliminary testing on real court cases. And, as we established earlier, gaining the first signs of genuine traction is supposed to be one of the priorities in the development of AR3S.
We test stronger models expecting a straightforward improvement in quality. The result is more complicated: most areas improve, but not enough, and in one area the stronger model actually performs worse. At the same time, stability problems and repeated runs become more frequent. We suspect this may partly be caused by instability in the LLM we are using at the time — Gemini.
I am still searching for a smarter name for the system and slowly accepting that “AR3S” may stay with us after all.
The pace of iteration increases. Every test brings more changes, edge cases and product decisions, but Mateusz develops AR3S alongside his regular work. The queue of changes grows faster than we can implement them. For the first time, I seriously consider starting conversations about a small round earlier than planned. Its purpose would be to finance greater technical involvement from the CTO and bring the product to pilots. We have not yet decided on the eventual working arrangement, but it is becoming clear that the next stage will require greater technical availability.
At the same time, I experiment with the language used in model instructions: Polish, English or a mixture of both? There is surprisingly little information on this, although some results suggest that the language of an instruction can genuinely matter.
The meeting with Maria from Lubasz i Wspólnicy is the formal discussion of the AR3S legal audit. I have been worried that working with medical data and litigation materials might make some of our ideas too risky or legally unworkable. Fortunately, the conclusion is much more optimistic: the system can be implemented in the planned form, provided that data-processing rules, agreements, safeguards and user communication are designed properly from the outset.
Importantly, we also receive a green light for the planned module supporting litigation strategy. We had not been sure whether we could suggest which actions a client might consider in a particular case. It turns out that we can — provided the role of the system is properly defined, professional oversight is preserved and it is made clear that AR3S supports the lawyer’s decision rather than making it. This is a major relief and one of the most important moments in the project.
From the beginning, one basic concern follows us: could a similar result be obtained simply by giving the material to the strongest general-purpose model? We prepare a controlled case containing 20 deliberately introduced, often subtle errors. AR3S and Claude Opus 4.8 receive the same material and the outputs are manually compared with a control map.
AR3S fully detects 15 errors and partially detects 2 more, scoring 16/20. Claude fully detects 13 and partially detects 1, scoring 13.5/20. It is only one synthetic test and the system still needs work, but the main hypothesis passes its first test: a specialist process can outperform a strong general LLM used on its own.
I show the raw analytical output to a lawyer working, among other things, on accident compensation and medical malpractice cases. The material comes from a synthetic case containing deliberately introduced problems. In his view, the analysis itself looks interesting, but the way the results are presented is too chaotic.
He is right — the layer that organises the output is still provisional and, among other things, similar findings are not yet aggregated. We schedule another meeting for August, when there should be a more useful report to show.
I radically rebuild and simplify the instruction used in one of the most important and difficult areas of CEM. It takes half a day, but the improvement is clear: fewer mistakes, clearer answers and better adherence to the key requirements. It confirms the lesson from June — development does not always mean adding another rule. Sometimes complexity has to be removed, priorities clarified and the instruction rebuilt from scratch. This is the direction.
On LinkedIn I come across information about European work on a large, open language model covering all official EU languages. This could matter for AR3S. Such a model might reduce the cost of less demanding parts of the analysis and, because of its stronger emphasis on European languages, perform better than English-first models on some tasks.
Even if it does not match the strongest American models in the most complex stages, it could become a useful layer of a European technology stack. In the longer term, that would be especially interesting when AR3S enters other CEE markets.
Moving to OpenAI models makes us slightly nervous because the listed price per token is higher. We therefore expect a full analysis to become even more expensive. The opposite happens: the system’s results improve markedly, while the cost of a complete run falls to roughly one third of its previous level.
The biggest surprise is that a more expensive token does not mean a more expensive analysis. More effective use of caching and fewer repeated runs probably make a major difference.
While on holiday, I return to a series of problems that we have been trying to solve separately. I conclude that continuing to adjust individual instructions will not be enough — the organisation of the entire process has to change. The new approach should simplify part of the analysis, improve stability and reduce cost. The pipeline is becoming increasingly complex. I only hope we are still solving a real problem rather than drifting into overengineering.
After several months of working together with a lawyer specialising in personal injury cases, we finish the article on WAD. My medical section is supplemented with a procedural perspective, while the text goes through successive rounds of revisions, additions and rewriting.
At some point, however, a fairly fundamental problem emerges: the article is far too long. It significantly exceeds the standard limit of 40,000 characters, and reducing it to the required length would mean removing a large part of the argumentation that we have painstakingly developed over the previous months.
We therefore contact the editorial team of a widely read legal journal and ask whether we may submit the full version anyway. To our relief, the editors agree to accept the text and send it out for peer review, leaving the question of any necessary cuts until later.
Today, we officially submit the article.
This does not, of course, mean that it will be accepted in its current form. We will probably still have to respond to reviewers’ comments, make further revisions and perhaps carry out some painful cuts. For now, however, the text that existed for months in a succession of working drafts finally leaves our computers and reaches the editorial office.
Work on AR3S is continuing on several fronts at once. Above all, I am beginning to look for a potential investor who could help accelerate the CTO’s work — something I already mentioned in the July entry.
It seems to me that, at this stage, the best fit would be an angel investor, ideally someone connected to the legal community. Beyond capital, such a person could bring valuable experience, help us understand the market better and perhaps make it easier to launch pilots with law firms within their network.
For this reason, I begin a thorough overhaul of the pitch deck so that it can be shown to a potential investor without embarrassment. At the same time, we are expanding the website, and I am organising the Build Log, which is beginning to resemble a fairly extensive history of how the project came together.
In the second half of August, I plan to meet with at least three — and possibly four — lawyers who work with expert reports on a daily basis. This time, I do not want simply to ask whether the idea sounds interesting. I want to understand their working methods better, discuss specific problems arising in their cases and find out whether the output produced by AR3S would genuinely be useful to them.
Before then, however, we need to improve the way the results are presented. Mateusz is working on that right now. In his view, the first version may be ready for testing as early as tomorrow (!!).
We launch the new ar3s.tech website and begin preparing a public Build Log. The journal is meant to show not only progress, but also wrong assumptions, failed attempts, costs and decisions that shaped the product — without exposing the confidential mechanics of CEM.
We have known about Newcase.ai since May. The product combines medical records, testimony and other case materials, builds chronologies, identifies inconsistencies and supports the analysis of expert witnesses. Its scope is broader than that of AR3S, however, covering the entire litigation intelligence layer rather than focusing exclusively on the substantive assessment of a specific expert report.
Today, during another round of competitive research, I happen to come across two solutions that are even closer to parts of what we are trying to build: V7 Go and ArrowLex.
V7 Go explicitly promotes expert report analysis, methodology assessment, the identification of weaknesses and inconsistencies, report comparison, and the mapping of conclusions to source material. Functionally, this is already very close to some of the problems we are trying to solve. V7 remains a broad platform for automating the analysis of many different types of documents — from medical reports to technical, engineering and financial materials — rather than a product focused exclusively on medical expert reports used in litigation. We will nevertheless need to keep a very close eye on them.
ArrowLex is a platform designed for lawyers working with expert witnesses. It supports the analysis of expert reports, the preparation of questions and examination plans, the simulation of expert responses, and the comparison of testimony with case documents. It therefore operates within a very similar legal workflow, but focuses primarily on examination preparation and expert litigation more broadly.
My first reaction is frustration with myself. We have already sent an earlier version of the pitch deck to our first potential investors without including these companies. It looks a little as though we were unable to identify our own competition. The competition slide needs to be rebuilt immediately.
Worse still, these companies did not suddenly appear today. V7 has been operating for years, and it did not start analysing expert reports yesterday. ArrowLex does not look like a hastily assembled experiment either. The competition has not suddenly grown up in front of us — we are simply only now noticing that others have been approaching a similar problem from different directions for some time.
On the other hand, discovering products like these is also good news in a way. It shows that the need for deeper analysis of expert reports does not exist solely in my head. Perhaps we really are trying to solve a genuine problem, rather than create a market that nobody except us needs.
I still cannot find a product identical to AR3S — one combining medical specialisation with the systematic verification of the reasoning in a specific expert report and the identification of substantive grounds on which it can be challenged. We can no longer comfort ourselves, however, with the idea that we are operating in a completely empty category.
It is difficult not to feel a twinge of anxiety. We are still building the MVP, while on the other side there are companies with finished products, established teams, funding and a head start of several years. Being first will therefore not be enough — especially since we probably are not. We need to build a solution that is clearly better within our narrow use case: deeper, more reliable and genuinely useful to a lawyer confronting a medical expert report.
And we need to do it as quickly as possible.
Today I had a short, thirty-minute introductory conversation with Magdalena — someone with many years of experience on the VC side and in evaluating very early-stage startups. I wanted to see how AR3S, our pitch deck, and the idea of looking for an investor before the proper pilot stage appear from the outside.
The conversation was brief but very pleasant. One simple piece of advice came through particularly clearly: talk to lawyers as early and as often as possible. I already discuss the system’s results and development direction with a few lawyers I know, but it would be difficult to pretend that this amounts to genuine market validation.
The problem is fairly obvious: AR3S is not yet a finished product, and an independent lawyer is unlikely to hand over confidential court materials to something that is still under construction. Waiting for the complete platform, however, may simply take too long.
This brought me back to an idea I had considered before I even started working on AR3S: offering paid expert analysis of court-appointed expert opinions myself. Originally, this was supposed to be a fully manual service. Now it could take a hybrid form — I would remain responsible for the analysis and the final result, while already using AR3S as part of the process.
The client would not yet receive access to the platform. Instead, they would receive a completed and verified analysis of a specific expert opinion. In return, I could test on real cases what law firms actually expect, how they want the results presented, how much they are willing to pay, and whether they come back with another case.
Perhaps this is exactly what the stage between the current prototype and proper pilots should look like: the first paid cases and genuine contact with the market, without waiting until everything has been polished to perfection.
Today I spoke on the phone with Krzysztof, a lawyer with extensive litigation experience. A very likeable guy and a great conversationalist — half an hour went by far too quickly.
We mainly talked about expert opinions. In his experience, successfully challenging an expert opinion requires genuinely strong arguments, and sometimes even that is not enough. Krzysztof pointed out that, where possible, it would be useful if AR3S could additionally support objections with references to scientific literature or textbooks.
The idea makes sense — in fact, it seems almost obvious for a tool like this — but I still have some reservations about it. Many of the mistakes I see in expert opinions are not clear contradictions of textbook knowledge. They are more often problems of interpretation, overlooked evidence or conclusions that go further than the material really allows. Still, this is probably worth putting on the list for the post-MVP stage. Implementing it may be more difficult than it first appears: LLMs have a particularly nasty habit of inventing papers that do not exist, and from the beginning we have tried to keep the model on a short leash and not give it too much room to fantasise.
I also told Krzysztof about the two medico-legal papers I currently have under review. He was very interested in the subject, and I even promised to email him one of the preprints. We also floated the idea of writing something together for a legal journal at some point. We’ll see what comes of it.