Claude Code developer: A senior product designer who ships with Claude Code

In October I had an agent build a 25-screen dashboard in one evening. It ran. Every screen looked fine on its own. Then I laid all 97 states side by side and found 21 versions of the same button, three of them broken, and two icon buttons 4px shorter than the rest. Nobody asked for any of it. The agent did what it was told, one screen at a time.

Claude Code gives a small team the output of a large one. The judgement still has to come from a person: which feature to build, which to drop, and the 4px nobody on the team will notice until a customer does. That person is what you hire here.

What founders write before they hire

From founders’ posts on Reddit this year, about apps built with AI tools:

• A Replit app that works, with a UI that looks “generic and a bit AI-generated”.
• A SaaS whose UI, iterated with Claude, Codex and Gemini, came out “generic, cluttered”.
• A first-time builder with a complex app: “Continue on lovable or hire dev?”
• A founder weighing whether to build the MVP alone or hire offshore.

Others hire by the task:

• A founder looking for a developer to finish a Lovable chatbot app built on Supabase, Stripe and Twilio.
• A post offering $120 to fix a Stripe webhook and a Supabase sync.

Under each one is the same problem. Code has become cheap to write, and nobody owns what good looks like. A Claude Code developer worth hiring takes that part: the product decisions, the design, and a reading of every change before it ships.

What Claude Code will not do for you

Claude Code can write most of a product. What it cannot do on its own:

• Decide what is worth building first, and what to leave out of the first version.
• Notice that ten screens it wrote on ten different days no longer look like one product.
• Stop repeating a mistake it made once, because the mistake is now part of the codebase it reads.
• Tell a design problem from an engineering one when users get stuck.
• Own the result: answer for a bug, a slow page or a broken flow after launch.

I take on that part. Claude Code writes the code; I decide what it builds, design it and read every change. Behind those calls are 14 years of product work and more than 40 launches.

A designer with Claude Code, or a developer with Claude Code

Both can now get working code out of Claude Code. The code was the cheap part of a product even before agents. The expensive part is what people see and do: which screen comes first, what happens when the list is empty, where a user hesitates, what the button says.

• A developer asks whether it works. A designer also asks whether someone who has never seen it will know what to do.
• A developer gets the feature in. A designer asks whether it belongs there, and what it takes away from the rest of the screen.
• A developer finishes the main path. A designer settles the empty, loading, error and permission states before the code exists.
• A developer reads the diff. A designer looks at the running screen and sees the 4px, the wrong grey, the label that wraps on a phone.

With Claude Code writing most of the code, the designer’s half is the one that decides whether the product works for people. I bring both halves: 14 years of product design, and the code.

Why the same tool gives a different product

Claude Code does what it is asked. Two people with the same subscription get products as different as their questions. These are the questions that come from experience, and a beginner does not know to ask them:

• What does this screen look like with no data, with a thousand rows, and with an error?
• Who else uses this, and what must they never be allowed to see or change?
• What does the user do right after this, and is it one step away?
• Which few components should every screen be built from, so screen twenty still looks like screen one?

I learned to ask them over 14 years and more than 40 launches, mostly by watching real people get stuck in screens that looked finished.

I measured what happens without those questions. Given a one-paragraph brief that ended in “make it look good”, the same agent kept 43 to 50 of the 79 decisions in my detailed brief, no build had a loading or an error state, and two runs on the same stack disagreed about what the dashboard should show (the test).

Claude Code will give you as many versions of a screen as you ask for, and few of them are strong. The work is knowing which one is, why, and what to ask for next. These are the questions I ask before I keep a version:

• Is the main action the most visible thing on the screen, or one of six equal cards?
• Does it still hold with a long customer name, an empty list and a failed payment?
• Is it built from components the product already has, or from new ones nobody will reuse?
• What do I ask for next: the empty state, the view for a user without permission, or the phone width?

What an experienced eye catches when everything looks fine

On the 25-screen dashboard from the top of this page, the review that followed asked 14 questions. I kept 8 variants as intended, marked 3 to fix and skipped 3, in a few minutes. The agent fixed the three with one CSS rule, one font size and one class. Investigating 21 variants by hand would have taken an afternoon, and clicking through I would not have found the three.

A product can pass every test, open on every phone and still lose people. The costly problems are the ones nobody on the team reports, because to the team the product looks done.

