I don’t fully understand what you’re trying to do, but my pretty experienced gut tells me that @Alexey_Gusev is right: You should be using a single table with, say, a single-select field called “LeadStatus” or something like that, which you can change from Lead, to Unpaid, to Client as needed.
Database design does not necessarily conform precisely to the way we human beings think about something. In an invoicing app, for example, if you have an ACTIVITY or ORDERS table that you use to create line items on your invoices, you are keenly aware of the practical difference between “billables” and “receivables” and “paid orders”. But when you’re modeling your data, you design the containers for the data — the tables — based not (well, not just) on how your users think about things, but on the structural properties of the things. And structurally, a billable order is identical to a receivable and a paid order. The only difference is their paid status.
I’m working this week on a school app. There’s a STUDENTS table. Parents call to ask about registration and at that time the school creates a record in STUDENTS, enters just basic info (name, address, DOB, sex, etc) and clicks into a single-select RegistrationStatus field and marks the student as “Inquired”. Later that will change to “Registered”, then “Enrolled”, and eventually to “Alum”. Everybody stays in the same table. In this example, it remains an open question whether, periodically, to purge records whose status never progressed beyond “Inquired”. But I’m considering that only because of Airtable’s limit on the count of records in a table.
Similarly, the things or “entities” that you’re working here seem to me identical in terms of basic data structure: a Client is just a Lead who has developed into a Client. Yes, you’ll want to gather more info about a client, but that just means you create a client form that displays more fields. The basic structural properties of the two “roles” are the same: name, company, contact info, whatever else. So create a status field, make views for your different status categories, and revise your forms based on those different views.
I might change my mind if I knew a lot about your project. There aren’t very many absolutely hard-and-fast rules. But I’ve been doing this since the last century and as I said, my gut tells me Alexey is right. And if so, you’ll end up finding it MUCH easier to manage all this data if you put it in a single table.