A client sent over a sample of the server requirements from one of their current hosting providers this week. The price was £750 for the server and the specs themselves looked fine. The only line that genuinely scared me was the 47-month contract attached to it. Nearly four years of commitment, no pause clause, no exit. There was no specific reason in the proposal for why the contract length needed to be that long. There was no guarantee from the vendor side that the service quality would hold for that long either. That is the part that should not be normal, and it is the part most founders sign through without questioning.
There is nothing wrong with having a contract for a defined period of time. There is a great deal wrong with a contract that does not give either side a way to pause the relationship when the conditions that justified it change. Conditions change all the time. Stores get sold, traffic profiles shift, vendors get acquired, key staff leave, a better option enters the market, the merchant pivots to a different platform. None of those scenarios should require breaking a contract. All of them should be inside the normal envelope of “we paused for two months and came back” or “we wound this down cleanly at the next renewal window.”
MageCloud Hosting Contract Note
What a 47-Month Contract Is Really Asking For
THE CONTRACT LENGTH
47 months of commitment
The vendor wants nearly four years of predictable revenue. That is a vendor business need, not a merchant business need.
THE MISSING CLAUSE
No pause, no exit, no renegotiation
Without a way to stop, the merchant carries all the downside risk if anything changes. Hosting vendors do not need this protection at the merchant’s expense.
WHAT TO ASK FOR INSTEAD
Month-to-month or a 12-month commitment with a 30-day exit
Either form gives the vendor the predictability they want and the merchant the option they need. Both sides win.
Paul Ryazanov · MageCloud · roughly £2.5K/month on our own development infrastructure, all month-to-month
Why Long Hosting Contracts Are Solving the Vendor’s Problem
The reason a hosting vendor wants a 47-month contract is that it makes their business easier to run. Churn is the most expensive line item on a hosting company’s books. Long contracts smooth out churn, make revenue forecasting tighter, and let the vendor staff up against a predictable book of business. All of those are real problems for the vendor and none of them are problems the merchant should be paying to solve.
The same instinct applied to the agency layer is what I covered in why I refuse to pay hosting two months ahead. The shape of the bill, and the shape of the contract attached to the bill, are the cleanest possible signals about whose problem the relationship is set up to solve. A vendor that demands months of advance billing or years of locked-in commitment is asking the merchant to absorb the vendor’s cash flow risk and the vendor’s churn risk. The merchant gets nothing in return for either.
What Should Be Inside Every Long-Term Vendor Contract
If a long-term contract genuinely is the right call for a particular store, the contract still needs to have a pause clause and a clean exit clause inside it. The pause clause covers the cases where the merchant needs to step back for a defined period without ending the relationship. The exit clause covers the cases where one side or the other genuinely does need to end it before the original term is up.
The shape that works for the vendor and the merchant at the same time is a 12-month minimum with a 30-day notice exit. The vendor gets a year of predictable revenue if the relationship holds. The merchant retains the option to leave on a clean monthly boundary if it does not. Either side knowing that the other can walk on 30 days is what actually keeps the work honest. A contract that locks one side in and not the other does not produce good work. It produces resentment and silent quality decay.
Why I Default to Month-to-Month for Everything I Run
Our own development infrastructure at MageCloud is billed month to month, post-paid, on every layer of the stack we control. We pay roughly £2.5K a month for the lot of it. The total saving from signing a multi-year contract on any of those services would be small compared to the cost of being locked into a vendor whose product or service changes mid-term and we cannot leave. The maths almost always works out in favour of the monthly option.
The exception is genuine enterprise infrastructure where the vendor is building specific physical or virtual capacity for the merchant, and the capacity build itself has a real cost that the vendor needs to amortise. In those cases a multi-year contract is justified, but even then the contract should include a pause and exit clause that protects both sides. The default should be monthly. The exception should be argued for explicitly, not slid into a standard proposal.
What to Tell Any Vendor Asking for 47 Months
The conversation to have with a vendor that has put a 47-month contract on the table is short. Ask them what specifically about the relationship justifies the length. Ask them what pause and exit clauses are inside the contract. If the answer to either question is vague, the conversation does not need to continue. There are plenty of reliable hosting vendors that will offer month-to-month billing without long-term commitment, and most of the ones that will not are protecting a churn problem at the merchant’s expense.
The same logic applies one layer up at the agency level. There is a parallel pattern that I covered in how MageCloud has kept clients for three years without a single contract. When the work is good, the relationship holds without a contract enforcing it. When the work is not good, the contract is what is hiding from the merchant. The shape of the contract being demanded tells you which one the vendor is expecting to be.
Where to Find Me Next
If you want to compare hosting contracts or talk through what a sensible pause clause looks like for your stack, come find me at the next Ecommerce Camp UK. The marketplace room always has at least one hosting horror story going.
Related reading: Your Store Does Not Need an AWS Cluster. The infrastructure version of the same oversold commitment.