I Tried to Sell Subscriptions to My First Customers. It Was the Wrong Model.

I launched DS160.io without a pricing model

At the start of 2025 I launched DS160.io, a tool that stores DS-160 responses and auto-fills the form on the CEAC website. I’ve written before about why I built it and the seven strategies I used to launch it. What I didn’t write about was pricing, because I hadn’t figured it out. My launch post literally says “I’m also still working on finalizing the pricing.”

I built it for individual expats like me. The customers who actually pay turned out to be agencies filing DS-160s for their own clients.

Recurring revenue is what you are told to want

There was no analysis behind it. Recurring revenue is what every SaaS post-mortem, pricing guide and investor deck optimises for. MRR is the number you screenshot. So I put up a monthly plan and started selling.

My first customer was a friend, and it netted me $10 for a month of work. Selling to agencies is where it stopped adding up.

Agencies asked what happens in a dead month

Nearly every agency I spoke to raised the same objection. What happens if I have a slow month? What if I have a dead month and do not file anything at all? I do not want to be paying for it then.

At first I treated that as something to get around. Then I realised they had found the flaw in my pricing faster than I had. I was asking them to carry the cost of their own quiet periods so that my revenue could be smooth.

That risk transfer is the real trick of subscription pricing, and it usually stays invisible, because most software gets used at a steady enough rate that nobody does the arithmetic. Agency filing volume is seasonal, so it was not invisible at all. These are businesses that know their own calendar precisely, and they could see the dead months coming before they ever handed over a card.

In a dead month, they should not be paying me.

An agency’s own revenue is per application

An agency bills its client per application. Their revenue arrives in the same lumps as their workload, and both dry up in the off season.

A monthly subscription cuts across that. It turns my software into fixed overhead they carry twelve months a year to support a pipeline that only runs for part of it. In a dead month they are paying full price for an idle login. That is not payment for value. It is payment for inertia, or for forgetting to cancel.

Charging per form puts my fee in the same unit as their invoice. It stops being overhead and becomes a cost of goods sold, incurred only on applications they have already billed a client for. I could not defend a monthly fee in the sales conversation. I have never had to defend this one.

A subscription pays me most when the product is used least

Under a subscription my best customer is the agency that signs up, never rolls it out to its filing staff, and forgets to cancel. Zero support burden, zero infrastructure cost, full revenue. My worst customer is the busy agency running hundreds of forms through Form Pilot in peak season.

So the model points me at making cancellation harder, timing the renewal email carefully, and not reminding a dormant account that it is still paying. None of those make the product better. A subscription decouples my revenue from my customer’s outcome, and once decoupled, the cheapest way to grow revenue is no longer to improve the product.

I moved to charging per form

The unit is one completed DS-160.

• Low usage should mean a lower bill, because they got less out of it. That is not generosity. It is the only version of the deal I can say out loud without flinching.
• Heavy usage should mean I get paid more. More forms means more value delivered, and more of my compute and support consumed.
• I should be incentivised to drive usage up, because that is now the only way my revenue grows.

That last point changed how I work. Under a subscription, an agency that buys a seat and never files through it still pays. Under usage-based pricing that account is a total loss, so every drop-off is my problem: the confusing onboarding step, the Form Pilot run that fails silently, the junior staffer who cannot work out how to add new travel to a returning client’s form. Activation stopped being a marketing metric and became revenue.

Nobody asks what they are paying for next month any more.

Usage-based pricing has its own failure modes

It can reward inefficiency. If you bill per API call or per retry, you are paid to burn more of them. Price the outcome rather than the mechanism. My unit is a completed DS-160, so making Form Pilot twice as efficient is margin I keep rather than revenue I lose. If you cannot name a unit that means something to the buyer, that is a signal about your product.

Unpredictable bills scare people. It bites less here because the unit is discrete and the agency knows its own case load, so the bill is something they can forecast and pass through to the client. Where volume is genuinely unpredictable, use hard spend caps and prepaid credit packs. Vague overage is profitable, which is why so many vendors leave the anxiety in place.

You lose revenue predictability. This is the honest reason most founders will not do it. My revenue now tracks agency filing seasons instead of a smooth MRR line, which means I have quiet months too. What I gave up was revenue from accounts that were not getting value, and that was always a loan against my churn rate.

It is more work to build. Metering, idempotency, refunds when an automation fails, and billing that is correct to the cent.

Charge for the job, not for access

I am not a purist. For most products the hybrid is right: a small platform fee, a usage component priced on a unit the customer recognises, and caps or prepaid credits so they control their ceiling.

For DS160.io it is simpler, because the job is discrete and my customers already sell it that way. Their client has a form to file. They pay me for that form.

Run one test on your own pricing page. Work out when you would notice if a given customer’s usage dropped to zero next month, and whether you would care. If the answer is at renewal, and not much, the model is working against you.

TL;DR

I priced DS160.io as a subscription because that is what you are supposed to do. My paying customers are visa agencies, and nearly all of them asked the same thing: what about a slow month, or a dead month? Their filing volume is seasonal and they bill their own clients per application, so a flat monthly fee made my software an overhead they carried through the off season. Charging per form puts my fee in the same unit as their invoice, so it only lands when they have revenue. Low usage means a lower bill, high usage means I earn more, and the only way to grow is to get more forms successfully filed. Pick a unit that does not punish you for being efficient, and give customers a ceiling they control.