Watch It Get Built — A Client Onboarding Tool Created Live From Scratch

Brian Clare — Founder, Blueprint Accounting

02:58What we’re building and why

Today we’re going to use Lovable to build a client onboarding tool from scratch. It’s something I did just the other night to see if it would work, and it does. I’m basically taking something I’ve already built in Airtable and we’re going to rebuild it in Lovable.

My name is Brian Clare and I run an accounting firm called Blueprint Accounting up in Ottawa. I’m not a developer by any means — definitely a vibe coder, and a super nerd for sure. I grew up around IT; both my parents were in it, so I saw computers pretty early. I started my firm in 2018, dove into Zapier and all that automation stuff, and then as soon as AI came out three or four years ago I just dove in. Since then I’ve been refining how I use it, how my team uses it, and learning from everyone and testing things out.

The subheader for this session is “how accounting firms can build the tools they’ve always imagined without a developer.” I’m purely vibe coding — just talking with Claude in this case, and then Lovable — trying to figure out how to translate my ideas into an app we can actually use. You’ll notice I’ve got a bunch of tabs open, and I built this webinar deck in Lovable as well, so you can do things like that too.

06:00The problem: tax season starts with chasing documents

Let’s set the scene. My firm started offering taxes this past tax season. In Canada, personal tax starts in January and ends around the end of April, and we were trying to figure out how to make gathering information from clients really efficient — and then get it into our tax software so we can start the actual tax work.

The problem: tax season starts with three weeks of chasing documents instead of preparing returns. You send out the request, the client says “I’m not really sure where this goes, I’m not really sure where this form is,” and it’s just this constant chasing. We need all of that before we can even start.

My journey was that I built version one in Airtable after a conversation back and forth with Claude. Being a tinkerer by nature I wanted to build it custom, but I know Airtable really well, so I built it out in two evenings. This year we’re describing version two in plain English, which is what we’ll do with a bunch of prompts today. The bet for today: the takeaway isn’t the tool, it’s that you could build one. We’re going to use eleven prompts over about forty minutes and have a working tool by the end.

My current personal tax intake form lives in Airtable. It gathers information about the client — eligibility, any wealth advisor info, whether they have a spouse, income, dependents, income types, whether they work from home, investments, rental properties, self-employment, and then various deductions and credit checks. The client fills it in and, based on their answers, it tells them what they need to send us. When we receive the answers, we can check what they said they’d send versus what they actually sent.

08:53Prompt 1 — Foundation: schema and two user experiences

For the first prompt we’re building the foundation. The idea is to think about where the data is coming from and where it’s going. I already know all the data points I want to capture, so I can have AI build out the structure or schema within Lovable using their databases. You can see it’s creating two tables — a clients table and an intake sessions table — and building both an admin view and a client view.

We copy the prompt, paste it into Lovable, and hit enter. The beautiful thing about Lovable is it works completely in plain English — really any language. It starts thinking through the structure, reviewing the admin UI scaffold and routing. It asks if we want to enable cloud; we click yes. It says it’ll build a database and add AI features through their LLM — free to start, pay as you go if we need to scale — and we choose a hosting region (Americas, Europe, or Asia Pacific). We click enable cloud, and that builds a full database.

Before Lovable had this built in, you had to integrate with something like Supabase yourself. Lovable’s databases are actually white-labeled Supabase — it just does that connection automatically for you now.

So what got built? The database schema (clients plus intake sessions), the admin shell, the sidebar navigation, and the routing for two separate user experiences: our internal team managing something, and what we send out to clients. We’re defining those two experiences upfront, and it prevents Lovable from mashing the admin and client features together. We would not want to send the admin view to a client where they could see every other client’s intake forms — that would be a horrible security experience.

The most valuable thing in your first prompt isn’t features — it’s the boundaries you set. We’re not just saying “build me an intake form,” because that’s a dumpster fire you’ll iterate on forever. Most of the actual work I did was with Claude, having a conversation about what I needed to build, and from there it created these structured prompts.

13:53Prompt 2 — The multi-step intake form with auto-save

Prompt two builds the actual intake form. It captures the tax year, personal information, whether you have a spouse (and if yes, their name and annual income), employment type, which income documents you’ll submit, rental properties, and then review and submit. It’s a fairly basic form that captures some of what my Airtable version did.

