Go back

Web & app development guide 2026–2027: how to stand out

A figure in neon green, wearing sunglasses, standing out from a monochrome crowd of identical figures under a blue sky.

Building the thing used to be the hard part of web and app development. Now it’s the easy part, and that’s the whole problem.

You can describe a product on a Tuesday and have it deployed by Wednesday. That’s good. But once shipping got easy, shipping stopped counting, and the question is no longer whether you can build it. It’s whether what you built survives ten seconds next to four competitors who opened the same tool you did.

Here’s the checklist we work through on every build, in six parts. Skip to the one you’re stuck on.

  1. Scope
  2. Design rules
  3. Copy
  4. Technical SEO
  5. AI search
  6. Speed and mobile

1. Scope: lock it before anyone designs anything

Almost every rescue job we take has the same shape. Someone had a good idea, went straight to building, and four months later has six half-features, no launch date, and a suspicion the whole thing needs restarting.

The order that works is dull, and it holds:

  1. Someone brings the idea. Not a spec. The problem, and who has it.
  2. You pull it apart. What one action does this product exist to cause? Who pays, and what were they doing before you existed?
  3. You lock a scope in writing. What gets made, what it costs, when each piece lands.
  4. You ship in stages, so a wrong direction gets caught in week one, while fixing it costs an afternoon instead of a quarter.

Step three is the one everybody skips, and it decides whether the project ever ends. A scope document isn’t bureaucracy. It’s the only thing that lets you say no in month two without it turning into an argument.

The fastest projects we run are the ones where the arguing happened first, while changing your mind was still free. That’s a 15-minute scoping call, and it’s where most of our work starts.

2. Design: write the rules down, then obey them

The cheapest quality upgrade available to a small team costs one hour. Before you design a second screen, write down:

  • Colour: one background, one foreground, one accent, one muted grey, plus error, warning and success. If you have eleven greens, you have no green.
  • Type: one family for headings, one for body, or one doing both. Then a fixed scale of about six sizes. Never a size that exists on one screen only.
  • Spacing: pick a step, 4px or 8px, and use multiples of it forever. Half of what reads as cheap is just inconsistent gaps.
  • Radius and shadow: one radius for cards, one for buttons, one shadow. Not four of each, picked by whoever built that component on the day.
  • The states nobody draws: loading, empty, error, zero results, and first run before there’s any data. Products lose people in exactly these screens, and they’re the ones that never make it into the mockup.

Then apply them everywhere. The app, the dashboard, the transactional emails, the invoice PDF, the App Store screenshots, the 404. A brand isn’t a logo. It’s a stranger telling it’s you with the logo cropped out. Inconsistency is the thing people can’t name but absolutely feel: nobody says your heading scale changed, they just trust you slightly less and never tell you why.

This is also the best thing you can hand an AI builder. Give a model a token set and a spacing rule and it stays coherent across twenty screens. Tell it to “make it modern” and you get the average of everything it has ever seen.

Most of our branding and UI/UX design work is building that rule set, so screen forty doesn’t look like a different company than screen one.

3. Copy: how do people spot an AI-built site?

Two ways. The layout is flat in priority, and the writing has tells. Almost nobody edits the second one.

The visual tells

Centred hero, soft gradient, three rounded cards with a line icon in each, pricing table with the middle tier highlighted. None of that is wrong on its own. What gives it away is the flatness: on a page somebody designed you can reverse-engineer the arguments they had, because this heading is huge and that one is small and grey. A page where everything is equally important makes no argument at all.

Then the picture problem. A feature grid of six emoji in six circles tells your reader nobody had a screenshot worth showing. Why that happens, and what it costs you in trust, is every AI website looks the same.

The writing tells

  • The “not X, it’s Y” construction. “This isn’t just a form builder, it’s a workflow engine.” One on a page is a rhetorical move. Six is a signature.
  • Em dash pile-up. A dash in every third sentence, doing work a comma or a full stop would do better. You can often guess which tool wrote a page from its punctuation alone.
  • The rule of three, forever. Three adjectives, three bullets, three benefits. Writing by people is lumpier.
  • The vocabulary. Seamless. Robust. Leverage. Unlock. Elevate. Delve. Landscape. “In today’s fast-paced world.”

The fix takes fifteen minutes. Read your copy aloud and cut anything you wouldn’t say to a customer across a table. Then swap every sentence telling the reader how to feel for the fact that would make them feel it: “blazing fast performance” becomes “the dashboard loads in under a second on a mid-range Android.” One is a claim, the other is checkable.

