Javier Ruiz Blay knew the problem from legal practice. Lawyers build up libraries of briefs, appeals, lawsuits, and templates, then a lot of that work vanishes after one case. JuraDocs gives those documents a second life in a marketplace built for professionals, where trust is part of the workflow rather than something handled later.
JuraDocs brought the legal vision, product direction, brand, and domain context. QuadiByte built the product underneath: frontend, backend, document workflows, verification logic, payments, dashboards, and admin systems.
Legal work depends on documents, confidentiality, credentials, and judgment. JuraDocs had to be credible enough for practising lawyers to use publicly, careful enough to protect sensitive files, and structured enough to handle money, invoices, reviews, verification, and admin decisions without relying on manual checks forever.
01
Javier saw the problem in legal practice. Good briefs, appeals, lawsuits, and templates often get used once, then disappear. JuraDocs needed to turn that work into reusable professional assets without making the exchange feel casual.
02
Before a document could become public, the platform had to check the seller account, profession permissions, bar registry data, document readiness, payout setup, invoices, reviews, and admin controls.
03
Once the marketplace worked, the next work was less glamorous and more important: payment recovery, seller-share retries, account moderation, anonymisation access, deployment structure, search quality, and model configuration.
We kept Medusa as the commerce backbone, then added the rules JuraDocs needed: seller ownership, document publishing, offers, reviews, fee snapshots, invoices, and payout state.
The hard part was not adding a vendor label to a product. Every order needed to know who owned the document, which profession rules applied, what fee was active at purchase time, and how settlement should recover when payment signals arrived late or failed.
Read how we rebuilt the commerce engineVerification gates, document processing, and payout workflows that recover cleanly.
The document work was heavy: anonymisation status, PDF redaction safeguards, structured legal metadata, and summaries that make a document searchable beyond its title.
We treated the model layer as infrastructure, not a demo. Processing runs through controlled workflows, progress is visible, and publication still depends on human review. The lawyer stays accountable for what goes live.
For JuraDocs, trust is not a claim on a landing page. Sellers move through account details, profession permissions, registry checks, verification state, payout connection, and publishing readiness before documents can enter the marketplace.
That protects buyers and gives the platform a real quality bar. Public listings are tied to professionals who passed the required checks, not anonymous uploads.
The first phase turned Javier's product thesis into technical rules: who can publish, what needs checking, what happens to a sensitive PDF, and how money moves after a purchase.
The platform had to feel serious enough for practising lawyers and simple enough that sharing legal documents did not feel like extra admin work.
With JuraDocs' brand, product direction, and legal requirements in hand, we built the frontend, backend, and data model on MedusaJS.
Documents, verification, search, bids, purchases, invoices, and payouts had to work as one system. A buyer should not feel the seams between them.
After the core marketplace was live, the work moved into the details: payment idempotency, retries, account states, registry-match rules, anonymisation access, deployment, search, and model configuration.
JuraDocs was not shipped and left alone. It kept getting tightened as a platform people could actually operate.
Share the rough version and we will help identify the first useful build, the same way we approached this project.