This builds a multi-step intake form with conditional questions. For example, employment type can be employed, self-employed, or both — you might have a side hustle or another business as well as a job — and depending on the choice it asks for different things.

One thing that wasn’t on my Airtable form is auto-save. When a client visits their intake form, it auto-saves: they can close the window, click the same link, come back, and their answers are there. The way I set it up, the form pulls in last year’s answers so they can just edit them — but if they came in, changed something, and closed the window, those changes wouldn’t be saved without this. So auto-save is a really nice quality-of-life feature. It saves every thirty seconds, and that’s one line in the prompt solving a real abandonment problem.

When you describe what you want, include the small behaviors that matter. We don’t want someone to have to click save — it just happens automatically — and when they come back, it tells them they’re returning to a freshly saved version so they’re not re-entering everything.

When it’s done we get a minimal client header, a progress bar, a locked-down banner, a conditional year step, all seven sections, a file upload, auto-save, and a confirmation screen. I like to go through every individual prompt in order rather than tweaking pages mid-build, because changing a page now might affect future prompts. I make my tweaks at the end.

18:09Prompt 3 — Year selection and resume logic

Next is year selection plus resume. This handles three scenarios. Scenario A: starting a new intake for a year that has no submission yet. Scenario B: resuming an in-progress session for the selected year — that’s the client coming back to add information. Scenario C: a brand-new client with no client ID who has never touched anything in our system, which is a very different flow. We want to make sure all three work.

We paste it in and Lovable edits the code. What’s getting built is the logic for which year we’re working on — making sure the client doesn’t start the wrong year, picks the correct year when resuming, or chooses the correct year on a fresh start. We’re also pre-filling personal information from prior years where we have it. Things like full name, email, and street address can change, so we pull them in and make them editable. The client just looks at the information, leaves it if it’s accurate, or edits it directly in the app.

Watching it work, you can see it reasoning: “I’m deciding whether to rewrite the whole file or just patch the orchestration section.” Rewriting a whole file takes a bit longer. I probably could have written a slightly better prompt, or ordered it differently, so it didn’t fully rewrite something — that would make it quicker.

21:34Prompt 4 — The client detail page for staff

Prompt four builds the client detail page. When a user clicks a client’s name on the admin clients page, it takes them to that client’s page. This is for your internal team. They can see the client info summary and the submissions that have happened, and click into each submission to see the answers. If there are no submissions, it shows “no intake submissions yet — send this year’s intake link to get started,” with an easy button to do that.

After this you’ll probably think of other features — bulk sending, auto-sending — but this is the starting point. The page shows each client’s full submission across the years, and the firm staff see this, not the client. A previous year’s intake is often more useful than the current one, so when the client goes to look at their answers it shows them which answers are from last year. They can edit if something changed, like their address if they moved; if nothing changed they go to the next page.

When in doubt, build the navigation around your team’s actual questions: who is this client, and what have they given us before? If they’ve provided something in the past, like a prior tax return, can we reuse that information? If not, we know it’s a new client and we’ll gather new information.

23:51Prompt 5 — The new-client modal

Prompt five adds the new-client modal. When you click “add new client” it pops up a modal that creates a new client record, grabbing just name and email. We punch in their name and email, click submit, and it sends them the intake form automatically and adds them to the database.

A two-field modal — name and email — is all the firm needs to onboard a client, because we’re relying on the client to send us the rest through the form. Asking firm staff to enter address, employment status, and so on just duplicates the work the client is about to do anyway. Once we gather it, next year when they come back we’ve already got that information; they’ll see it pre-filled on next year’s intake form and can edit it if anything changed.

Strip your forms to a minimum. We want it really easy for clients to submit. Internally, we just enter name and email; the client then gets the intake form and knows exactly what to fill in and submit.

25:21Prompt 6 — Transactional emails

Now we build transactional emails — three to start with. First, the initial intake invitation: when the firm clicks “send this year’s intake form,” the client gets an email asking them to fill it in. Second, the client confirmation after submission — I’ve connected my domain, and it sends something like “Thanks, Brian. We’ve received your 2024 tax intake,” which gives the client the feeling they’ve done something correctly. Third, the firm notification after submission: when the client submits, we get an email too. If you’re using something like Karbon, that goes into a shared triage and tells us the client submitted, so we can go into the app, double-check the information, and start the return.

