Looking for the most trusted design agency for AI companies? Book a call with Studio Maydit

AI Infrastructure Website: Selling to Two Buyers

Summarize with AI

An AI infrastructure company website has to pass two readers in one scroll: the engineer who tries your API and the person who approves the spend. The engineer wants a code sample, a benchmark with its method, and a price he can turn into a monthly number. The approver wants to know where the data goes, how often you have been down and what you have been audited for, and she wants it near the top of the page, not in the footer.

Most infra sites are written by the people who built the serving stack, so they speak fluently to the first reader and hardly at all to the second. That is why so many of them collect plenty of API keys and very few contracts. Your team knows the system is fast, careful with data and stable. A stranger with a budget cannot see any of that unless the page shows it.

Picture an example company that serves open-weight models through an API. The hero reads Open models, served fast. Under it sits one button, Get API key, and a small grey link, Read the docs. The first thing below the fold is a bar chart titled Time to first token. This company's bar is the shortest of five, and the label says p50: 112 milliseconds. The chart has no date, no hardware, no prompt length, and the other four bars are labelled Provider A to Provider D.

Next comes a curl snippet with a copy button, then a grid of fourteen model cards, each with a context window and a price per million tokens. Then the footer. In small grey type, the footer holds the links the second reader came for: Security, Status, Enterprise, Privacy. The Security page has three sentences and a SOC 2 logo with the words Type II in progress, and no date. Status says All systems operational, with no history. The Enterprise link opens a form with nine fields.

Everything above the footer is true and well made. None of it answers the person holding the budget.

Tuesday the engineer, Thursday the person who signs

Follow that page through one week at a prospect, a mid-size company with a support product built on a model. On Tuesday a staff engineer lands from a search. He copies the curl snippet, swaps in his new key and gets a response back almost at once. He drops the link in his team channel with one line: this is quick, worth a look.

On Thursday his head of platform opens the same link. She has no use for the curl snippet. She has a list. Does the vendor keep our prompts? Which region does the traffic run in? What was uptime last quarter, and is there an SLA? What happens to the bill at ten times today's volume? Who else runs production traffic here? She scrolls past the chart she cannot check and the model grid she does not need, down to the footer. She opens Security, reads three sentences, and emails the vendor a sixty-question security questionnaire.

That questionnaire is where the deal slows down. Nothing on the page was false. It simply never spoke to her, so the conversation moved to email, where every answer takes days instead of a scroll.

What the founder sees from his side of it

The founder sees the Tuesday half. Each morning he scans new signups, and plenty of the email domains belong to companies he would love to sell to. He forwards the best ones to his sales lead with a note asking for a call. On most of the calls that do happen, the first question is about data retention.

The Thursday half reaches him as paperwork. His sales lead keeps a document of stock answers and pastes from it into every questionnaire. The same six answers go out each time: no prompt retention by default, two regions, an audit underway with an end date, status history going back eight months, a named support contact, and lower rates on committed spend. Every one of those answers is good. None of them is on the website.

That is the gap. The team knows the system keeps no prompts because they wrote the code that drops them. The approver has never seen that code, and the homepage does not mention it. They know their product and nobody else does, and the page was written as though everyone did.

Why a long signup list is not revenue

For an infra company the engineer's signup is cheap to win and costly to serve. AI product builders average around 52 percent gross margin against 70 to 80 percent for traditional software, because inference and GPU costs sit directly in cost of goods. An infrastructure company feels that more than anyone, since the GPUs are the product. Every free account that runs test traffic and never turns into a contract is paid for in compute.

Product-led benchmarks, measured on SaaS companies rather than AI ones, put the freemium free-to-paid median at 2 to 5 percent. For infra, that first card swipe is not where the money is. The money is in the step from one engineer's personal card to a committed contract, and that step goes through the approver. The Series A bar for AI startups is now around 3.5 million in ARR (Carta, Q1 2026), and committed contracts are how an infra company reaches it. Investors check the site for that too, and what investors look at on your website covers how.

Founders count runway in months. A security review that drags across a quarter is a quarter of runway spent waiting on answers the homepage could have carried.

Pick one audience is the wrong advice for infra

The usual advice is to choose: developer-first or enterprise. That advice comes from software where the person who uses the tool often pays for it. In infrastructure they are almost never the same person. Write only for the engineer and you get a champion who cannot close. Write only for the approver and you get a page of Enterprise-grade and Talk to sales, and the engineer leaves for a provider whose docs he can read in two minutes.

So do not pick. Put them in order. The engineer owns the first screen, because he arrives first and he is the one who will try it. The approver owns the second screen, because she arrives days later already knowing what the product does, and she reads further down a page than anyone.