• Twenty-one versions of one button across 25 screens, each fine on its own screen.
• A main action that is not the most visible thing on the screen, so people look for it.
• Grey text that a customer on an old phone in daylight cannot read.
• A form that throws away everything typed when one field is wrong.
• An empty state that tells a new user nothing about what to do first.
• Two words for the same thing in two places, so users think they are two different things.
• A flow that only works for the person who built it, because they never have to guess.

I find these the way I have for 14 years: I use the product as a new customer would, then lay every screen and state side by side, where the differences stop hiding.

None of this is new knowledge. Jakob Nielsen’s usability heuristics, published in 1994, say users should never have to “wonder whether different words, situations, or actions mean the same thing” (Nielsen Norman Group). NN/g’s guidance on empty states asks the screen to say what could appear there and how to fill it (Kate Kaplan, 2021). An agent can recite these rules when asked. Applying them to screen twenty, unasked, takes someone who checks.

A product in a day is a demo

Claude Code builds a first version several times faster than anyone could two years ago. That part is real, and I use it every day. What it builds in a day is a demo: the main path, on good data, for the person who built it.

The speed also feels bigger than it is. In a 2025 study by METR, 16 experienced developers took 19% longer on real tasks with AI tools, and afterwards still believed the tools had made them about 20% faster.

In Stack Overflow’s 2025 survey of more than 49,000 developers, the most common complaint about AI tools, from 66% of them, was code that is “almost right, but not quite” (Stack Overflow). Veracode tested more than 100 language models on 80 coding tasks: in 45% of them the working code carried a security flaw (Veracode).

What a one-day product leaves for later:

• Sign-in, password resets, and what happens when a session expires halfway through a task.
• Roles and permissions: who can see, change and delete what.
• Empty, loading and error states on every screen, the twentieth as well as the first.
• Payments, refunds, invoices and the emails that go with them.
• Phones, slow connections and the browsers your customers really use.
• Data that has to survive the next change to the product, and the one after it.

Each of these is a day or a week of decisions. Claude Code makes them faster to build. The decisions are still yours to make, or mine if you hire me.

What founders believe about Claude Code, and what the evidence says

• The agent reuses what is already there. Code written with AI assistants copies more and reorganises less. GitClear analysed 211 million changed lines of code: from 2021 to 2024 the share of copied lines rose from 8.3% to 12.3%, and the share of code moved or reorganised fell from 25% to under 10% (GitClear, 2025).
• The agent can review its own work. It catches a lot, and I use it for that. A tool finds differences; whether a difference is a mistake is a design decision, and the agent that made the difference is the last one to see it.
• A kit like shadcn/ui is a design system. A kit gives you parts: buttons, fields, dialogs, with good states. It does not decide which color means success, how dense a table can be for the person who reads it, or where the one accent goes. Everyone who ships the default theme gets the same face.
• Written guidelines keep the agent in line. In my test, guidelines alone cut raw values in new code from 34 to 25. When the guidelines said 16px corners and the code said 24, the agent followed the code. With a rules file, a catalog of what each component is for and an audit it had to run until it reported nothing, it left 0, and finished in 4.4 minutes instead of 8.1.

What I build with Claude Code

• First versions. An MVP from an idea to working software on your accounts. More on design and build.
• Front ends and design systems. Components, every state and the system in code, so the product looks like one product. More on design engineering. I build the components in Storybook myself when the team uses it.
• Features in your codebase. New screens and flows in an existing product, through your normal review.
• Internal tools. Admin panels, dashboards and the tools a team needs and nobody has time to build.
• Cleanup of AI-built apps. A Lovable, Bolt, Cursor or Claude Code app that works in a demo and not for real users. More on AI-built app cleanup.
• Claude Code for your team. Part of longer work inside your team. I learn how the team works, then give its agents the context and the right direction: CLAUDE.md, rules, skills, hooks and checks, so your own engineers and agents build the same way.

How the work runs

The first complex component I shipped into a design system myself went out with regressions: it worked where I built it and broke in two places I had not opened. Now I check a change everywhere it is already used before it ships.

• Start. Access to the repository, or a new one on your accounts, and the first task in code on day one. An idea is enough to start.
• Build. Claude Code writes, I decide and design. Every change is read before it goes in, and goes through your normal review.
• Checks. Tests, type checks and a pass through the running product before anything is called done.
• Handover. The code, the design system and the rules files your agents read stay in your repository, so the next person or agent builds the same way.

When day one falls depends on my schedule: write and ask. If it is urgent, a faster start may be possible.

What it takes from you

Less than a hire: no recruiting, no onboarding plan, and nobody new to manage.

