Notities
Wat ik leerde bij het maken van websites, huisstijlen en producten die hun geld moeten opbrengen. Prijzen, analyses en werkwijze, geschreven door wie het werk doet. De notities zelf zijn in het Engels.
Most of it. Ramp leads with the buyer’s outcome, puts one action in the first screen and repeats it, links its big number to the method, asks a one-question quiz in the buyer’s words and answers the switching worry on a button. The live counters, the video and the 85,000 customers need Ramp’s scale.
By claiming its category in eight words with no adjectives, showing the product instead of describing it, proving itself with dated releases, and leaving the arguing to a written method. It also serves AI agents a markdown copy of the page. A young company can copy all of that except the reputation.
A website from me is one fixed price for up to about six pages, designed and built by one person, with a CMS, redirects, tracking and a handover. Most of the money pays for decisions, not typing. More pages, more copy and integrations raise it, and you see the new number before I start.
Because a buyer who knows the price has a better first call, and one it doesn’t suit can leave without booking. ‘From’ is where a scope starts. Your own price is fixed in writing after the call, before any work starts, and then it doesn’t move.
Probably, unless something stops it. Check in this order: search crawlers allowed, page indexed with a snippet, words in the HTML without JavaScript, answers first, evidence on the page, markup and dates that match, mentions elsewhere. An llms.txt file comes last, if at all.
For the decisions and the checking. AI drafts research, first passes and boilerplate code. I decide what to build and what to leave out, make every design decision, read every line before it ships, and answer for the result. The price is fixed for that result, so how fast the AI was is my risk.
Move it piece by piece, unless the whole product is small enough to rebuild in one short project while feature requests wait. A rewrite stops your releases until it is finished. A piece-by-piece move keeps them going, and if you stop halfway you still have something that works.
It depends on what the software is meant to do, and what you say it does. Software that only stores, sends or schedules is usually not a medical device. Software that works on one patient’s data to inform a diagnosis or a treatment usually is. Decide it module by module, in writing, before design starts.
List every old address before anything is designed, give each one a permanent redirect to its closest new page, change one thing at a time, and watch the numbers for ninety days. Nobody can promise rankings. Anyone can account for every URL.
Add up the hours your team spends re-typing and checking the same facts, then the errors that get caught late. If one year of that costs more than the tool, build it. If it doesn’t, or a product you can buy already fits, don’t.
Divide the price by what one new customer leaves you after costs. That is how many extra customers the site has to win. Then check whether your traffic can supply them within a year. The inputs come from your own analytics; benchmarks only tell you if they look odd.
Fast enough is Google’s ‘good’ line on three measures, for three visits in four on phones: the main content in 2.5 seconds, a reply to a tap within 200 milliseconds, and a page that barely jumps. Below that line, fix speed first. Above it, I would usually spend the money on the offer.
These notes answer the questions people ask before they hire a designer and developer: what it costs, whether it pays, what can go wrong. Each one gives the answer first and links every number to its source.