← Back to Blog

It Looks Like a Developer Built a SaaS

Paul Allington 7 October 2025 8 min read

"It looks like a developer built a SaaS."

That's the most devastating piece of feedback I've ever given to an AI. Not because it was wrong, but because it was perfectly, brutally accurate. The page was functional. The layout was clean. The typography was sensible. And it looked like every other Bootstrap-template SaaS application that's ever been deployed by a backend developer who considers "aesthetics" to be a font choice between Inter and Roboto.

I've spent months fighting this problem, and I think it's one of the most underreported limitations of AI-assisted development. The code works. The design doesn't. Not because it's broken, but because it's generic. And generic, in a world where every AI-built application uses the same design patterns, is the new ugly.

The Bootstrap Uncanny Valley

There's a specific aesthetic that AI produces when you ask it to build a web page. I call it Bootstrap Uncanny Valley. It has all the correct elements - hero section, feature cards, testimonial blocks, pricing table, call to action. The spacing is consistent. The colour palette is inoffensive. The responsive breakpoints work.

And it is completely, utterly forgettable.

The problem isn't that AI produces bad design. It's that it produces average design with absolute confidence. It doesn't know the difference between a page that functions and a page that converts. Between layout that's correct and layout that's compelling. Between a website and a SaaS admin panel with a marketing hat on.

"This doesn't look like a website. It looks like a developer built a SaaS."

I've said variations of that sentence more times than I'd like to admit. "Still feels adminy, not markety." "This is functional but it's not selling anything." "It looks like a dashboard pretending to be a landing page."

The Showcase Catastrophe

When I was rebuilding The Code Guy website, I had Claude build showcase pages for my products - Task Board, TestPlan, CoSurf. Each page was supposed to be a proper product showcase: what the product does, why it matters, who it's for.

The first versions were dreadful. Not broken. Not ugly. Just... bland. They read like documentation pages with screenshots. Feature lists with icons. Benefit statements that could apply to literally any software product. "Streamline your workflow" - could be a task manager, could be a CRM, could be a spreadsheet. "Powerful yet intuitive" - has any product in the history of software ever described itself as "weak and confusing"?

I looked at all three pages and said something I now consider a turning point: "ALL of the showcase pages are really bland and horrible. Either we need to ditch them, or we need to make them proper. You decide."

Claude decided to make them proper. And to its credit, the next iterations were genuinely better. But getting from "bland and horrible" to "actually good" took weeks of iteration, not the single conversation that AI development timelines would suggest.

Learning to Speak "Marketing" to an AI

Here's the thing though. I discovered that the way you talk to AI about design fundamentally changes what it produces. And the key insight is this: you have to give it a persona to design for, not a specification to implement.

"Build a landing page for a task management tool" produces Bootstrap Uncanny Valley every single time. But "think marketing - what would a small business owner who's never heard of us think when they land on this page?" produces something noticeably different. The language changes. The hierarchy changes. The emphasis shifts from features to outcomes.

I started using persona-based language for all design work. "What would our personas think?" became a standard prompt. Not because it's a magic trick, but because it forces the AI to evaluate its output against a human response rather than a technical specification. And that evaluation, even when imperfect, catches the worst of the generic-ness.

"Think marketing, not engineering" was another phrase that reliably improved output. AI defaults to engineering thinking because that's what most of its training data looks like. When you explicitly shift the lens, you get different results. Not always better results, mind you. But different, which at least gives you somewhere to iterate from.

The AI Slop Aesthetic

There's a term floating around the internet: "AI slop." It usually refers to AI-generated content that's technically competent but soullessly generic. I think it applies to design as much as it applies to text.

AI-generated design has tells. Excessive use of gradient backgrounds. Card layouts with rounded corners and subtle shadows that all look identical. Hero sections with large text and a stock-photo-style illustration. Pricing tables with a "Most Popular" badge on the middle tier. These aren't bad design choices individually. But when every AI-generated page uses them, they become a signal that screams "nobody made deliberate design decisions here."

The challenge is that these defaults exist because they work. Cards with rounded corners and shadows are genuinely good UI patterns. Pricing tables with a highlighted middle tier genuinely convert better. The problem isn't the individual elements - it's the combination. When everything is a default, nothing stands out.

Breaking out of AI slop requires the one thing AI can't provide: taste. Someone has to look at the output and say "this is competent but it's not us." That someone is the human. Every time.

The Brand Guidelines Approach

The most effective technique I've found is giving AI explicit brand guidelines before asking it to design anything. Not just colours and fonts - those are table stakes. I mean the personality. The feeling. The things that make a brand recognisable even if you can't see the logo.

For a client project, we spent a full conversation establishing the design language before writing a single line of CSS. What does "professional but approachable" look like? What's the difference between "clean" and "sterile"? What imagery and metaphors fit the brand? How does the site's personality differ from competitors?

This front-loaded investment paid off massively. When AI had a brand framework to work within, it produced design that was recognisably "theirs" rather than generically "nice." Not perfect - it still needed human curation - but the starting point was miles ahead of the generic alternative.

The problem is that most developers skip this step. They want the page built, not the brand defined. And AI is happy to oblige, because it can build a perfectly functional page without any brand context at all. It just builds one that looks like everything else.

The Iteration Tax

I'll be honest with you: getting good design from AI is expensive. Not in money - in time and attention.

A functional page takes one conversation. A good-looking page takes five. A page that genuinely feels like a specific brand and not a template takes ten or more. Each conversation involves reviewing the output, identifying what feels wrong (which is harder than identifying what is wrong), articulating that feeling in words the AI can act on, and then reviewing again.

I call this the iteration tax. It's the cost of using AI for creative work where "correct" isn't the same as "good." Backend code is either right or wrong. Design is right and also somewhere on a spectrum from generic to distinctive. Getting to the distinctive end of that spectrum requires a human eye and a willingness to keep pushing.

"Not quite. The layout's fine but it doesn't feel premium enough."

"Better. But the typography hierarchy isn't giving enough weight to the value proposition."

"Close. Can you make the feature section feel less like a documentation page and more like a sales pitch?"

Each of these is a valid piece of feedback that a designer would understand instantly and an AI interprets approximately. The approximation gets you closer each time, but it never quite arrives. You eventually reach a point where the output is good enough and the marginal improvement from another iteration isn't worth the effort.

What I'd Tell a Developer Building a Product

If you're using AI to build a product and the marketing pages look like a developer built a SaaS - that's the default state. Don't feel bad about it. But don't ship it either.

Invest in brand definition before design implementation. Tell the AI who your users are, what they feel, and what they expect. Use persona-based prompts. Show examples of sites you admire and articulate what you like about them. Give AI taste to borrow, because it doesn't have its own.

Budget for the iteration tax. Your landing page will not be good on the first pass. Or the second. Plan for five or six rounds of refinement, and accept that the last two rounds will be you saying "it's nearly right but something feels off" and struggling to articulate what.

And when someone looks at your site and says "it looks like a developer built a SaaS" - take it as the constructive feedback it is. Because the thing about AI-assisted development is this: the code is the easy part. Making it look like a real product that real humans want to use? That's still very much a human job.

I'm getting better at it. Slowly. But every time I see a gradient background with floating card elements and a "Get Started Free" button in the exact shade of blue that every AI defaults to, I have a small internal crisis. Because I know that shade of blue. I've shipped that shade of blue. And I'm still trying to unlearn it.

Want to talk?

If you're on a similar AI journey or want to discuss what I've learned, get in touch.

Get In Touch

Ready To Get To Work?

I'm ready to get stuck in whenever you are...it all starts with an email

...oh, and tea!

paul@thecodeguy.co.uk