I BUILD THINGS FOR THE WEB

The Problem I Was Solving

Fresh Movers needed a backend that could handle booking requests, user authentication, mover listings, and real-time availability checks — all with fast response times and clean API documentation that my React frontend could consume easily.

Why FastAPI Won

The first thing that caught my attention was automatic interactive API documentation. FastAPI generates Swagger UI out of the box at /docs — meaning every endpoint I wrote was instantly testable without leaving my browser. When you're building and iterating quickly, this is a genuine superpower.

The second reason was performance. FastAPI is built on Starlette and uses Python's async/await natively, making it one of the fastest Python web frameworks available — comparable to Node.js in benchmarks. For an application where multiple users might be checking mover availability simultaneously, async request handling matters.

Third: type hints. FastAPI uses Python's type annotation system with Pydantic models for request and response validation. This means if a request comes in with the wrong data type, FastAPI rejects it automatically before it ever touches my business logic. Coming from a background where I'd manually validate inputs, this felt like having a safety net on every endpoint.

What Django REST Would Have Given Me

DRF has a mature ecosystem, an admin panel out of the box, and battle-tested ORM integration. For a project with complex relational database requirements and a large team, DRF makes sense. But for a lean, performance-focused API being built solo with speed as a priority, it felt like putting on a suit to go jogging.

The Tradeoff I Accepted

FastAPI's ecosystem is newer. I hit moments where a Django package I'd heard about simply didn't have a FastAPI equivalent, and I had to build the solution myself. That was frustrating in the short term but genuinely educational.

What I'd Tell Other Developers

If you're building a new API from scratch, value performance and documentation, and are comfortable with Python type hints — start with FastAPI. If you're building something with complex admin requirements or joining a large team with existing Django expertise — go DRF. The best framework is the one that fits the specific problem in front of you.

The Original Idea

Meridian was supposed to be a straightforward productivity app — set goals, create tasks, track progress. Clean, simple, useful. The AI integration was almost an afterthought. Then I started thinking: what if the app didn't just track what you were doing, but actually understood why you were doing it?

Choosing Claude Over GPT

I evaluated both OpenAI's GPT-4 and Anthropic's Claude for the coaching interface. The decision came down to one thing: context handling. Meridian needed an AI that could hold the full context of a user's yearly goals, their daily task list, their completion rate, and their current blockers — and then give advice that felt genuinely personalised, not generic.

Claude handled longer context windows more gracefully in my testing, and the responses felt more thoughtful and less robotic. For a coaching interface where tone matters as much as accuracy, this was the deciding factor.

The Architecture Challenge

The hardest part wasn't calling the API — that's just a fetch request. The hard part was deciding what context to send. Sending everything on every request would be expensive and slow. Sending too little would make the AI's advice feel disconnected from reality.

I settled on a structured context object that included: the user's top 3 active goals with completion percentages, today's task list with statuses, the last 3 days of completion data, and any tasks the user had flagged as blocked. This gave Claude enough to be genuinely useful without bloating every request.

What Surprised Me

The AI responses were sometimes too good. Users in testing started treating Meridian's AI coach as a source of truth for life decisions. I had to add a subtle disclaimer and think carefully about the prompts I was sending — because the framing of your system prompt shapes the entire personality and boundaries of the AI's responses. Prompt engineering is a real skill and it took me several iterations to get it right.

The Performance Problem

AI API calls are slow compared to a database query. On first load, waiting 2–3 seconds for the coaching panel to populate felt jarring. I solved this with a skeleton loading state and by pre-fetching the AI response in the background when the user logs in, so by the time they navigate to the coaching tab, the response is already there.

What I'd Do Differently

I'd design the AI integration from day one rather than bolting it on. The data model I built for goals and tasks was retrofitted to feed the AI context object, which led to some awkward data transformations. Building with the AI in mind from the start would have produced cleaner architecture.

The Lesson

AI doesn't make your product smart. It makes your product feel human. The intelligence comes from how you structure the problem, what context you provide, and how carefully you craft the experience around the AI's output. The API call is 5% of the work.

How I Got Here

My first React project used plain CSS modules. Organised, but slow. My second used Bootstrap — fast to start, painful to customise. My third used styled-components — powerful, but the context switching between JavaScript logic and style definitions started to feel like mental overhead. Then I tried Tailwind on the Moringa Tech Hub project and something clicked.

What Tailwind Actually Is

Tailwind is not a component library. It doesn't give you pre-built buttons or navbars. It gives you utility classes — small, single-purpose CSS building blocks that you compose directly in your HTML. Instead of writing a CSS class called .card with ten properties, you write those ten properties inline as class names. It sounds messy. In practice, on a React project, it's the opposite.

Why It Works With React Specifically

React already encourages you to think in components. When your styling lives in the same file as your component logic, you stop jumping between files to understand what something looks like. The entire mental model of a Button component — its layout, colour, hover state, responsive behaviour — lives in one place. That's genuinely faster to read, write, and debug.

The Parts That Frustrated Me First

The class names are verbose. A fully styled card in Tailwind looks like a wall of text in the className attribute. I solved this with the clsx library for conditional classes and by extracting repeated patterns into reusable React components rather than Tailwind @apply directives.

The second frustration was purging. In production, Tailwind removes any CSS class you didn't use — which is great for performance but caused me one memorable bug where dynamically generated class names were being purged because Tailwind's scanner couldn't detect them. The fix is to always write complete class names, never construct them with string concatenation.

The Performance Win

Tailwind's production CSS bundle is tiny — typically under 10kb for a full application because unused styles are stripped out. Compare this to Bootstrap's 30kb+ minified CSS included whether you use it or not. For Lighthouse scores and Core Web Vitals, this matters.

When I'd Choose Something Else

If I were building a large design system with dozens of developers and strict brand consistency requirements, I'd reach for a component library like Shadcn/UI built on top of Tailwind — which gives you the utility system plus pre-built accessible components. For solo projects and small teams, vanilla React plus Tailwind remains my fastest path from idea to deployed product.

The Bottom Line

React gives you composable UI logic. Tailwind gives you composable styling. Together they reduce the number of files, the number of decisions, and the amount of context switching required to build a good-looking, performant frontend. In 2026, with the tooling maturity both ecosystems have reached, this combination is genuinely hard to beat for a full stack JavaScript developer.