The hero then carries two actions, and the second matters more than it looks. Get API key is for the engineer. The approver's button should not be Contact sales, because a sales form is a wall to someone who wants to read first. Make it Read the security overview, and send it to a page that clears her list without a call. The developer-tool look described in the Linear, Vercel and Raycast aesthetic suits that first screen, since it tells an engineer that engineers built this. It tells the approver nothing about data, uptime or audits.

Engineers assume any chart on a vendor homepage was run on the vendor's best day. Everyone in the field knows benchmarks get gamed, and saying so out loud is the quickest way to be believed. So the 112 milliseconds in the example is worth less than it looks. Nothing sits under it.

Under every number, print the method in one line: model, hardware, input and output length, concurrency, region and date. Link the script so an engineer can rerun it. Name the comparison or drop it, because four anonymous bars read as a chart you would rather nobody checked. Show the slow number too. A p99 beside the p50 tells the engineer you already know his next question.

The approver reads the same chart another way. She does not care about one fast request. She cares whether speed holds at her volume, and whether there is a record to prove it. One line under the chart linking to ninety days of status history serves both readers at once.

Evidence a stranger can read on sight matters most when a product looks like a dozen others on paper, which is true of most inference providers. Dualite, a local-first AI builder, had the same problem in its own category: a strong product that first-time visitors could not tell apart from its rivals. We led brand direction and designed and built the site in Framer so the difference showed on sight, and stayed on as product design partner as the platform passed 100,000 users.

Pricing an engineer can turn into a monthly bill

A price per million tokens is honest and close to useless on its own. The engineer has to work out tokens per request, requests per day and days per month before he can say a number in a meeting. Most do not bother. They guess, and the guess lands in the team thread as too expensive or fine.

Put a small calculator on the pricing page with four inputs: model, requests per day, average input tokens and average output tokens. Out comes a monthly figure. The engineer posts a screenshot in his team channel, and the approver finds a number she can take to finance. Under the calculator, answer her side in plain lines: what changes above a committed volume, whether spend caps and alerts exist, whether dedicated capacity is on offer, and how invoicing works.

Six changes to make before Friday

  • Write down the approver's list. Ask your sales lead which questions come back on every security questionnaire. That list is the brief for your second screen.
  • Move the answers out of the footer. Under the hero, add one row: default data retention, regions, audit status in plain words with a date, and a link to status history. In progress with no date reads as not started.
  • Change the second button. Replace Contact sales with Read the security overview, and let that page answer the list before any form appears.
  • Print the method under every benchmark, with a date and a link to the script. If you cannot print the method, take the chart down.
  • Add the pricing calculator: four inputs, one monthly number, and a line about committed volume underneath.
  • Test the page on two strangers. Ask an engineer at another company to find the curl snippet, and someone who has signed a vendor contract to find your retention policy. If either needs more than one scroll, the order is wrong.

If you would rather hand the rebuild over, this ranking of website design agencies for AI infrastructure companies compares studios that take on this kind of site.

Studio Maydit designs and builds websites for AI founders in the US, UK and Europe, in Framer, Webflow or custom code, and carries on into product design when the API console needs the same care. For an infrastructure company our website design work is usually both halves at once: a first screen that tells an engineer this was built by people who ship, and a second screen that lets the person with the budget finish her list without sending a questionnaire. A fixed-scope project takes three to four weeks. If your sales lead pastes the same six answers into every security review, book a 30 minute call and we will show you where they belong on the page.

Frequently given answers

Sid, founder of Studio Maydit

Looking for something else?

Book a call with the founder.

It needs to serve two readers in one scroll. For the engineer, that means a working code sample, benchmarks with their method, and pricing he can turn into a monthly figure. For the person who approves the spend, it means data retention, regions, audit status and uptime history, placed on the second screen rather than in the footer.

Lead with developers on the first screen and put the enterprise buyer's evidence on the second. The engineer usually finds and tests the product first, and the approver arrives days later with a list of questions.

Print the method under every number: model, hardware, input and output length, concurrency, region and date. Link the script so engineers can rerun it, and show tail latency next to the median. A chart with no method reads as a chart run on the vendor's best day.

Near the top of the homepage, in plain words, with a link to a full security page. State the audit status honestly with a date, and say what happens to customer prompts and outputs by default. In the footer, it turns into an emailed questionnaire.

Yes, and in a form an engineer can turn into a monthly bill. A price per million tokens on its own makes him do the maths, so add a simple calculator for requests, input tokens and output tokens. Under it, explain committed volume and spend caps for the approver.

Usually the website answers the engineer and not the person who signs. The approver's questions about data handling, uptime and audits end up in email threads and questionnaires instead of on the page. Moving those answers onto the second screen of the homepage shortens that detour.

Let’s chat about
what you’re building

Tell us where you’re headed, and we’ll scope the right plan for you.