Bankruptcy software with a client portal: what a solo practitioner needs and what to skip

The short answer. In a bankruptcy practice the client portal earns its keep by answering the questions a client would otherwise ask by phone: where is my case, what did you receive from me, what do you still need. Document assembly earns its keep when it is attached to the stage of the case rather than to a folder of templates. A lawyer working without administrative staff needs three things, intake, case status and document assembly, and can leave out most of what vendors put in the demo.

We built a partner platform for personal bankruptcy with a procedure of more than thirty stages, DOCX generation, a money module and a chat with a curator. Everything below comes from that work and from what the firms running on it actually used.

The portal replaces a specific thing: the phone call

A bankruptcy case runs for months, and for most of that time nothing visible happens to the client. The filing is prepared, the court takes it, a hearing is scheduled, a trustee is appointed. The client sees silence, and silence produces calls.

Count them for a week before you buy anything. In a practice of forty cases the answer is usually between five and fifteen calls a day, and almost all of them have one of three contents:

• what stage is my case at, and what happens next;
• did you get the document I sent;
• what do you still need from me.

All three are status questions, and a portal that answers them removes most of the interruption from the day. This is the whole business case, and it is worth writing down before a demo, because a portal that shows everything except these three answers will not reduce a single call.

What the portal shows, and what it must not show

The temptation is to give the client the same view the lawyer has. That turns into a problem on the first unfavourable development in the case.

The client sees	The client does not see
The stage in plain language, with what comes next	Internal stage names, deadlines, risk notes
Documents they supplied, and their status	Drafts, versions, comments between lawyers
What is still required of them, as a list	The trustee’s correspondence, court file internals
Dates that concern them: hearings, deadlines for their own documents	The lawyer’s own calendar and workload

The second column matters more than the first. A client who can read an internal note will read it at the worst possible moment, and a portal that leaks drafts will be switched off within a month. If a product cannot separate these two views cleanly, it is not a bankruptcy product, it is a project management tool with a login screen.

Document assembly belongs to the stage, not to a template library

Most document generators are a folder of templates with a button. The lawyer picks a template, fills a form, gets a DOCX. That works for a practice with five documents, and it stops working as soon as the procedure has stages, because the question is no longer “which template” but “what has to exist before this stage can close”.

The version that holds up ties documents to stages:

• each stage declares the documents that have to exist before it can close;
• a document is assembled from data already in the case, not from a form filled in again;
• the assembled file stays editable, because the lawyer will change wording by hand and should not be fighting the system to do it;
• every generated file keeps the template version it came from, so a document produced in March can still be explained in September.

The last point is the one that gets left out and then costs the most. Court forms change. Without a version stamp on the generated file, a firm cannot answer why two filings from the same practice look different, and in a dispute that question will be asked.

Intake is where the time actually goes

In personal bankruptcy the heavy part is not the filing, it is collecting what the filing needs: identity documents, creditor list, loan agreements, income records, property records. A client sends them over months, in the wrong format, one at a time, through whatever channel is open.

Three mechanics do most of the work here:

A checklist the client can see. Not a list of what the lawyer needs, a list of what the client still has to provide, with the ones already accepted marked off. This single screen removes the “what do you still need” call.

Acceptance, not just upload. A file arriving is not the same as a file being usable. Somebody has to look at the photo of page three and say it is legible. Mark that explicitly, because the alternative is discovering it at filing time.

One channel, enforced. Documents arriving by messenger are documents that get lost. The portal only helps if it is the only door, which means saying so to the client at the first meeting rather than hoping.

What a solo practitioner can skip

This is where most of the budget is saved. A lawyer with no assistant and twenty to sixty live cases does not need the platform a fifty-partner network needs.

Worth building	Can wait, or never
Intake checklist and document acceptance	Partner network, referral tracking, commissions
Case status visible to the client	Real-time chat inside the product
Document assembly tied to stages	A training module for staff you do not have
A reminder when a client’s item is overdue	Automated court filing integrations
Export of the whole case as files	Analytics dashboards

Two of those deserve a word. Chat inside the product sounds obvious and almost always loses to the phone and the messenger the client already uses; what the client wants from the product is the answer, not a new place to ask. And analytics on sixty cases tells a solo practitioner nothing they do not already know from memory.

What breaks

Photographs instead of documents. Clients send pictures of pages, often at an angle, often one page of three. Any product that assumes clean PDFs will produce a filing with a missing page. Acceptance has to be a human step, and the product has to make rejecting a file easy and polite.

Legal questions through the portal. The client will ask whether they should sell the car. If the product has a message field, that question will arrive there, and an unanswered message in a legal product is a liability. Either answer in the channel, or do not open the channel.

Form changes. The forms will change mid-case. A product where templates are baked into the code means waiting for a vendor release while a deadline runs. Templates belong in the hands of the practice, with versions.

Cases that stall. A case can sit for months waiting on a court. The product has to distinguish “waiting, correctly” from “forgotten”, or everything looks alarming and nothing gets attention.

Ready-made or custom

For a solo practice, start with a ready-made product. Practice management tools cover intake, status and documents well enough, and the first month of using one will teach more about your own procedure than any specification.

Custom development starts making sense at a specific point: when the procedure itself is your product. A network of partner lawyers, a referral model where money is split, a procedure with branches the ready-made tool cannot express, compliance requirements on who may see what. That was the case in the platform we built, where the procedure had more than thirty stages and the money split between the company and the partner had to be correct to the ruble.

The honest version of the test: if the thing you cannot buy is the procedure, build. If the thing you cannot buy is a feature, wait, because the next release may bring it.

Budgets and timelines for the built version are in a separate article on what a legaltech platform costs, and the broader question of what to automate in legal work is here.

Common questions

Will a client portal reduce the number of calls? It reduces the status calls, which are most of them. It does not reduce the calls where the client is frightened, and those are the ones worth taking.

Can one person maintain a system like this? A bought one, yes. A built one needs somebody responsible for templates when forms change, and that is a real recurring task, not a one-off.

Is document assembly worth it for a small practice? It is worth it when the same data goes into several documents. If every case produces two documents and they are different every time, a good template in Word and a careful hour is cheaper than any generator.

What about security? A bankruptcy case holds income records, debts and family details. Any product holding them needs per-case access, an audit log of who opened what, and an answer to the question of what happens to the files when the client leaves. Ask that question before the demo ends.

The rule

Buy for status and intake first, because that is where a solo practice loses its hours. Attach document assembly to the stages of the procedure, keep the template versions, and leave the portal with only what the client is supposed to see.

Before any of it, count the calls for one week and sort them into the three kinds. A practice that does that arrives at the demo with a question the vendor has to answer, instead of a feature list to agree with.