These three cover the entire client life cycle. By bundling related emails together, the AI sees the system as a whole and uses the same templates, the same sign-off, and the same sender. Asking for them separately would have created three inconsistent emails. You can customize what those emails look like directly inside Lovable.

When I set up the email domain it had already verified it automatically — once you’ve done it on one app it seems to carry over. Sometimes a prompt hits an error: you click refresh, and if it persists you can click “show logs.” If you understand the log you know what to do, but worst case you just click “try to fix” and send the error back. From a vibe coder’s perspective that’s great — I can read what the log says, but could I start typing in the code and fix it myself? No. So having that “try to fix” option is awesome.

28:17Prompt 7 — AI-generated conditional questions

This prompt does AI-generated conditional questions. For example, if last year the client was self-employed, it asks “Are you still operating your business? Any major changes?” When you’re ready to submit, you get an AI-generated question based on comparing this year’s answers with last year’s. It does that analysis for you.

The prompt reads, roughly: “You’re helping a Canadian accounting firm gather tax information from returning clients. Given the client’s previous year’s intake answers, generate one to three follow-up questions that should be asked this year. Focus on items from last year that need to be confirmed or updated.” It returns the questions as JSON with input types and what each relates to. You could make this far more robust if you wanted.

This is the moment Airtable couldn’t reach. The Airtable form is very static — you can do basic conditional logic, like a yes/no spouse question that reveals more fields if yes. But here we can create genuinely adaptive questions and have AI generate them based on the actual context of the returns. Historically that was a developer-only feature, but in the age of AI we can build it ourselves if we think through the prompt. It gets meta: AI is building the AI conditional feature.

The system prompt you write is doing the real work. As you iterate, you keep refining it — maybe the way I did, building the infrastructure and the prompts in Claude first. You test it, see what questions come up, and refine from there.

32:06Prompt 8 — The submission flow

Prompt eight is the submission flow — a fairly simple one. It marks the intake session as submitted, saves the data, updates the client record with anything that changed, fires the emails, and closes the client journey. This is where the client receives their confirmation email and our team receives the notification. The team can then come into the app, review all the answers, confirm anything that needs review, or take it over to the tax software and start working.

Updating the client record on submission is what makes next year’s pre-fill accurate. Think about what happens after an action completes. A lot of what we’ve done is pre-building — having the conversation in Claude, making sure we understand how to get our idea into Lovable — but now we’re looking at what happens after an action is taken: from the inputs, to the outputs, to what we need to do with those outputs.

We got another warning and a small error here, so we refresh, and when it persists we click “try to fix.” Sometimes those things pop up and we just get AI to fix itself.

34:17Prompt 9 — The admin submissions page

This is the admin submissions page, and it’s super important because it’s the firm’s review screen. It lists all submissions, filtered by status and year, with a detailed review screen per submission.

You can submit all your prompts one after another — when I hit enter, it queued this one and ran it automatically once the previous step finished. I like to wait until each is done to catch any errors, but if your prompts are already built you can just drop them into the chat in sequence.

This builds the dashboard where staff actually do their work after a client submits — verify everything’s there, then work on the return. Without it, the firm has nowhere to work with the intake data; submissions go into a black box, or worst case the team has to dig into the database, find the right row in intake sessions, and read raw data. Far better to create a proper UI for it.

Build the operator’s interface with as much care as the user’s. As much as we want it easy for clients to submit, we want it just as easy for the team to manage, update, and send requests. If it’s a horrible experience, they simply won’t use it.

37:16Prompt 10 — AI document verification with an override

This one’s another use case for AI, and it’s what the client sees. Documents are critical for taxes. In Canada these are things like a T4 (personal income), contractor income, dividends or disbursements (a T5), a T2202, RRSP receipts for investments, a statement of business activities for a sole proprietorship, a statement of rental income, and so on. You’d customize these for whatever country you’re in.

When a client uploads a file, AI checks whether it matches and looks valid for the document type expected. Clients can drag and drop files directly, or click to open their file explorer. So it does real-time AI verification of uploaded documents — for example, it catches that a client uploaded a T5008 thinking it was a T4 and notifies them it’s the wrong file. They can delete it, drop a new one in, and it re-verifies.

Crucially, we also give the client an option to skip if AI misread the document — an override button. The override is the design decision. AI is wrong sometimes, and a tool that blocks the user when AI disagrees is worse than no AI at all. So if it really was a T4 and AI got it wrong, the client clicks “override,” the file stays, and they’re not blocked from submitting.