None of this means don’t use AI. We use it every day, on this site included. The draft is the input, not the output, and the last twenty percent is where the differentiation lives.

4. Technical SEO: what your AI site builder skipped

The parts that don’t render. An AI builder optimises for what’s on the screen, and nothing on the screen breaks when your Open Graph tag is missing. You find out three weeks later, when someone shares your link in a WhatsApp group and it renders as a grey box with a URL underneath.

Work through this once, per site. It’s the highest-return afternoon in the build.

Per page

  • One <h1>, and headings that descend without skipping a level.
  • A unique <title> under 60 characters, with the words a stranger would type at the front. Not your brand name, which nobody is searching yet.
  • A unique meta description, 120 to 158 characters, written to earn the click rather than describe the page.
  • A self-referencing canonical URL.
  • Real alt text on every image that carries meaning, and empty alt="" only for decoration. Starter templates ship alt="" on hero images constantly.
  • Semantic header, nav, main, article, section, footer. Crawlers and screen readers read the same tree, and a page built from divs is illegible to both.
  • Link text that describes where it goes. “Read more” as an entire anchor is a wasted signal.

Per site

  • robots.txt, pointing at your sitemap. A staging Disallow: / shipped to production is the most expensive two-line mistake available to anyone.
  • A sitemap, generated rather than hand-maintained, and submitted in Search Console.
  • An OG image on every page, absolute URL, around 1200x630. Test it by pasting the link into Slack, WhatsApp, LinkedIn and iMessage.
  • A favicon, in the sizes a browser tab and a phone home screen both want.
  • JSON-LD structured data: Organization and WebSite on the home page, BlogPosting on posts, BreadcrumbList on anything nested, FAQPage only where an FAQ renders. Generate it from the content the visitor sees. Never mark up something that isn’t on the page, because Google hands out manual penalties for it.
  • One trailing-slash convention, with internal links matching it exactly.
  • A working 404, plus redirects for every URL you’ve moved. A live URL is permanent, and changing a slug throws away what it earned.

Then verify instead of assuming. Run view-source: and read the head, put your schema through Google’s Rich Results Test, load /robots.txt and your sitemap in a browser. It turns something up every time.

Technical SEO and structured data is the smallest piece of work we do for most people, and the one with the shortest path to a result.

5. AI search: does llms.txt actually do anything?

Probably a little, and nobody can prove how much. No major search engine has confirmed it reads the file, and Google has been dismissive in public.

llms.txt is a proposed convention: a markdown file at your site root listing your key pages and what they cover, so a model gets a clean map instead of navigation soup. Twenty minutes to write, nothing to lose, and we ship one here. Treat it as a cheap bet rather than a strategy.

What we’re reasonably confident does help:

  • Server-rendered HTML. Content that only exists after JavaScript runs is a coin flip, and several AI crawlers don’t execute JS at all.
  • Answer-shaped writing. A question as a heading, then a direct answer in the first two sentences under it. Models quote passages, not pages.
  • Checkable specifics. Numbers, dates, named things, sources. Generic marketing prose gives a model nothing to cite, because nothing in it could be true or false.
  • Structured data, the machine-readable version of those same facts.
  • A robots.txt that doesn’t block AI crawlers by accident. Some sites should block them. Decide it deliberately.
  • Being mentioned elsewhere. Models weight what other sites say about you.

Mostly it’s the discipline that always worked.

6. Speed and mobile: the tiebreaker

Give every image explicit width and height so nothing jumps as the page loads. Preload the hero image only, lazy-load the rest, serve modern formats. Then ship as little JavaScript as you can get away with. Most marketing pages need approximately none, and a framework loaded to power one accordion is a cost paid by every visitor who opens the page.

Then test on the right device. Not your laptop: most of your traffic is mobile, mobile is what Google indexes, and a site that feels instant on a MacBook can feel broken on the phone your customer owns. That constraint drives most of the decisions in our web development and mobile app development work.

What changes in 2027

The floor keeps rising, and when the baseline rises everything standing on it flattens into the same silhouette. The only thing left with an outline is whatever somebody deliberately pushed higher. None of the six above is hard. They’re just slow, which is what the tools have trained everyone out of.


If you’ve got a product idea and no clear path to something shipped, that’s the part we’re useful for. It starts with a call and a scope you can hold us to, then the build: web and mobile, the design system underneath, the SEO pass, and AI systems inside the product if it needs them.

Book a 15-minute scoping call and tell us what you’re trying to ship. If you don’t need us, we’ll tell you that too.

Have something you need built?

Tell us what you're making. You'll get a straight answer on scope and timeline.

Start a Project