DEV Community

Alex
Alex

Posted on Originally published at levelui.com AI-assisted

Startups ask for the cheapest option first. It is not a question about price.

Startup enquiries are more alike than founders expect. Different products, different markets, different stages, and the same ten requests, usually in the same order, often inside the first ten minutes.

That is not a complaint. Almost every one of them is a reasonable thing to want. But a request is not a brief, and the distance between what somebody asks for and what they are actually trying to buy is where most of a first budget gets spent on the wrong thing. What follows is that list ordered by how often each one comes up, which is a different list from the one I would write if I ordered it by importance.

One number frames the whole thing. In CB Insights' analysis of startup post-mortems, the most cited cause of death was running out of money, at 38%, with no market need close behind at 35%. Nothing below beats either of those. A website cannot save a product nobody wants, and an expensive one will help you run out of cash faster.

The order is frequency, not importance

Ordering by importance produces a much more flattering list, with strategy at the top and the logo somewhere near the bottom. It is also a list about the agency rather than about what founders actually say, which makes it useless as a guide to your own first conversation.

So the ranking here is how often each request appears. The one at the bottom shows up in maybe one enquiry in five. The one at the top shows up in almost all of them, frequently before anybody has described what the product does.

The cheapest option is a risk question

The single most common opening is some version of what is your cheapest option, and about half the time it arrives before the product has been explained at all. That ordering is the tell. If it were really a question about price it would come after the scope, not before it.

What is actually being asked is a question about risk. The founder does not know whether this will work, has a fixed and usually small amount of money, and is trying to find the smallest cheque that could possibly be enough. That is not stinginess. It is the same instinct that keeps a company alive long enough to find out whether anyone wants the thing.

The honest answer, and I will give it against my own interest, is that the cheapest genuinely useful thing is one page that does one job, and for a company that has not yet proven demand that is frequently the correct purchase rather than a compromise. One finished page will not carry a business through a Series A, and it is not supposed to. It is supposed to tell you whether to keep going.

The distinction that actually matters is not cheap against expensive. It is configured against developed. Below a certain budget you are buying an assembled site on an existing platform, with the ceiling that implies. Above it you are buying something built, which costs more and does not have that ceiling. Both are legitimate purchases. Being sold the first while being charged for the second is not, and it is common enough that asking which one you are getting is a reasonable opening question.

The deadline is the only genuinely fixed constraint

Second most common is a date. Demo day, the close of a round, a trade fair, an investor meeting on the fourteenth. It is almost always real, almost always immovable, and almost always attached to a scope that assumes six weeks of work.

This is the one request on the list where the constraint is not negotiable, and treating it as a preference is how agencies produce a genuinely good site that arrives eight days after the event it was for. The date is fixed, so the scope has to move, and it should move deliberately rather than by whatever happens to be unfinished on the morning of.

Cut pages before you cut quality. One page that is actually finished, fast, properly written, with a form somebody tested, beats a nine page site with three placeholder sections, and it beats it in front of exactly the audience you are worried about. The rest can follow in month two, by which point you will know which parts anyone asked about.

Worth saying plainly, because it is uncomfortable and true: on projects that miss their date, the long pole is usually the client's own review cycles rather than the build.

Ranking is a timeline, not a build setting

Will it rank on Google gets asked as though it were a checkbox in the build. Sometimes it arrives pre-packaged as is it SEO optimised, which is the version somebody else already sold.

The build determines whether you can rank and does nothing at all about when. A new domain with twelve pages does not rank for anything competitive in its first month, and Google's own starter guide says outright that changes can take anywhere from a few hours to several months to be reflected in search. Realistically you are looking at something like half a year before organic is a channel rather than a rounding error.

What a good build actually buys is that nothing is in the way. Clean URLs, real server rendered content, fast pages, correct metadata, a sitemap that is not lying about what exists. That is worth having and it is not the same product as ranking. For the gap between launch and traction, you buy traffic, and you should budget for it rather than discovering the timeline in month three.

The app is usually about the stores, not the product

Somewhere in the middle of the list, reliably, is and eventually a mobile app, where eventually means this quarter. Frequently before the web product has a single active user.

What is being bought here is seriousness. An app in the stores feels like proof the company is real in a way a website does not. There are startups whose product genuinely has to be native, anything leaning on the camera, on background location, on offline use, or on push as the core loop. There are far more where the app is a wrapper around pages that already work fine in a browser.