Modernization with humility lands better than modernization with certainty. The override isn’t a workaround — it’s part of the design. We’re not telling people to always click override; we’re giving them the option for when AI gets it wrong.

41:03Prompt 11 — Polish and visual design

The final prompt is polish. Right now it’s black and white and pretty generic; we paste this in to get a cleaner-looking tool. What changes is the visual design — typography, color, spacing. You can even hand the AI your own colors, your logo, and anything related to your company, and it’ll polish the tool to match your brand and the way you talk.

Build the substance first. Prompts one through ten built the experience: how a client goes through the form, how we gather the information, how the team manages it. Then you use AI to add the polish and make everything look nice. The stylized version has a lighter side panel, different-colored buttons, and a logo — and you can have AI add all your brand colors and details to make it fully polished.

43:19Walkthrough of the finished tool

Let me take you to my finished version. I’ve already added a client — just myself, from testing. There’s a copy-link button and a “send intake invitation” button; I’ll copy the link so we don’t have to send an email.

This is what the client sees. Because I’d already submitted last year, it pulls in all my information for me to verify. If I’m asked “do you have a spouse?” and click no, the fields disappear — that’s the conditional. If yes, I enter my wife Michelle’s name and income. For employment, if I’m only employed it asks for a T4; if self-employed it asks for a T4 and a statement of business activities; both or neither asks for more.

For documents, I drag in a sample T4 — it checks the document and confirms “looks like a valid T4.” Then I drop in a T5 (dividend or disbursement income) and it says “this looks like a T5, not a T4 or statement of business activities — please upload the file.” There’s the override: “I’m sure this is correct,” I click override, and it stays as a file that will be submitted.

When I get to rental income I click no. Last year I said I had rental income, so this generates conditional follow-up questions. It also shows “welcome back, we saved your progress, picking up where you left off.” For the tax year I pick 2025, and the follow-up questions appear: “Did you continue to earn rental income? If so, please provide…” — comparing my 2024 answers against this year. I answer them, get a summary, and click “submit intake.”

That submission flows into the admin side. I refresh, click on myself, and see two submissions. Clicking in shows all the information submitted, the two files, the follow-up questions, and a space for preparer notes.

47:06What just happened, and what’s still missing

Forty minutes ago we had nothing but an idea: build an intake form. We took that idea, talked with Claude, did a little homework ahead of time, and used plain English to build the app.

A few things to call out. I didn’t write a single line of code — I can’t write code. I just described what I wanted, and every prompt I used is something you could have written too; there’s nothing technical in any of them. The hardest part wasn’t the prompting — copying and pasting into Lovable is easy. The hardest part was the thinking I did beforehand, using Claude as my thinking partner. I knew what the schema needed to be because I’d built it the hard way last year in Airtable. The AI parts — conditional question generation, document verification — aren’t separate from the app; they’re features inside it. Five years ago you’d have needed a developer to build those.

This app is not done. There’s no auth — if someone went to the URL right now, with no authentication, they could see everything. I’m going to unpublish it. There’s only light error handling, the styling could be better, and there’s no OAuth, so if you’re a Google or Microsoft firm none of that is built in. You can prompt Lovable to add it. Right now it’s not secure — someone with the URL could open the submissions and see my T4, my SIN, all of it. So put security upfront. Lovable does have a security feature — there’s an in-depth scan — and if you try to publish, it’ll almost certainly run a security review and flag that there’s no OAuth. Always double-check that before publishing, especially when client data is involved.

50:02What to do on Monday: three questions before you touch a tool

Pick one painful thing in your firm, then ask three questions before you touch any tool.

First, what does success look like? Be specific. Don’t just think “I want a better intake form.” A good goal is “a returning client doesn’t have to re-enter information we already have” — a great quality-of-life feature.

Second, what does the data model look like? You already know this. Even if you don’t understand development, you understand what information you capture from clients, what you need to request, and what answers your team needs to see. That’s your data model.

Third, where could AI help? Find the judgment call your team makes manually that an AI could make consistently. For me, that was comparing this year’s answers to last year’s to generate conditional questions, and verifying that an uploaded file matches the document we asked for. Those are things you can have AI judge for you.

I’m Brian Clare, I live in Canada, and I have my own accounting firm. I’m excited to see what you build — feel free to find me on LinkedIn, tag me, or add me. I’d love to see it.