• Access to the repository and the accounts the product runs on, or the go-ahead to create them in your name.
• Whatever exists already: a few lines about the idea, notes, designs in Figma, a prototype in Lovable, Bolt or Cursor, or a codebase.
• One person who answers questions about the product and decides when two good options compete.
• Your team’s normal review of pull requests, if it has one.
• Calls as often as you want them. The rest is my work.

You see the work in the running product as it goes, one reviewed change at a time, so nothing waits for a big reveal at the end of the month.

What a month includes

A month is priced as one thing. These are the parts, and what each costs as separate work:

Three ways to build with Claude Code

Hiring a Claude Code developer: what you see first and what is underneath

Each option fits some work. An hourly developer is right for a well-defined task, an agency when you need a team at once, a kit for a prototype or an internal tool. A product that has to hold together across many screens needs one person who owns how it looks and behaves.

Next to a full-time hire

The median total pay of a software engineer in the US is $200,000 a year (Levels.fyi), about $16,700 a month before benefits and recruiting. A product designer is a second salary on top.

The average base pay of a principal product designer in the US is $179,294 a year (PayScale), about $15,000 a month. Together, over $31,000 a month for the two salaries alone, after months of hiring.

This starts from $8,000 a month, with the product decisions, the design and the code in one person, and no handoff between them.

What the product says about your team

The founders above worried that their UI looked “generic and a bit AI-generated”. Customers see the same thing, and they judge the team by it before they meet anyone.

• An investor who opens the product on their own phone sees the empty, error and permission states. A demo on good data says the team can prompt. A product with those states says it knows its users.
• A customer who checks one number, or loses one form, stops trusting the rest of the screen.
• Your engineers read one set of components, rules files and reviewed pull requests, and build on the code instead of around it.
• You show the product without apologising for the screens you have not opened in a while.

What people worry about before hiring

• “I will pay and get nothing.” You can pay week by week, in advance, and the first month has an exit after two weeks: you pay for those two weeks only and keep everything made.
• “I will be locked in.” The code lives in your repository, on your accounts, with the rules files that let the next person or agent carry on without me.
• “AI code will be a mess nobody can maintain.” Every change is read before it goes in and follows your conventions. The design system and the rules stop the agent from inventing a new version of each component. On my own test app, that is how one button became 21.
• “It costs more than doing it myself.” Your hours have a price too, and rebuilding a product costs more than building it once. Next to a full-time engineer at about $16,700 a month, this starts from $8,000.
• “$8,000 a month is a lot before revenue.” Pay week by week, each week before it begins, and stop after two weeks in the first month if it is not working. For that you get one person doing what two salaries of over $31,000 a month would cover.
• “A junior or an offshore team would be cheaper.” Per hour, yes. A junior with Claude Code writes code as fast as anyone; the questions that make it a product come from years of watching people use one. An offshore team builds what the brief says, and the decisions the brief missed come back to you.
• “A designer cannot build the back end.” With Claude Code I build the front end, the back end and the deployment. Security certification and compliance audits go to specialists, and I tell you when you need one.
• “My users will hate the change.” In a product people already use, I change what gets in their way and keep what they rely on. Every change goes through your review, and you decide what ships and when.
• “It will not work for my product.” It works from an idea, a design or a codebase, in your stack. The usual cases: a B2B tool where admins invite their team and set who sees what; a marketplace where buyers and sellers see different screens; a SaaS where a trial user has to reach the first useful result before the trial ends; an internal dashboard that pulls from three systems. If your product needs something I do not do, I say so before you pay.
• “Who fixes it after launch?” While the month runs, I do, within the price already paid. After it, I can stay on part-time or take a quoted piece of work, or your team carries on with the code, the design system and the rules files in the repository.
• “What if I disagree with you?” It is your product. I say what I see, with the evidence, and you decide.

Payment and the way out

Payment is always in advance: the whole month at its start, or week by week, each week before it begins. A quoted project is paid by stage, each stage before it starts.

The first month has an exit. If by the end of the second week it is not working for you, say so. The work stops there and you pay for those two weeks only. Everything made up to that point stays in your repository.

Built with Claude Code

Claude Code developer: questions teams ask

Other ways I can help

• Design and build, from $8,000: a working first version, designed and built.
• Design engineering, from $8,000 a month: the front end, built by the designer.
• AI-built app cleanup, from $700: for Lovable, Bolt, Cursor and Claude Code apps.
• Fractional product design, from $8,000 a month: a senior designer, part-time.

Further reading: An AI UX audit agent for Claude Code. All services, with the situation each one fits: Services.