I Wanted to Make It as Easy as Possible to Start

Three weeks into the hard launch and the home page was already talking past everyone. So I split it.

I have been grinding on EZdoc every day since launch. Some days I'm still at the keyboard at 1 AM. The whole point of working that hard is to make sure the product actually fits the people who land on it — not the other way around. So when I realized the home page wasn't fitting anyone, that bugged me more than any single bug in the codebase.

The problem wasn't the design. The problem was that I was trying to sell two completely different products to two completely different people on the same page.

So I split the home page into two paths. Here's why.

I was building for two people, not one

I keep a running mental model of who EZdoc is actually for, and the longer I sit with it the more I'm convinced it's two distinct people, not one blended persona.

There's the person who wants one document, tonight. Freelancers sending an invoice for the gig they wrapped today. Parents designing a flyer for the bake sale. Someone rewriting their resume because the interview is Monday. A plumber who needs to send a quote before he loses the job. A 27-year-old launching a side hustle who needs a clean one-pager so they don't look like an amateur.

Then there's the team that needs a thousand documents, by Friday. An ops lead at a coding bootcamp generating 800 certificates before graduation. An accounting firm running monthly statements for 1,200 customers. An agency wiring EZdoc into HubSpot so client onboarding kits fire automatically. An HR director shipping every offer letter pre-signed and filed before the hire's first day.

Same product underneath. Same AI, same templates, same engine. But the conversation each person needs to have before they trust me with their data, their time, or their card — those are not the same conversation at all. And the way EZdoc gets sticky for each of them is different too. The freelancer comes back when the result is good enough that they tell a friend. The team becomes loyal when the integration is reliable enough that no one notices it's running.

The thing I refuse to do

There's a script most SaaS companies run on the freelancer. It goes like this: get them to sign up, push them into a free trial, tighten the limits until they hit a paywall, send six "your trial expires soon" emails, hope they convert to a $19/month plan they'll forget to cancel.

I hate that script. I've been the customer at the receiving end of it more times than I can count, and every time I cancel I'm a little angrier at the company that pulled it on me.

The freelancer doesn't want a subscription. They want the invoice. If EZdoc gives them an invoice and the client pays it, that is the entire transaction I want with that person. Maybe they come back next month. Maybe they don't need me again until October. Maybe never. All of those are fine outcomes.

If I push them into a monthly plan they don't need, I haven't made a customer. I've made a regret. They'll show up six months later only to cancel, mad, and tell their friends EZdoc is one of those companies. That's not a business model. That's a slow-motion brand fire.

So pay-as-you-go on EZdoc is built to be the opposite. Three free AI generations on signup — same model the paying users get, no card required, no draft mode, no feature locks. Want more? Five dollars buys about five more documents. No subscription. Card never gets stored. Nothing auto-renews.

If you sign up, get the resume, land the job, and never think about EZdoc again — that is a win. I want that. The reason I built this is so a real person could do a real thing with less friction. Not so I could siphon $19/month from someone who only needs help twice a year.

The other audience needs the opposite

The team that runs 800 certificates from a Google Sheet does not want pay-as-you-go. They want a subscription. They want predictability. They want the API and webhooks. They want to know that on the first of every month, 1,200 customer statements will go out without anyone touching a button.

For them, the right pitch is the workflow. Drop in a CSV. Build a template once. Walk away with a stack of finished PDFs. Connect Zapier so closed-won deals fire onboarding kits automatically. Hit the REST API from your billing system to generate statements on a cron. Wire it up once, never think about it again.

They want a different page. A different tone. A different set of CTAs. The freelancer wants warmth and "you can leave whenever." The ops director wants reliability and "here's the API spec."

So now there are two pages. Pay-as-you-go for the one-document person. Bulk and teams for the thousand-document team. The home page asks you to pick which one you are, and then sends you somewhere that actually talks to you.

I design software the way I talk to people

This is how I think about everything I build, in software and out.

The way I talk to a contractor about my deck is not the way I talk to my kid about screen time is not the way I talk to my wife about dinner is not the way I talk to a customer who just hit a bug at 11 PM. Same me. Different conversations. Each person gets the version of me that meets them where they are.

Software should do the same. The freelancer Googling "how to make an invoice" at 9 PM on a Sunday is in a completely different place than the developer Googling "PDF generation API." If I show them the same page, I'm asking both of them to do the work of figuring out which half is for them. That's lazy and it costs me both of them.

The two-path home page isn't a marketing trick. It's me admitting publicly that EZdoc is two products in one app, and that the right thing to do is be honest about that on the way in.

What this changes going forward

Splitting the page is the easy part. The harder part is keeping the discipline.

Every feature I ship from here on, I want to be able to answer: which audience is this for? If it's for the freelancer, does it make their one-document-tonight smoother? If it's for the team, does it make the thousand-documents-by-Friday more reliable? If a feature doesn't clearly serve one of them, I'm probably building it for me, not for either of them.

Some things serve both — the AI builder, the template library, the document editor. Those stay shared. But pricing pages, onboarding flows, default settings, empty states, the words on the buttons — all of those should know which person is on the other side of the screen.

That's the work I'm focused on now. Less "what's the next feature?" and more "is what I built actually meeting the person it was built for?" That's the question that pulls me back to the keyboard at 1 AM, and it's the question I'd rather get right than ship more code that doesn't quite land.

Try the new pages

If you need a document tonight, pay-as-you-go is here. Three generations free, no card, leave with the thing you came for. If it works for you, great. If you never come back, also great. Both are wins.

If your team needs hundreds at a time, bulk and teams is here. Bring your data, walk away with a stack of finished PDFs.

If you want to tell me I got it wrong, or you're somewhere in between these two audiences and the new pages don't fit you either, my email is [email protected] and I read everything that lands there.

— Jason