I needed the same onboarding flow three times, so I built the tool

Onboardle was not a product idea. It was a form I needed for something else, then needed again, then needed a third time.

It started as an intake form

I was building an AI-driven website builder. To generate a site for a business I needed things from that business: what they do, who they sell to, their logo, their existing site if they had one, whatever brand material was lying around. That is a lot to ask a stranger.

The obvious design is a contact form first and the questionnaire after. It is also the design that loses people. Someone who has not yet seen anything of value has no reason to hand over their email, and asking first turns a curious visitor into a decision they are not ready to make.

So I inverted it. Let them start. Let them answer a few questions about the business, upload the logo, watch the thing take shape. Ask for the email when there is something waiting on the other side of it — not as a toll, but as the address to send the result to. By then they have put twenty minutes in, and the ask reads as a formality rather than a gate.

That was the bet: the right place to ask for contact details is usually not the beginning, and it is not the same place for every business. It needed to be something you could move.

Then I needed it again, for IT clients

Taking on a new IT client means collecting a specific pile of information before you can do anything useful. How many people. What they run — hardware, software, whatever is holding the accounting together. Who has administrator rights. Then the parts that are not questions at all: agreeing to the terms, paying a deposit, booking the kickoff.

I had been doing that across an email thread, a PDF and a scheduling link. Three tools and a great deal of chasing. Structurally it is the same thing as the website intake — an ordered set of steps ending with someone committed — and it needed different pieces in a different order.

And a third time, for staff

I do not have employees yet. I will. And having sat through onboarding at large organizations, I know what that software looks like: a fixed run of slides with a quiz at the end, built for a company inducting two hundred people a year into a process that does not change.

A ten-person business does not have a process that does not change, and does not want to model one. It wants to send someone a link that walks them through the tools, has them acknowledge the handbook, and confirms they actually read the security policy — and it wants to alter that next month without it being a project.

Three problems, one shape

All three are an ordered set of steps: some collecting information, some presenting it, some requiring a decision, ending in a record of what the person did. The differences are which steps, in what order, and who is allowed to begin one.

So that is what Onboardle is. A flow is a sequence of steps, and there are fifteen kinds of step — welcome and completion pages, content and rich text, checklists, forms, file uploads, resource lists, embedded pages, approvals, payments, scheduling, quizzes, and acknowledgments with a signature. Lead capture is one of them. Which means the question I started with, where to ask for the email address, is now answered by dragging a step, not by rebuilding a funnel.

Client flows are public — anyone with the link can start one. Employee flows are not, and reach people three ways: a personal magic link, a shared access password, or an emailed access link for a flow you want listed but not open. Every account gets a subdomain, and a custom domain where the plan allows it, because a flow that collects a signature and a deposit should not look like it is hosted somewhere else.

Why build it rather than buy it

I did look. There are good onboarding tools, and most are built around one of my three cases and awkward at the other two. The flexible ones price per seat, which stops making sense the moment the people going through a flow are prospects rather than staff.

Underneath that was the plainer arithmetic: I would be renting it forever, for something I understood well enough to build. That is the same calculation I now run with clients who have outgrown the software they are leasing — and it is a considerably easier argument to make having run it on myself first.