Frontend

I do not know CSS. I cannot center a div from memory. I have no idea what flexbox properties do without looking them up. And yet I have built complex user interfaces with sortable tables, analytics dashboards, multi-step forms, and responsive layouts. The secret is simple: I use shadcn/ui and Tailwind CSS, and I describe what I want to see instead of how to code it.

The stack that works for me is React with Next.js, styled with Tailwind CSS, using shadcn/ui components as building blocks. shadcn/ui gives you pre-built, professional-looking components — buttons, tables, modals, dropdowns, tabs, cards. Tailwind CSS lets you style things by adding class names directly in your code. You never write a separate CSS file. When I need a component, I describe it to Claude: "I need a data table that shows campaign name, status, send date, and open rate, with sortable columns and a search filter." Claude writes the whole thing using shadcn/ui Table, Input for search, and Tailwind for spacing and layout.

React basics — components, props, state — I learned entirely by building, not by reading documentation. A component is just a reusable piece of UI. Props are the data you pass into it. State is data that can change. That is genuinely all you need to understand to start. When Claude builds a component for you, read through it. After your third or fourth project, these concepts click naturally because you have seen them used in context dozens of times.

Next.js App Router makes page structure dead simple: pages are just files in folders. Want a page at /dashboard? Create a file at app/dashboard/page.tsx. Want a page at /campaigns/123? Create app/campaigns/[id]/page.tsx. Layouts that wrap multiple pages go in layout.tsx files. That is the entire routing system. No configuration, no router setup. Files equal pages.

Let me give you real scale so you understand what is possible. The SMTPCloud Dashboard has 149 TSX files. That is 149 React components and pages. It has a complex campaign management interface where you can create campaigns, select recipients, configure sending parameters, preview emails, and track results. It has analytics dashboards built with Recharts — line charts, bar charts, area charts showing open rates, click rates, deliverability over time. All of this was built by describing what I wanted to Claude.

Quality Monitoring is another example. It uses React 18 with Vite instead of Next.js, and it has a feature-based architecture. There are separate folders for dashboard, issues, team management, admin panel, returns tracking, and insights. Each feature has its own components, hooks, and utilities. The dashboard alone has multiple chart types, filterable tables, date range pickers, and role-based views that show different data depending on whether you are an admin, team lead, or agent.

The real skill in frontend development with AI is describing what you want to see, not how to code it. Instead of saying "create a React component with useState and useEffect that fetches data and maps over it to render table rows," I say: "I want a table that shows campaign stats — name, status, sent count, open rate. It should be sortable by clicking column headers. Add a search box at the top that filters by campaign name." Claude knows the implementation details. You know what the user needs to see.

For data fetching, I use TanStack Query (formerly React Query) in most of my projects. I never set it up by studying the docs. I told Claude: "I need to fetch the list of campaigns from my API at /api/campaigns. It should show a loading spinner while fetching, cache the data so it does not refetch every time I navigate back, and show an error message if the request fails." TanStack Query handles all of that — caching, background refetching, loading and error states. Claude sets it up and I get a smooth user experience without managing any of that complexity manually.

Responsive design — making your app look good on phones, tablets, and desktops — is handled by Tailwind utility classes. Classes prefixed with md: apply only on medium screens and up, lg: on large screens. So a grid that shows one column on mobile and three on desktop is just a matter of adding the right classes. Claude handles this automatically when I say "make it responsive" or "it should work well on mobile too." I have never manually written a media query in my life.

One thing I learned the hard way: do not try to design the perfect UI upfront. Build the ugly version first. Get the data showing, get the interactions working, make sure the page does what it needs to do. Then tell Claude: "This works but it looks rough. Clean up the layout, add proper spacing, make the table look professional." Polishing an existing working page is ten times easier than trying to build a perfect page from scratch.