Who Hosts This in Year Two? The Question Founders Ask Too Late.
A founder read through our proposal on a call. Scope, timeline, price, all of it. Then, near the end, he asked the question almost nobody asks before signing: if this becomes a year-to-year thing, who manages and hosts the URL?
It was the best question on the call.
Most founders get there about fourteen months later. It usually arrives as a renewal notice from a vendor they don't remember choosing, or as a text at 9pm that starts with "hey, is the site down?"
The build has an end date. The software doesn't.
A proposal answers a short question: what gets built, by when, for how much. Six weeks, eight weeks, twelve. There's a start date, a finish date, and a number in between, and every person on that call is staring at the number.
The software answers a much longer question. It has to exist next November. It has to still be reachable when a customer types the domain into a phone. Somebody has to keep a card on file for the database. Somebody has to notice when a certificate is about to expire. None of that lives inside the build number.
It isn't hidden, exactly. It's just not the thing anyone is looking at while they're looking at the price. That gap is where founders get hurt, and not by a bad build. By the quiet assumption that the build was the whole cost.
"Who hosts it" is a list, not a vendor
When a founder asks who hosts the app, the honest answer isn't a company name. It's an inventory.
The domain registrar. DNS. The app host. The database. The transactional email sender. Probably file storage, error monitoring, and an auth provider. Five to eight accounts, each with a renewal date, a payment method, and an owner.
That last column is the one that decides your freedom, and it's the one nobody reads. The vendor barely matters. Any competent team can work with any of them. The question that determines whether you can walk away is whose name is on the account.
We've watched a build sit nearly still for weeks waiting on access to accounts the founder technically owned but couldn't produce logins for. The engineering was ready. The credentials were in somebody's inbox, behind forty other emails. Nothing about it was dramatic and nobody was the villain, which is exactly why it keeps happening to people.
Why our hosting tiers go out with the SOW
We attach hosting and maintenance pricing to the proposal. Same email, before anyone signs anything.
That isn't generosity, it's context. A monthly number that appears after you've signed reads like a tax. The identical number sitting next to the scope reads like what it actually is, which is the cost of the thing continuing to exist. Same figure, opposite meaning, and the only variable is when you saw it.
There's a version of this business where you quote the build low, stay quiet about the recurring cost, and let it surface once the contract is signed and the founder has nowhere convenient to go. That version closes more deals. It also produces a founder who feels tricked in month four, and people who feel tricked don't refer you.
The tier nobody buys
Our top maintenance tier comes with a fast guaranteed response window. Almost nobody takes it. Our honest internal read is that almost nobody ever will.
It stays on the sheet.
Not as a decoy. Because it prices the option truthfully. A founder looking at three tiers can see roughly what a guaranteed same-day response costs to staff, and can then decide, with real information, that they don't need one. That's a decision.
Take the top tier off the sheet and the middle tier stops being a choice and becomes a default. Defaults are how founders end up paying every month for something they never actually evaluated. A menu with one item isn't a menu. It's a bill.
The ownership test
Every account goes in the founder's name on day one. Not at handoff. Not "we'll transfer everything when the engagement wraps."
Day one, for a boring reason. A transfer scheduled for the end of a relationship happens at the exact moment both sides have the least energy for paperwork. If the accounts start in your name, there's no transfer. There's a password you already have.
This is also the cleanest test you can run on a shop you're considering. Ask where the accounts live during the build. If the answer involves their dashboard, their card, their organization, and a promise to sort it out later, you're not buying software. You're renting it, and the rent is your inability to leave.
We'd rather you be able to leave. We've written before that outgrowing us is the plan. You can't outgrow a partner who's holding your domain.
Three questions to ask before you sign
Ask these of us, or of anyone else you're considering.
- What's the full list of accounts this app needs in order to stay online, and whose name is on each one?
- What does month 13 cost, in dollars, and what exactly do I get for it?
- If I hire an in-house engineer next year, what do you hand over, and how long does it take?
A shop that answers all three quickly has thought about your second year. A shop that goes vague on any of them has thought about their invoice.
The first chapter isn't the book
The founder who asked that question wasn't being difficult or slowing down the call. He was doing the thing most founders skip. He read the build as the first chapter instead of the whole book.
Your app's second year is being decided right now, in a document you're about to sign, by a section most people skim. Ask the year-two question before it gets answered for you. It's cheap to ask now and expensive to discover later.