There is a particular kind of enterprise buyer who, when presented with a simple product, immediately asks for the complicated version of it.
"Can you send over the technical documentation for the platform?"
"Is there a portal for building infrastructure?"
"Do you support Terraform-based provisioning?"
These are reasonable questions if you are evaluating AWS. They are bizarre questions if you are buying a dedicated server.
The Product Is the Machine
Unmanaged infrastructure is not a platform. It is not a service with an API reference and a 200-page integration guide. It is a physical computer in a rack, connected to a network, with an operating system on it. You get root. The rest is your problem.
That is not a limitation. That is the entire point.
The customer who asks for Terraform support for bare metal is telling you something about their expectations that has nothing to do with your product. They have spent years inside managed ecosystems where provisioning means clicking through a wizard or writing a YAML file. The idea that you would just SSH into a machine and configure it yourself feels like a gap in the offering rather than the offering itself.
The Documentation Problem
What would the technical docs for an unmanaged server even contain?
Step 1: We rack the server.
Step 2: We install your OS.
Step 3: Here is your IP and root password.
Step 4: There is no step 4.
That is not being dismissive. That is genuinely the entire workflow. The documentation is the man page for SSH.
Enterprise buyers are conditioned to equate documentation volume with product maturity. A thick PDF means someone thought about this. A sparse README means amateur hour. But in unmanaged hosting, sparse documentation is not a sign of immaturity. It is a sign that there is nothing to abstract. The server is the interface. The network is the network. You either know what to do with root access or you do not.
Selling Simplicity to People Who Want Complexity
The hardest sale in infrastructure is convincing someone that less is more. That the absence of a control panel is a feature. That not having a proprietary API means they are not locked into one.
The enterprise procurement process is built for complexity. There are checklists. Compliance matrices. Vendor scorecards with 50 line items. Half of those line items exist only because some other vendor invented them to differentiate their product. "Does your platform support multi-tenant RBAC with SAML federation?" No. You get root. Create your own users.
This is not a criticism of enterprise buyers. They are doing their jobs. The process exists because vendors have spent decades building increasingly complicated abstractions on top of fundamentally simple things, and buyers need a framework to evaluate all that complexity.
The problem is when that framework gets applied to a product that deliberately opted out of the complexity arms race.
Know What You Are
The temptation, when a big customer asks for docs and portals and Terraform modules, is to scramble. Build a portal. Write the docs. Wrap your simple product in enough enterprise theater to pass the procurement checklist.
Some companies do this. They add layers. Dashboards. Managed services tacked onto unmanaged infrastructure. And slowly, imperceptibly, they stop being good at the thing they were actually good at, which was racking servers and keeping the network clean.
The better answer is honesty. This is what we sell. This is what it costs. Here is your server. If that does not fit your procurement framework, we are probably not the right vendor, and that is fine.
Not every customer is your customer. The ones who understand what unmanaged means are worth more than the ones you have to convince.