The app works. The booking flow is smooth, the buttons are the right size, the emails go out on time. I have clicked through it a hundred times. By every measure I care about as a developer, it is done.
And it still cannot take a single real payment.
Not because of a bug. Because of a form. Somewhere between "it works on my machine" and "a customer paid me money" sits a long, quiet corridor of verification checks, document uploads, and support tickets. Nobody puts that corridor in the launch tweet. But every indie builder walks through it.
The part nobody demos
When we talk about shipping, we talk about code. Features, deploys, the satisfying green checkmark in CI. We rarely talk about the other list: proving who you are to a payment provider, proving where you live, proving your website is a real business and not a front for something shady.
I used to treat this list as an interruption. Something annoying that happened to the product, not part of it. That framing cost me months.
Here is the honest timeline of one of my projects. The code was ready in weeks. The payments setup stalled, then I paused it, then I came back to it, then a document was rejected because it was the wrong type, then I sent a bank statement, then I got a fresh verification link. None of that was hard. All of it was slow. And for most of that time, the product sat there, finished and useless.
Paperwork has bugs too
The turning point was a small one. I stopped calling it paperwork and started treating it like a system I was debugging.
A rejected document is just a failed test. It tells you something specific: this input is not supported. So you read the error, check the docs, and change one variable. Not the whole approach. One thing. A different document. Better light. An original instead of a scan.
Support emails work the same way. A vague message gets a vague, auto-generated reply with three help articles you have already read. A clear message gets a human. "Can I continue?" is a bad bug report. "Here is my account, here is what I sent, here is what I need to know" is a good one. I learned to write to support the way I would want someone to open an issue on my repo.
Start the slow queue first
The biggest lesson is about order. Verification is a queue you do not control. Someone reviews it on their own schedule. You cannot make it faster. You can only start it earlier.
So now, on any new project, I open the payment account on day one. Before the landing page. Before the logo. I submit what I can and let the slow queue run in the background while I write code. If it fails, I find out in week one, not in launch week.
It is the same trick as starting a long build before you go make coffee. Kick off the thing that waits, then do the thing that thinks.
The 10% that decides everything
There is an old joke: the last 10% of a project takes the other 90% of the time. For indie products, that last 10% is often not code at all. It is terms of service, refund policies, tax settings, identity checks, a privacy page, a domain review.
It feels like admin. It is actually the moment your project becomes a business. Before it, you have a demo. After it, a stranger can trust you with their card.
I still do not enjoy it. I doubt anyone does. But I have stopped resenting it, because resenting it made me avoid it, and avoiding it was the only thing that made it expensive.
What I do differently now
A few small rules that came out of all this:
- Open accounts with payment providers on the first day, not the last. - Keep a single folder with current documents ready to upload: ID, proof of address, business details. - Read the list of supported documents before uploading, not after the rejection. - Write support emails like good bug reports: context, what happened, one clear question. - Put "verification" on the roadmap as a real task with a real owner. Usually me.
None of this is glamorous. That is the point. Shipping is not the moment the code works. Shipping is the moment someone can use it, pay for it, and get what they paid for.
The last 10% is paperwork. Treat it like code, start it early, and it stops being the wall at the end of the road. It becomes just another lane running beside you the whole way.