Post-closing in a VC or PE transaction is not glamorous work. The SHA is signed, the funds have transferred, and what remains is a list of Conditions Subsequent ("CS items") that need to be completed within defined timelines. Filing Form PAS-3 with the RoC within 30 days of allotment. Issuing share certificates within 60 days. Stamping, updating the Register of Members, circulating the letter of allotments. Board resolutions certified and delivered. FC-GPR filings on the RBI's FIRMS portal. Deadlines slip, regulatory penalties follow. Or worse, investor friction kills the relationship.

We tracked all of it on a shared Excel sheet. Columns for the item, the responsible party, the deadline, the status. The link went to investors, to the founder's team, to the company secretary. I handled the legal side: stamp papers, MCA filings, coordinating with the company secretary. For everything else, I'd chase down the founder's team.

It worked. That was the problem.

What "working" was actually costing

The Excel tracker did not fail in any dramatic way. CS items got completed. Filings were made. Deals closed cleanly. But two things consistently created friction that I had come to accept as inherent to the process.

The first was the status column. In practice, a CS item is never simply "pending" or "done." Waiting for stamp papers from a vendor. Drafted but not yet signed. Filed, pending MCA approval. Each state is different. The moment you try to capture that nuance in a free-text cell, you are either too verbose and investors stop reading, or too vague and they follow up asking what is actually happening. Whatever I wrote felt like the wrong level of detail for someone on the other end.

The second was visual. Investors and founders read this tracker differently than I do. I know what every row means because I built it. For a founder seeing it for the first time, or an investor's associate checking progress on a deal they closed two weeks ago, an Excel sheet with colour-coded cells just reads as administrative noise. It communicates very little about the actual state of the transaction.

Building it without writing code

I had no prior experience building software. What I had was a clear mental model of what the tracker needed to do. After doing it manually for long enough, I knew exactly where it broke down.

I described the problem to Lovable: a Conditions Subsequent tracker for SHA/SSA fundraising deals, with discrete status stages (Not Started, In Progress, Waiting for Revert, Completed), sub-tasks within each CS item, and the ability to assign responsibility to either the legal team or the client. The output was a working interface in a single session. I just handed it a clear brief about a workflow I understood.

The tracker at post-closing-tracker.lovable.app does what the Excel sheet never could. A CS item like "Issuance of Share Certificates" shows its stage, its sub-tasks, and its progress (1 of 2 sub-tasks complete) in a format that an investor can read without context. "Waiting for Revert — Client" communicates more precisely than any status cell I ever typed. The visual hierarchy follows how the transaction actually progresses. A spreadsheet can't do that.

The real insight: briefs that work for a junior lawyer work just as well for AI. The skill is the same.

Where it currently breaks

The honest limitation is significant. The tracker was built on Lovable's free tier, and when the credit limit expired, persistence went with it. Every time someone opens the link now, the items and statuses reset to the default state. It is a functional demonstration of the workflow, not a deployable tool. For actual use on a live deal, it is not usable in its current form.

The gap between a working MVP and something you can actually put in front of investors is more instructive than the build itself. The interface works. But data persistence, deal-specific configs, and reusable checklists require real infrastructure. Those are the things that make the difference between a prototype and a professional tool. They go beyond what a prompt can solve.

What this clarified about law firm process

Transactional law firms have not historically thought about internal tooling as something they build. They buy software or they use what they have. Excel. Word. Email. The idea that a lawyer might identify a workflow gap and build something to fill it in an afternoon, without an IT department, is genuinely new.

What vibe coding makes available is not the ability to replace legal judgment with software. The CS items still need to be identified correctly. The deadlines still need to be tracked by someone who knows the regulatory consequences of missing them. The coordination with the company secretary, the client's CFO, the investor's team — none of that is automated. What changes is the surface you use to manage and communicate all of it. That surface can now be purpose-built for the specific workflow, rather than adapted from a generic tool that was never designed for post-closing transaction management.

The Excel sheet worked. It will keep working for lawyers who have not tried the alternative. But having built something better, even incompletely, I find it hard to go back to updating status cells and hoping the investor reads them correctly.

Personal observations from practice. Nothing here constitutes legal advice.