The cost that gets underestimated is not the build, it is the release cycle. Native means two codebases, an Apple Developer Program membership at ninety-nine dollars a year, a one-time twenty-five dollar Google Play registration, and app review sitting between you and every fix you ship. On the web a bug is a twenty minute deploy. In the stores it is a submission. For a company still changing its mind weekly, that is the expensive part.

A progressive web app installs to the home screen, works offline, and updates the moment you push. Start there and let real usage tell you whether you need the stores.

Editing everything is not the same as editing content

Can we edit it ourselves is the most reasonable request on the list, and behind it is nearly always a specific bad memory: a previous agency that charged for a typo and took four days to change a phone number.

You should have that independence. A client who cannot change their own copy stops updating the site, and a site that stops being updated stops earning. The trap is the word everything. Editing text, images, prices, team members and posts is a solved problem. Editing layout, adding arbitrary sections and rearranging the page means a page builder, and the page builder is what installs the ceiling.

There is a number for that ceiling. In the 2025 Web Almanac, WordPress sites passed Core Web Vitals 45% of the time against 74% for Wix, and the gap is attributed largely to accumulated plugins and builders rather than to the core software. If speed is a product requirement rather than a preference, the answer is a built site with defined editable regions, which is a smaller ask than it sounds.

The reference site you cannot copy

Make it look like Linear, or Stripe, or Vercel, or occasionally Apple. Always a company with a design team larger than the entire startup asking, and nearly always a developer tools or fintech product with a dark palette, enormous whitespace and one gradient.

The goal underneath is credibility, and that is a good goal. The problem is that the reference is the wrong instrument for it. Those sites are austere as a consequence of having one product, one audience, and a team to enforce it. Copy the surface onto a company with three offers and a services page and it stops reading as confidence and starts reading as a template.

The parts that transfer are cheap and unglamorous: restraint in the palette, one typeface used properly, real spacing, and content that says one thing per screen. The parts that do not transfer are the ones people point at, the ten second hero animation and the WebGL background, which on a startup site mostly cost you the first paint.

Five things nobody asks for

The rest of the list is the logo, three languages from day one, and can you put AI in it, each of which has a real answer and a longer explanation than fits here. More interesting is what never comes up at all.

Who writes the content is the first, and it is the single biggest reason projects run late. Design and build finish on schedule, then the site waits five weeks for the About page. A site with placeholder text cannot launch, so this is not a detail, it is the critical path, and it belongs in the kickoff rather than in an apologetic email in week six.

Measurement is the second. Founders ask whether the site will rank and almost never ask how they will know whether it worked. Without analytics in place on day one there is no baseline, so the redesign argument in month eight becomes a matter of opinion.

Accessibility is the third, and in the EU it is no longer optional. Since 28 June 2025 the European Accessibility Act has applied to a broad set of products and services sold to consumers, e-commerce included, with WCAG 2.2 as the practical reference. Built in from the start it costs very little. Retrofitted onto a finished site it is expensive.

The legal and privacy layer is the fourth, and it interacts badly with the second, because a consent banner bolted on in month six usually breaks the analytics nobody was checking anyway. What happens after launch is the fifth. A site is not a delivery, it is a thing that runs, and dependencies age whether or not anyone is watching.

If you only ask an agency one thing, ask what the smallest version is that would still tell you something. Not the cheapest, the smallest that produces a real signal. Anyone who cannot answer that, or who answers it by describing their largest package, has told you what kind of relationship this is going to be.

Read the full version

This is the condensed version. The full article counts all ten down properly, puts real prices on each one, and includes the arithmetic for what a first startup site actually costs at two different stages.

Ten things startups ask a web agency for

Sources

The failure statistics come from CB Insights' analysis of startup post-mortems. The Core Web Vitals comparison is from the 2025 Web Almanac CMS chapter, and the indexing timeline is stated by Google in its SEO starter guide. Store costs are published by Apple and Google Play. The accessibility deadline is Directive (EU) 2019/882, with WCAG 2.2 as the conformance reference. The ordering, the pricing and the opinions are mine.

If you take client work, I would be curious whether your enquiries land in the same order, and particularly whether the cheapest option question arrives as early for you as it does for me.

Top comments (0)