Most people use Claude the same way.

They open a new conversation, type a prompt, get an answer, make a few corrections, and repeat the entire process the next day.

There’s nothing wrong with that.

But after spending time experimenting with AI-assisted development and productivity workflows, I’ve realized something: the biggest advantage doesn’t come from writing better prompts. It comes from changing how you work with the tool.

Claude has several capabilities that can make a surprisingly big difference when you use them properly.

Some help you avoid repeating instructions. Others let you delegate complicated tasks, reuse entire workflows, or make Claude check its own work.

The interesting part?

Many users still treat Claude like a chatbot when they could be using it as a much more capable working environment.

Here are five tricks worth learning.

1. Stop Rewriting Instructions — Create Your Own Claude Skills

One of the most frustrating things about working with AI is repetition.

Imagine you’re a Python developer.

Every time you ask Claude to write code, you explain that you prefer:

• Type hints.
• PEP 8 formatting.
• Clear function names.
• Modular architecture.
• Proper exception handling.
• Unit tests for important functions.

You might spend more time explaining your preferences than actually reviewing the code.

That’s where Claude Skills become interesting.

A Skill is essentially a reusable set of instructions, resources, and sometimes scripts that teaches Claude how to perform a particular task.

Instead of explaining your workflow in every conversation, you define it once and reuse it.

For example, you could create a Python code-review Skill that instructs Claude to:

1. Inspect the code before suggesting changes.
2. Identify performance bottlenecks.
3. Look for unnecessary database queries.
4. Check error handling and edge cases.
5. Suggest improvements without unnecessarily rewriting the entire application.
6. Include tests for important changes.

Now imagine using the same workflow across multiple projects.

You don’t need to paste six paragraphs of instructions every time.

Here’s a prompt to get started:

“Create a reusable Claude Skill for reviewing production-level Python code. It should check code quality, performance, security, maintainability, error handling, and testing. Include clear instructions and examples. Keep the review practical and prioritize problems by severity.”

The interesting thing about Skills is that Claude can discover relevant skills and load their detailed instructions when needed, rather than requiring you to paste everything into every conversation.

That’s a much better way to handle repetitive work.

When I would use it: Code reviews, documentation generation, research workflows, report writing, and any task where consistency matters.

2. Give Claude a Project Memory Instead of Starting From Zero

Here’s a situation most developers have experienced.

You’re working on a project for several days.

Claude understands your architecture, database structure, naming conventions, and business logic.

Then you start another conversation.

Suddenly, you’re explaining everything again.

It’s like onboarding a new developer every morning.

Claude Projects can help solve this problem.

Projects let you organize related conversations, files, and project-specific instructions in one place.

For example, suppose you’re building a FastAPI application.

You could create a Project containing:

• Your project architecture.
• Database schema.
• API documentation.
• Coding conventions.
• Important configuration details.
• Existing implementation decisions.

You can also add project instructions explaining how Claude should approach development.

For example:

“You’re helping me develop a production-ready FastAPI application. Before suggesting architectural changes, inspect the existing project structure and understand how its components interact.

Use Pydantic for validation, SQLAlchemy for database operations, and follow modular architecture. Avoid unnecessary dependencies and explain potentially breaking changes before recommending them.”

Now your project has a consistent starting point.

You can ask Claude to implement an endpoint, investigate a database issue, or review a particular module without repeatedly explaining the entire application.

One important distinction: project knowledge and conversation history aren’t identical. Put important reusable information into project instructions or uploaded knowledge rather than assuming Claude will remember every decision automatically.

When I would use it: Long-running software projects, research, business documentation, and any workflow involving multiple related conversations.

3. Ask Claude to Plan Before Writing Code

This is one of the simplest changes I’ve made to my AI-assisted development workflow.

Previously, I would give Claude a task and expect it to start coding immediately.

Sometimes it worked beautifully.

Other times, it modified the wrong files, misunderstood the architecture, or implemented something that technically worked but created problems elsewhere.

The issue wasn’t necessarily the model.

It was the workflow.

For complicated development tasks, I now prefer separating planning from implementation.

Instead of asking:

“Build an authentication system for my FastAPI application.”

I use a different approach.

Step 1: Ask Claude to investigate.

“Inspect my existing FastAPI project. Identify the current authentication mechanism, database models, API structure, and relevant dependencies. Don’t modify any files yet.”

Step 2: Ask for an implementation plan.

“Based on the existing architecture, create a step-by-step implementation plan for JWT authentication. Include the files that need modification, required dependencies, security considerations, and potential edge cases.”

Step 3: Review the plan.

This is where you catch architectural mistakes before they become code.

Step 4: Ask Claude to implement the approved plan.

“Implement the approved authentication plan. Follow the existing coding conventions and avoid unrelated changes.”

This approach is particularly useful with Claude Code.

It allows you to investigate a codebase, understand the proposed changes, and then move into implementation with a much clearer direction.

There’s another advantage.

You can use subagents for independent investigation tasks in Claude Code, allowing different pieces of a complicated problem to be explored separately.

For example:

• One agent investigates database architecture.
• Another reviews authentication security.
• Another examines existing API endpoints.

You can then combine their findings before implementing anything.

The goal isn’t to make Claude write more code.

It’s to make sure it writes the right code.

4. Make Claude Check Its Own Work

Here’s something I wish more people understood about AI-assisted programming.

Getting code from an AI model is relatively easy.

Knowing whether that code actually works is a different problem.

A function might look perfectly reasonable and still fail when it encounters unexpected input.

An API endpoint might return the correct response in one scenario but break when multiple requests arrive simultaneously.

And a database query might work with ten records but become painfully slow with a million.

That’s why verification is so important.

Instead of asking Claude to implement something and stopping there, give it a way to test its own output.

For example, after implementing a Python function, use this prompt:

“Review the implementation and verify its behavior. Create unit tests covering normal inputs, empty values, invalid inputs, boundary conditions, and unexpected exceptions. Run the tests, inspect any failures, fix the underlying problems, and run the tests again.

Do not claim the implementation works unless the tests actually pass.”

This changes the workflow considerably.

Instead of receiving code and manually discovering every problem, Claude gets an opportunity to investigate failures and improve its implementation.

For Claude Code, you can take this further by asking it to:

• Run the project’s existing test suite.
• Check formatting and linting.
• Inspect the Git diff.
• Identify unintended changes.
• Review performance-sensitive sections.
• Run relevant integration tests.

One particularly useful practice is to make verification part of the task itself.

Don’t treat testing as something you’ll remember to do later.

Make it a required final step.

As Anthropic’s Claude Code team emphasizes in its power-user guidance, verification is one of the most impactful ways to improve the reliability of AI-generated work.

Pro Tip: Never confuse code that Claude has written with code that Claude has verified. Those are two very different things.

5. Turn Repeated Work Into Automated Workflows

This is where things become particularly interesting.

Most people use AI to complete individual tasks.

Experienced developers eventually start thinking about entire workflows.

Consider a simple example.

Every morning, you need to:

1. Check GitHub issues.
2. Review recent commits.
3. Identify unfinished tasks.
4. Summarize development progress.
5. Prepare a standup report.

You could ask Claude to perform each task separately.

But why repeat the same instructions every morning?

With Claude Code, you can create reusable Skills for recurring workflows.

For example, you could create a /standup Skill that tells Claude to inspect recent Git commits and relevant project information, then generate a structured daily report.

A simplified Skill structure looks like this:

.claude/
└── skills/
    └── standup/
        └── SKILL.md

Inside SKILL.md, you might write:

---
name: standup
description: Generate a daily development standup report.
---
# Daily Standup Report
Review recent Git activity and summarize:
1. Work completed.
2. Important commits.
3. Current blockers.
4. Outstanding tasks.
5. Suggested priorities for today.
Keep the report concise and use bullet points.
Do not invent completed work or assume that
an unfinished task has been resolved.Now you have a reusable workflow rather than another prompt sitting somewhere in your chat history.

You can extend this idea considerably.

For example:

• A /code-review workflow for reviewing changes.
• A /documentation workflow for updating project documentation.
• A /security-check workflow for identifying potential vulnerabilities.
• A /techdebt workflow for finding duplicated code and maintainability issues.

You can also explore Claude Code hooks when you need deterministic automation around specific events, such as running a formatter after certain operations.

The distinction is important: a Skill tells Claude how to perform a workflow, while a hook can automatically execute a predefined action when its configured event occurs.

That’s how you move from repeatedly asking AI for help to building a development environment that handles recurring work more consistently.

And honestly, that’s where the real productivity gains begin.

One More Thing: Stop Treating Every AI Feature as Necessary

There’s something I’ve noticed while experimenting with AI tools.

Whenever a new feature appears, developers immediately try to incorporate it into everything.

New agent? Add an agent.

New workflow framework? Rewrite the application.

New automation feature? Find something to automate.

But more features don’t automatically mean better results.

Sometimes a carefully written instruction is enough.

Sometimes a simple Python script is more reliable than an AI agent.

And sometimes the best solution is not using AI at all.

The trick is knowing which tool solves the actual problem.

As the old engineering principle goes:

“Simplicity is the ultimate sophistication.” — Often attributed to Leonardo da Vinci

I think that principle applies to AI development more than ever.

Final Thoughts

Claude is much more useful when you stop treating every conversation as an isolated interaction.

Reusable Skills reduce repetitive instructions.

Projects provide consistent context.

Planning improves implementation.

Verification makes AI-generated work more dependable.

And automated workflows help you stop repeating the same tasks.

None of these techniques requires you to become an AI researcher.

They simply require you to rethink how you use the tools already available.

My biggest takeaway is this:

Don’t focus on getting Claude to answer faster. Focus on building a workflow that makes you ask for the same thing fewer times.

That’s a much more valuable advantage than knowing a hundred clever prompts.

And it’s something you can start applying to your next project today.

What Claude workflow has saved you the most time? I’d love to hear about it in the comments.

5 Claude Tricks That Give You an Unfair Advantage (Most People Still Use the Old Way) was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

For a long time, my AI coding workflow looked something like this:

Open ChatGPT.

Explain what I want to build.

Copy the generated code.

Paste it into my editor.

Run it.

Find an error.

Go back to ChatGPT.

Explain the error.

Copy the fixed code.

Repeat.

Sound familiar?

At first, this felt revolutionary. I could write Python scripts faster, explore unfamiliar libraries, and build features without spending hours searching through documentation.

But after using AI coding assistants for several projects, I noticed something.

I was spending almost as much time explaining my code to AI as I was actually developing it.

Sometimes even more.

The problem wasn’t that AI couldn’t write good code. The problem was how I was using it.

I was treating a powerful development assistant like a search engine that happened to understand Python.

Eventually, I changed my workflow.

Instead of writing endless prompts and asking AI to generate individual pieces of code, I started giving it access to the problem, the project structure, the requirements, and the expected behavior.

The difference was surprisingly significant.

Here’s what I do differently now.

1. I Stop Writing Prompts and Start Defining the Problem

One mistake I see developers make is immediately asking AI to generate code.

For example:

“Write a Python script that reads a CSV file, removes duplicates, and saves the result.”

There’s nothing particularly wrong with this prompt.

But it gives AI almost no information about the actual problem.

What happens if the CSV contains missing values?

Which columns determine whether a record is duplicated?

Should the original file be overwritten?

What happens when the file doesn’t exist?

A few missing details can turn a seemingly simple script into a collection of unexpected bugs.

Instead, I describe the problem before asking for an implementation.

For example:

Project: CSV Data Cleaning Tool

Objective: Build a reusable Python utility that cleans customer datasets.

Requirements:

• Accept CSV files as input.
• Remove duplicate records based on email addresses.
• Handle missing values without silently deleting important information.
• Validate required columns.
• Save the cleaned dataset to a separate output file.
• Log how many records were removed or modified.

Constraints:

• Use Pandas.
• Keep the implementation modular.
• Handle invalid input gracefully.
• Include basic unit tests.

Notice the difference?

The second approach gives AI something much more valuable than instructions.

It gives it context.

When AI understands what you’re trying to accomplish, it can make better implementation decisions instead of guessing what you meant.

I’ve learned that five minutes spent defining a problem can save considerably more time debugging an incomplete solution.

2. I Give AI the Project Context Before Asking It to Change Anything

This is probably one of the biggest improvements I’ve made.

Imagine joining an unfamiliar software project.

Would you immediately start changing files without understanding its architecture?

Probably not.

Yet developers often do exactly that with AI coding assistants.

They ask an AI tool to implement a feature without explaining:

• How the project is organized.
• Which frameworks are being used.
• Where business logic belongs.
• How the database is structured.
• Which coding conventions the project follows.
• How existing components communicate.

Then they wonder why the generated code doesn’t fit the application.

My approach is different.

Before asking AI to implement anything substantial, I ask it to inspect the existing codebase.

For example:

“Analyze this project and explain its architecture. Identify the main modules, important dependencies, entry points, database interactions, and existing coding conventions. Don’t modify any files yet.”

I want the AI to understand the project before touching it.

For larger projects, I also maintain a small AGENTS.md or equivalent project instruction file containing:

• Project overview.
• Technology stack.
• Directory structure.
• Development commands.
• Testing requirements.
• Important architectural decisions.
• Coding conventions.

This prevents me from explaining the same things repeatedly.

It also makes the AI’s suggestions more consistent across different tasks.

One useful principle: Don’t make AI rediscover information that your project can explain once.

3. I Ask AI to Create a Plan Before Writing Code

I used to think asking AI for a plan was unnecessary.

Why spend time discussing implementation when the model can generate code immediately?

That assumption didn’t age well.

On larger tasks, jumping directly into implementation often produces code that looks convincing but doesn’t fit the overall architecture.

For example, imagine building an AI-powered document processing application.

The project might require:

1. PDF extraction.
2. Text cleaning.
3. Document chunking.
4. Embedding generation.
5. Vector storage.
6. Semantic retrieval.
7. LLM-based question answering.

Asking AI to implement everything in one go is an invitation to unnecessary complexity.

Instead, I ask:

“Analyze the requirements and propose an implementation plan. Break the project into small tasks, identify the files that need modification, mention potential edge cases, and explain how each component will be tested. Don’t write code yet.”

This gives me an opportunity to review the architecture before implementation begins.

I can identify unnecessary dependencies, question questionable design decisions, and correct misunderstandings early.

It’s much cheaper to fix a bad plan than to rewrite 500 lines of generated code.

And here’s something worth remembering:

AI should help you think through the implementation, not make every architectural decision on your behalf.

4. I Let AI Work on Small, Independent Tasks

One of the most useful changes I’ve made is reducing the size of individual coding tasks.

I no longer ask:

“Build the entire backend for my application.”

Instead, I break the implementation into manageable pieces.

For example:

Task 1: Create the document upload endpoint.

Task 2: Implement PDF text extraction.

Task 3: Add document validation.

Task 4: Implement text chunking.

Task 5: Integrate the embedding model.

Task 6: Write tests for the retrieval functionality.

Each task has a clear responsibility and an expected result.

Why does this matter?

Because smaller tasks are easier to review, test, and debug.

If the PDF extraction module fails, I don’t need to investigate the entire backend.

I can focus on one component.

This also makes AI-generated changes easier to understand.

A useful coding assistant should make your development process more manageable, not turn your repository into a mystery.

5. I Make AI Write Tests, Not Just Implementation Code

This is where things get interesting.

Most developers use AI to generate functions.

Fewer consistently ask it to generate meaningful tests for those functions.

I’ve found that the second habit is just as important as the first.

Consider a simple Python function:

def calculate_discount(price, discount):
    return price - (price * discount / 100)

It works.

But what happens when:

• The price is negative?
• The discount is greater than 100?
• The input is a string?
• The discount is zero?
• The price is a floating-point value?

The happy path tells us very little about how reliable a function actually is.

Now I ask AI to generate tests alongside the implementation.

For example:

import pytest
def test_calculate_discount():
    assert calculate_discount(100, 10) == 90
    assert calculate_discount(200, 25) == 150
    assert calculate_discount(100, 0) == 100For production-oriented code, I’d also ask it to consider invalid inputs and define the expected behavior explicitly.

Using pytest, I can automate these checks and quickly identify regressions when the implementation changes.

My preferred workflow is simple:

1. Ask AI to implement the feature.
2. Ask it to identify important edge cases.
3. Generate tests for those cases.
4. Run the tests.
5. Review failures before accepting the changes.

One important distinction: generated tests aren’t automatically correct. They can repeat the same misunderstanding as the implementation.

That’s why I review the expected behavior rather than blindly trusting a passing test suite.

Pro Tip: Ask AI, “What are the five most likely ways this implementation could fail in production?” before considering a feature complete.

You might be surprised by what it catches.

6. I Use AI to Review Code Before I Review It Myself

Another habit that has saved me considerable time is asking AI to review its own implementation.

Not because AI is always better at finding bugs than an experienced developer.

It isn’t.

But it can provide another perspective, especially when I’m working with unfamiliar code.

After implementing a feature, I ask it to inspect the changes for:

• Incorrect assumptions.
• Unnecessary complexity.
• Missing error handling.
• Security vulnerabilities.
• Performance bottlenecks.
• Duplicate logic.
• Potential race conditions.
• Missing tests.

For example:

“Review the changes you just made as a senior Python engineer. Focus on correctness, maintainability, security, and edge cases. Don’t rewrite working code unnecessarily. Report issues with their severity and explain why each one matters.”

This is more useful than simply asking:

“Is this code good?”

The latter encourages generic feedback.

The former gives the review a purpose.

I also pay particular attention to database queries, API authentication, file handling, and user input validation.

These are areas where a small implementation mistake can create a surprisingly large problem.

Of course, AI reviews aren’t a substitute for code review, security testing, or human judgment.

Think of them as another layer of inspection.

7. I Stop Copying Code Between Different Tools

There was a time when my development workflow involved constantly switching between my browser, terminal, ChatGPT, and code editor.

I’d ask ChatGPT for a function, copy it into VS Code, run it, copy the error, and paste it back into the conversation.

It worked.

But it wasn’t particularly efficient.

Modern AI coding tools can work much closer to the actual development environment.

Depending on the tool, they can:

• Inspect project files.
• Search through existing functions.
• Edit multiple related files.
• Run terminal commands.
• Execute tests.
• Explain errors.
• Review changes.

This changes the way I approach development.

Instead of asking AI to generate isolated code snippets, I can give it a task within the project itself.

For example:

“Implement pagination for the existing FastAPI endpoint. Follow the current project conventions, preserve backward compatibility, add input validation, and write tests. Run the relevant test suite and report any failures. Don’t modify unrelated files.”

The important part isn’t that AI can edit multiple files.

It’s that it can work with the actual project context and verify its changes.

Tools such as Cursor and Claude Code make this style of development possible, although their exact capabilities and workflows differ.

The less time I spend moving code between applications, the more time I can spend understanding what I’m building.

8. I Make AI Explain Important Decisions

There’s one thing I deliberately avoid.

Accepting code simply because it works.

A function can produce the correct output and still be poorly designed.

It might introduce unnecessary dependencies, duplicate existing functionality, or create performance problems that won’t appear until the application grows.

Whenever AI makes an important architectural decision, I ask it to explain why.

For example:

“Explain why you chose this approach instead of using a background task. What are the trade-offs, and under what circumstances would this implementation become inefficient?”

This is particularly useful when working with:

• Asynchronous Python.
• Database connection management.
• Background task processing.
• Caching strategies
• API architecture.
• LLM orchestration.
• Vector database retrieval.

You don’t need to understand every generated line immediately.

But you should understand the important decisions that shape your application.

Otherwise, you’re not really developing software.

You’re supervising code generation.

And those are two very different things.

The Workflow I Actually Follow Now

After experimenting with different approaches, I’ve settled on a relatively simple process.

It looks like this:

Step 1: Define the problem.

Describe what needs to be built, who will use it, and what success looks like.

Step 2: Provide project context.

Let AI inspect the existing codebase, dependencies, architecture, and conventions.

Step 3: Generate an implementation plan.

Break the work into small, independent tasks.

Step 4: Implement one task at a time.

Let AI modify the relevant files instead of generating disconnected snippets.

Step 5: Generate and run tests.

Verify functionality, edge cases, and expected behavior.

Step 6: Review the changes.

Inspect the diff, question architectural decisions, and check for unnecessary modifications.

Step 7: Document important decisions.

Update project instructions or documentation when the architecture or development process changes.

The entire process is less about writing better prompts and more about creating a better development environment for AI.

That’s the distinction I wish I’d understood earlier.

Final Thoughts

AI hasn’t made software engineering effortless.

It has changed where the effort goes.

A few years ago, I spent more time writing boilerplate, searching documentation, and figuring out implementation details.

Today, AI can help with much of that work.

But the responsibility for understanding the problem, making architectural decisions, and verifying the result still belongs to the developer.

That’s why I no longer measure my AI coding workflow by how many prompts I can write or how quickly I can generate code.

I measure it by something much simpler:

How much reliable software can I build without creating unnecessary complexity?

The biggest improvement in my development process didn’t come from learning a better prompt.

It came from changing the way I work with AI.

Stop treating AI like a machine that writes code on command. Start treating it like a development assistant that understands your project, follows your plan, and helps verify the result.

You’ll spend less time prompting.

Less time debugging avoidable mistakes.

And considerably more time building things that actually work.

Because ultimately, the goal isn’t to make AI write more code.

It’s to make yourself a better developer.

Prompting AI to Code Is Holding You Back. Here’s What I Do Instead. was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

For a long time, I thought I had a pretty good understanding of AI.

💥 Master AI & Tech Skills
🔥 Up to 50% OFF — Limited-Time Offer
👉 Enroll Now & Start Learning

I knew how large language models worked at a high level. I had experimented with different prompts, explored popular Python libraries, tested APIs, and built a few small scripts.

I could explain what RAG was, why embeddings mattered, and how AI agents were supposed to work.

Then I started building actual AI applications.

And things got interesting.

A prompt that worked perfectly in a notebook suddenly produced inconsistent results in production. An API call that took two seconds during testing occasionally took fifteen. A model that seemed intelligent when answering simple questions struggled with a document containing messy formatting.

I quickly realized something:

Understanding how AI works and knowing how to build reliable AI software are two very different skills.

The gap between them is where most of the interesting engineering happens.

Here are seven lessons I learned after moving beyond AI tutorials and starting to build applications that solve real problems.

1. Prompt Engineering Is Easy Until You Need Consistency

One of the first things I learned was that getting an LLM to produce a good answer is relatively easy.

Getting it to produce a consistently good answer is another story.

Consider a simple project: extracting information from invoices.

You provide an invoice and ask an LLM to return:

• Invoice number
• Customer name
• Invoice date
• Total amount
• Tax amount

During initial testing, everything looks great.

Then you try another invoice.

The model returns the date in a different format. One field is missing. The total amount includes a currency symbol when your application expects a number.

Your Python code breaks.

This is where I started appreciating structured outputs and validation.

Instead of treating an LLM response as trustworthy data, I began treating it as an untrusted input that needed validation.

Libraries such as Pydantic make this much easier.

For example:

from pydantic import BaseModel
from datetime import date
class Invoice(BaseModel):
    invoice_number: str
    customer_name: str
    invoice_date: date
    total_amount: float
    tax_amount: float
invoice_data = {
    "invoice_number": "INV-1024",
    "customer_name": "John Smith",
    "invoice_date": "2026-10-15",
    "total_amount": 1250.50,
    "tax_amount": 150.00
}
invoice = Invoice(**invoice_data)
print(invoice.total_amount)Now, instead of blindly accepting whatever the model returns, I have a clear contract for the data my application expects.

For actual LLM integrations, you can combine Pydantic with provider-supported structured output features and still validate the result before using it.

The important lesson?

A good AI application doesn’t just generate intelligent responses. It makes those responses usable by ordinary software.

2. The Model Is Not Always the Problem

When an AI application produces an incorrect answer, our first instinct is usually to blame the model.

I used to do the same.

If a chatbot couldn’t answer a question about a PDF, I would experiment with different prompts, adjust temperatures, or switch models.

Sometimes that helped.

Often, it didn’t.

The problem was somewhere else.

Imagine building a document question-answering application using Retrieval-Augmented Generation (RAG).

The workflow looks something like this:

1. Extract text from documents.
2. Divide the text into smaller chunks.
3. Generate embeddings.
4. Retrieve relevant chunks.
5. Pass those chunks to an LLM.
6. Generate an answer.

Now imagine the user asks:

“What was the company’s revenue in 2024?”

But your retrieval system returns a paragraph about the company’s 2023 revenue.

The LLM may generate a perfectly convincing answer.

It will still be wrong.

Changing GPT to Claude won’t magically fix poor retrieval.

This taught me to debug AI applications as complete pipelines rather than isolated model calls.

I now pay attention to:

• Whether the source documents were extracted correctly.
• Whether chunk boundaries preserve useful context.
• Whether the embedding model captures the meaning of the query.
• Whether retrieval returns relevant information.
• Whether the final answer is supported by the retrieved content.

A useful tool here is sentence-transformers.

from sentence_transformers import SentenceTransformer
from sklearn.metrics.pairwise import cosine_similarity
model = SentenceTransformer("all-MiniLM-L6-v2")
documents = [
    "The company generated $2 million in revenue during 2024.",
    "The company hired 150 new employees in 2023.",
    "The organization expanded into three new markets."
]
query = "What was the company's revenue in 2024?"
embeddings = model.encode(documents)
query_embedding = model.encode([query])
scores = cosine_similarity(
    query_embedding,
    embeddings
)[0]
best_match = scores.argmax()
print(documents[best_match])This is a simple demonstration of semantic retrieval, not a complete production RAG system. Real applications also need thoughtful chunking, metadata filtering, evaluation, and often reranking.

But it illustrates an important point.

Sometimes the best way to improve an AI application isn’t to use a smarter model.

It’s to give the model better information.

3. AI APIs Introduce Problems That Ordinary Python Scripts Don’t

Writing a Python script that calls an AI API is straightforward.

Building one that handles thousands of requests reliably requires a different mindset.

I learned this when experimenting with workflows that involved processing multiple documents.

Initially, I simply looped through the files and sent requests to an LLM.

Something like this:

for document in documents:
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {
                "role": "user",
                "content": f"Summarize this: {document}"
            }
        ]
    )

It works.

Until you have hundreds or thousands of documents.

Then you start encountering:

• Rate limits.
• Network timeouts.
• Temporary provider errors.
• Unexpected API costs.
• Failed requests.
• Long execution times.

A script that works perfectly with five documents might become unreliable with five thousand.

This is why I started paying more attention to retry mechanisms, batching, concurrency, and background processing.

For example, exponential backoff is a useful technique for handling temporary failures.

import time
import random
def retry_request(func, retries=5):
    for attempt in range(retries):
        try:
            return func()
        except Exception:
            if attempt == retries - 1:
                raise
            delay = (2 ** attempt) + random.random()
            time.sleep(delay)

This is a simplified example. In production, retries should be limited to retryable errors, respect provider rate-limit instructions, and avoid blindly repeating non-idempotent operations.

The bigger lesson is that AI applications need the same reliability engineering as any other backend system.

An impressive model cannot compensate for an unreliable application around it.

4. Data Preparation Matters More Than I Expected

When people discuss AI development, they usually talk about models, agents, frameworks, and vector databases.

Data preparation doesn’t get nearly as much attention.

But it should.

I discovered this while experimenting with document-processing applications.

A PDF might contain:

• Tables with inconsistent formatting.
• Scanned pages.
• Repeated headers and footers.
• Broken text extraction.
• Unusual Unicode characters.
• Important information inside images.

Simply extracting text doesn’t mean you’ve extracted useful information.

For example, a PDF table might visually look like this:

ProductQuantityPriceKeyboard10500Mouse15200

But after text extraction, the content might become a poorly structured sequence of words and numbers.

The model then has to guess which value belongs to which column.

That’s unnecessary work.

For PDF processing, I frequently find PyMuPDF useful.

For tabular data, Pandas remains one of the most practical tools in my Python toolbox.

import fitz
pdf = fitz.open("report.pdf")
for page_number, page in enumerate(pdf):
    text = page.get_text("text")
    print(f"Page {page_number + 1}")
    print(text)This gives you a starting point for extracting document content.

For more complicated documents, you may need table extraction, OCR, layout detection, or image processing.

The interesting part is that improving preprocessing can sometimes produce better results than changing the underlying LLM.

Garbage in, garbage out isn’t an outdated programming principle. AI just makes it more expensive.

5. Not Every AI Problem Needs an AI Agent

This was one of the most useful lessons I learned.

Whenever a new AI concept becomes popular, developers naturally want to use it everywhere.

Agents are a good example.

An AI agent can use tools, make decisions, perform multiple steps, and coordinate actions to accomplish a goal.

That’s powerful.

But does every application need one?

Consider a simple email classification system.

You receive an email and want to categorize it as:

• Sales
• Support
• Billing
• General inquiry

You could build an agent that reasons about the email, selects tools, decides what to do next, and manages a workflow.

Or you could send the email to an LLM with a structured classification prompt.

Which approach would I choose?

The second one.

It is simpler, cheaper to maintain, and easier to test.

Agents become more useful when a task genuinely requires multiple decisions, tool interactions, or adaptive execution.

For more complicated workflows, frameworks such as LangGraph can help manage state, branching, retries, and human approval steps.

But I wouldn’t introduce that complexity without a reason.

A useful rule I’ve adopted:

Don’t introduce an agent when a function can solve the problem.

Sometimes the most advanced engineering decision is choosing not to use advanced technology.

6. Evaluating AI Applications Is Harder Than Testing Normal Python Code

Traditional Python testing is relatively straightforward.

You provide an input, execute a function, and compare the output with an expected result.

For example:

def add(a, b):
    return a + b
assert add(5, 10) == 15AI applications are different.

The same prompt can produce slightly different answers. Two responses can communicate the same information using completely different words.

So, how do you test them?

You need to evaluate more than whether the output matches an exact string.

For an AI-powered document assistant, I would start with a small evaluation dataset containing:

• Questions with known answers.
• Relevant source documents.
• Expected supporting passages.
• Questions that cannot be answered from the documents.

Then evaluate different parts of the system.

Retrieval evaluation: Did the application retrieve the correct information?

Answer evaluation: Did the generated response accurately answer the question?

Grounding evaluation: Was the answer supported by the retrieved sources?

Reliability evaluation: Does the system behave consistently across repeated tests?

Tools such as Ragas and DeepEval can help evaluate RAG and LLM applications.

I also recommend keeping a collection of real failure cases.

Whenever the application produces an incorrect answer, save the input, retrieved context, and output.

That collection gradually becomes one of your most valuable testing resources.

Because fixing a bug once is good.

Making sure it doesn’t return six months later is better.

7. The Best AI Applications Are Usually Boring Behind the Scenes

This might sound strange, but the more AI applications I explored, the less impressed I became by complicated demonstrations.

A chatbot that can answer questions about anything looks exciting.

An application that automatically processes 2,000 invoices, validates the extracted information, flags suspicious entries, and sends a report to the accounting team is much more interesting to me.

Why?

Because the second application solves a specific problem.

It has a clear purpose.

It saves time.

And someone can actually use it.

When I approach a new AI project today, I usually think about the entire workflow:

• FastAPI for exposing functionality through an API.
• Pydantic for validating structured data.
• Pandas for handling datasets.
• PyMuPDF for extracting PDF content.
• Sentence Transformers for generating embeddings.
• Celery for background processing.
• PostgreSQL for persistent storage.
• An LLM API for tasks that genuinely require language understanding.

Not every project needs all these libraries.

The point is to choose tools according to the problem rather than forcing every new technology into the architecture.

A successful AI application doesn’t have to look complicated.

It has to work reliably.

What Changed the Way I Think About AI Development?

Looking back, the biggest change wasn’t learning another framework or discovering a new model.

It was changing the questions I asked.

Earlier, I would ask:

“Which model should I use?”

Now I ask:

“What exactly am I trying to automate?”

Earlier, I would ask:

“How can I make this prompt better?”

Now I also ask:

“Is the model receiving the right information in the first place?”

Earlier, I was impressed when an AI demo worked once.

Now I want to know what happens after 1,000 requests.

That shift has made me approach AI development much more like software engineering.

And honestly, that’s what building useful AI applications requires.

Final Thoughts

I still enjoy exploring new AI models, libraries, and frameworks.

There’s always something interesting happening in the ecosystem.

But I’ve stopped measuring my AI knowledge by how many tools I know or how many tutorials I’ve completed.

I measure it by what I can actually build.

Can I turn an unstructured document collection into a searchable knowledge base?

Can I automate a repetitive business process without creating a maintenance nightmare?

Can I build an application that handles unexpected inputs, API failures, and imperfect data?

Those are much more interesting questions.

If you’re learning AI, my advice is simple.

Don’t spend all your time reading about what AI can do.

Pick a problem you’ve personally experienced and build something that solves it.

Start small. Make mistakes. Debug the unexpected behavior. Improve the workflow.

You’ll probably learn more from one imperfect project than from ten perfectly polished tutorials.

Because there’s a big difference between knowing how AI works and knowing how to make it work.

And that difference only becomes clear when you start building.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

Disclosure: This post includes affiliate and partnership links.

I Thought I Understood AI Until I Started Building With It was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years ago, I had a habit that I thought made me a good developer.

💥 Master AI & Tech Skills in 3 Months!
💰 One Subscription. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

Whenever a new JavaScript framework appeared, I wanted to try it.

A new CSS library? Installed.

A new build tool? Tested.

A new frontend framework promising better performance and developer experience? I was already reading its documentation.

My browser was full of documentation tabs, GitHub repositories, tutorials, and blog posts about the next big thing in web development.

I thought staying updated meant becoming a better programmer.

I was wrong.

The more technologies I learned, the more I realized that I wasn’t necessarily becoming better at building software. I was becoming better at learning new tools.

There’s a difference.

Eventually, I started asking myself a different question:

What if I spent less time learning every new technology and more time understanding the technologies I already used?

That small change completely transformed my approach to web development.

Here are seven lessons I learned after stepping away from the endless cycle of web development trends.

1. I Stopped Switching Frameworks Just Because Something New Appeared

For a long time, I treated frameworks like smartphones.

Every new release made me wonder whether I was missing something.

React was popular, then Vue caught my attention. Next.js introduced interesting features, and other frameworks started promising faster rendering and better developer experiences.

I kept experimenting.

There was nothing inherently wrong with that. Exploring different frameworks helped me understand how modern frontend development worked.

The problem was that I rarely stayed with one technology long enough to understand its deeper concepts.

I knew how to create components, but I wasn’t always thinking carefully about component boundaries.

I knew how to fetch data, but I didn’t fully understand caching strategies, request waterfalls, or server-side rendering trade-offs.

I could configure a project, but maintaining it over time was a different story.

So I changed my approach.

Instead of switching frameworks whenever something new appeared, I started evaluating technologies based on actual project requirements.

For example:

• Does the project need server-side rendering?
• Is client-side interactivity essential?
• How complicated will the routing become?
• Does the team already understand the framework?
• Will the technology remain maintainable as the application grows?

These questions became more valuable than GitHub stars or social media discussions.

The best framework isn’t necessarily the newest one. It’s the one that solves your problem without introducing unnecessary complexity.

2. I Started Understanding JavaScript Instead of Memorizing Framework APIs

This was probably one of the biggest improvements in my development journey.

Frameworks make many things easier.

However, they can also hide the underlying concepts.

For example, you can use React for years without properly understanding:

• JavaScript closures
• The event loop
• Promises and asynchronous execution
• Prototypes and inheritance
• The difference between shallow and deep copying
• How references work in JavaScript
• Memory management

But eventually, these concepts become important.

I remember spending time debugging unexpected behavior in a React component. The problem wasn’t really React. It was related to how JavaScript closures captured variables.

Understanding closures made the problem much easier to solve.

The same thing happens with asynchronous JavaScript.

If you understand how the event loop works, debugging unexpected execution order becomes significantly easier.

For example:

console.log("Start");
setTimeout(() => {
    console.log("Timeout");
}, 0);
Promise.resolve().then(() => {
    console.log("Promise");
});
console.log("End");The output is:

Start
End
Promise
Timeout

Why?

Because synchronous code executes first, promise callbacks are processed through the microtask queue, and timer callbacks are processed through the task queue.

Understanding this behavior is much more valuable than memorizing another framework method.

Frameworks change.

JavaScript fundamentals remain useful across almost every frontend project.

3. I Stopped Collecting CSS Frameworks and Learned CSS Properly

I’ll admit something.

There was a time when I thought learning another CSS framework would solve most of my styling problems.

Bootstrap made layouts easier.

Tailwind CSS made utility-based styling convenient.

Component libraries helped me build interfaces faster.

But I eventually noticed something.

Whenever a design became slightly complicated, I still needed to understand CSS.

Responsive layouts, unexpected overflow, alignment issues, stacking contexts, and complex positioning didn’t magically disappear because I was using a framework.

So I went back to the fundamentals.

I spent more time understanding:

• Flexbox
• CSS Grid
• Positioning and stacking contexts
• Responsive design
• Container queries
• CSS custom properties
• Specificity and inheritance

One particularly useful concept was CSS Grid.

Before understanding it properly, I often used nested flex containers to build layouts that were essentially two-dimensional.

Grid made those layouts considerably easier to reason about.

For example:

.dashboard {
    display: grid;
    grid-template-columns: 250px 1fr;
    grid-template-rows: 70px 1fr;
    min-height: 100vh;
}
.sidebar {
    grid-row: 1 / 3;
}
.header {
    grid-column: 2;
}
.main-content {
    grid-column: 2;
}This creates a simple dashboard structure without introducing unnecessary layout wrappers.

I still use CSS frameworks when they make sense.

But I no longer expect them to replace an understanding of CSS.

A framework should accelerate your work, not become a substitute for knowing what you’re doing.

4. I Became More Interested in Performance Than Popularity

Something interesting happens when you stop chasing trends.

You start noticing problems that aren’t particularly exciting but matter enormously in real applications.

Performance is one of them.

A website can look beautiful, use the latest framework, and still provide a terrible user experience.

Slow loading, excessive JavaScript, layout shifts, and unnecessary network requests can make even a well-designed application frustrating.

I started paying more attention to performance measurements.

Instead of guessing whether a website was fast, I used tools such as:

• Lighthouse
• Chrome DevTools
• WebPageTest
• Chrome Performance Panel
• PageSpeed Insights

I also became more familiar with Core Web Vitals.

Three particularly important metrics are:

Largest Contentful Paint (LCP): Measures how quickly the largest visible content element loads.

Interaction to Next Paint (INP): Measures how responsive a page feels when users interact with it.

Cumulative Layout Shift (CLS): Measures unexpected visual movement during page loading.

These metrics helped me think beyond whether my code worked.

I started asking whether the application felt good to use.

Sometimes the biggest performance improvement wasn’t switching frameworks.

It was compressing images, removing unnecessary JavaScript, reducing third-party scripts, or fixing an inefficient API request.

That’s not particularly glamorous.

But users don’t care how fashionable your tech stack is.

They care about how quickly your website works.

5. I Started Writing Code That Other Developers Could Understand

When you’re learning web development, it’s easy to focus on making something work.

If the button responds, the API returns data, and the page renders correctly, the task feels complete.

But professional software requires more than that.

Code needs to be understandable, testable, and maintainable.

I gradually became more conscious of things like:

• Meaningful variable and function names
• Smaller, focused components
• Reusable logic
• Proper error handling
• Consistent project structure
• Type safety with TypeScript
• Automated testing

TypeScript, in particular, changed how I approached larger applications.

Consider this example:

type User = {
    id: number;
    name: string;
    email: string;
    isActive: boolean;
};
function getUserDetails(user: User): string {
    return `${user.name} - ${user.email}`;
}Without explicit types, it’s easier for incorrect data structures to travel through an application unnoticed.

TypeScript helps catch many of these mistakes during development rather than waiting for them to appear at runtime.

Of course, TypeScript doesn’t eliminate every possible bug.

But it makes assumptions more visible.

And that’s valuable.

I also learned that reusable code isn’t automatically good code.

Sometimes developers create complicated abstractions to avoid repeating just two or three lines.

I’ve done that myself.

Now I prefer straightforward code over clever abstractions that require an explanation every time someone opens the file.

6. I Stopped Ignoring Backend Development

For a while, I approached web development primarily from the frontend.

My main concerns were components, layouts, interactions, and making interfaces look right.

But real applications don’t exist only in the browser.

They communicate with APIs, interact with databases, authenticate users, process information, and handle failures.

Understanding the backend made me a considerably more capable frontend developer.

I started paying more attention to:

• REST API design
• HTTP methods and status codes
• Authentication and authorization
• Database relationships
• API pagination
• Caching
• Input validation
• Error handling

One thing I particularly recommend understanding is the difference between authentication and authorization.

Authentication answers:

Who are you?

Authorization answers:

What are you allowed to do?

They sound similar, but confusing them can introduce serious security problems.

For example, hiding an administrative button in the frontend doesn’t prevent an unauthorized user from calling the underlying API directly.

Permissions must also be enforced on the server.

This is the kind of detail that separates building an interface from building a reliable application.

You don’t necessarily need to become a backend specialist.

But understanding what happens behind your frontend makes your architectural decisions much better.

7. I Started Building Complete Projects Instead of Collecting Tutorials

This was the final change that brought everything together.

I used to save tutorials constantly.

A new React course, a Next.js project, a CSS animation tutorial, or an interesting GitHub repository.

My learning list kept growing.

Unfortunately, my completed projects didn’t grow at the same speed.

So I started following a different rule.

Whenever I learned something new, I tried to use it in a real project.

Not another tutorial project that disappeared after two days.

Something that solved an actual problem.

For example, instead of simply learning how authentication works, I built an application with:

• User registration and login
• Password hashing
• Protected routes
• Role-based permissions
• Form validation
• Error handling
• Database integration

Instead of watching another performance optimization tutorial, I took an existing application and measured its performance before and after making improvements.

This approach taught me things tutorials rarely cover.

What happens when an API fails?

What if a user submits the same form twice?

What if the database returns incomplete information?

What if a component receives unexpected data?

These problems force you to think like an engineer rather than someone following instructions.

And that’s where real development experience comes from.

A Simple Rule I Now Follow When Learning New Technologies

I haven’t stopped exploring new tools.

I still enjoy experimenting with frameworks, libraries, and development workflows.

The difference is that I no longer treat every new release as something I must learn immediately.

Before adopting a technology, I ask myself:

1. What problem does it solve?
2. Is that problem actually present in my project?
3. Does it offer a meaningful improvement over my current approach?
4. How difficult will it be to maintain?
5. Will learning it improve my understanding of software development?

If I can’t answer these questions, I usually don’t rush into adopting it.

A useful rule I learned along the way:

“The more you know, the more you realize what you don’t need to know.”

You don’t have to master every framework, library, or development tool to become an excellent developer.

You need to understand the fundamentals, recognize problems, and know how to choose the right solution.

Final Thoughts

Web development moves incredibly fast.

A framework that everyone discusses today might receive considerably less attention next year.

A new library might become popular overnight.

And another tool will probably promise to revolutionize the way we build websites.

That’s fine.

Technology should evolve.

But your learning strategy shouldn’t depend entirely on what’s trending.

I became a better developer when I stopped trying to learn everything and started focusing on understanding things deeply.

I spent more time debugging, reading documentation, improving existing projects, understanding browser behavior, and writing code that other developers could actually maintain.

Ironically, I learned more when I started following fewer trends.

My advice?

Don’t spend every weekend rebuilding your tech stack because someone on the internet discovered a new framework.

Pick a problem.

Build something useful.

Understand why it works.

And when something breaks, resist the temptation to immediately install another library.

Sometimes the best upgrade to your development workflow isn’t a new technology.

It’s becoming better at using the technologies you already have.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

Disclosure: This post includes affiliate and partnership links.

I Stopped Following Every Web Development Trend — and Became a Better Developer was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

read here.

I still remember deploying a Python application that had worked flawlessly on my local machine.

💥 Master AI & Tech Skills in 3 Months!
💰 One Subscription. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

Every endpoint responded correctly.

The database queries were fast.

The frontend loaded without errors.

Even my automated tests were passing.

I pushed the code, deployed the application, and waited for everything to come online.

Then the errors started.

The API couldn’t connect to the database. Some environment variables were missing. A few requests returned unexpected errors, and a feature that worked perfectly on my laptop suddenly stopped working.

Nothing had changed in the business logic.

At least, that’s what I thought.

After spending hours debugging the application, I realized something important:

Writing code that works locally and building software that works reliably in production are two very different skills.

Over the years, I’ve learned that many deployment failures aren’t caused by complicated bugs. They’re caused by small differences between environments that developers don’t think about until something breaks.

Here are eight problems I’ve encountered, the Python tools that helped me solve them, and the engineering habits I now use to avoid repeating the same mistakes.

1. Environment Variables — The Configuration That Disappeared

One of the first things I check when an application works locally but fails in production is its environment variables.

During development, it’s easy to get comfortable with a .env file.

You store your database URL, API keys, secret keys, and application settings there, and everything works.

Then you deploy.

Suddenly, the application complains that a configuration value doesn’t exist.

Why?

Because your local .env file doesn't automatically travel with your application.

Production environments need their own configuration.

I now use pydantic-settings to manage application settings more reliably.

It allows me to define configuration using Python types and validate values when the application starts.

For example:

from pydantic_settings import BaseSettings, SettingsConfigDict

class Settings(BaseSettings):
    database_url: str
    secret_key: str
    debug: bool = False
    model_config = SettingsConfigDict(
        env_file=".env",
        env_file_encoding="utf-8",
        extra="ignore"
    )

settings = Settings()Now, instead of accessing environment variables throughout the application, I have one centralized configuration object.

print(settings.database_url)

The advantage isn’t just cleaner code.

If a required setting is missing, the application can fail immediately with a meaningful validation error rather than crashing somewhere deep inside an API request.

A small improvement, but one that can save hours of debugging.

Libraries: pydantic-settings, python-dotenv

Lesson: Never assume production has the same configuration as your development machine.

2. Dependency Conflicts — The Package That Worked Yesterday

Here’s another situation that took me a while to appreciate.

You install a Python package, write your code, test everything, and move on.

A few weeks later, you deploy the application on another machine.

Suddenly, something breaks.

The code hasn’t changed.

The package has.

Or perhaps another dependency installed a different version of a library that your application relies on.

Python’s package ecosystem is incredibly useful, but dependency management can become surprisingly complicated.

For example, imagine your application depends on:

• FastAPI
• Pydantic
• SQLAlchemy
• OpenAI
• Pandas

Each package may have its own dependencies and version requirements.

Updating one library can introduce incompatibilities elsewhere.

This is why I never rely on whatever happens to be installed on my development machine.

I prefer explicitly managing dependencies and locking versions.

For smaller projects, a pinned requirements file can be enough:

fastapi==0.120.0
pydantic==2.12.0
sqlalchemy==2.0.44
pandas==2.3.3

These are illustrative version pins; use versions compatible with your project.

For larger applications, I also like using tools such as uv to manage dependencies and generate a lockfile.

The important distinction is that a requirements file with version ranges and a lockfile don’t necessarily provide the same reproducibility guarantees.

A lockfile captures a resolved dependency set, making it easier to recreate the same environment.

Pro Tip: If an application works on your laptop but fails in CI, compare the installed dependency versions before rewriting the application code.

Sometimes the bug isn’t in your code.

It’s in the environment running it.

Libraries and tools: uv, pip, pip-tools

3. Database Connections — Why Local Databases Lie

Local database configurations are often much more forgiving than production configurations.

During development, I might run PostgreSQL inside Docker or use a database installed directly on my machine.

The application connects successfully, queries return quickly, and everything looks fine.

Then production introduces a different reality.

The database might be hosted on another server, require SSL, enforce connection limits, or sit behind a network firewall.

Suddenly, database connection errors start appearing.

One issue I pay particular attention to is connection pooling.

Imagine an API receiving hundreds of requests.

If every request creates a completely new database connection, the application can quickly overwhelm the database.

SQLAlchemy provides connection pooling to reuse database connections more efficiently.

Here’s a basic example:

from sqlalchemy import create_engine
DATABASE_URL = "postgresql+psycopg://user:password@localhost/app"
engine = create_engine(
    DATABASE_URL,
    pool_size=10,
    max_overflow=20,
    pool_pre_ping=True
)A few details matter here.

• pool_size controls the number of persistent connections in the pool.
• max_overflow allows additional temporary connections when demand increases.
• pool_pre_ping checks whether a connection is still alive before using it.

That last option is particularly useful when database connections might have been closed by an external server.

However, there’s something developers often overlook.

If you run five application workers, each with its own connection pool, your potential database connections multiply.

A pool size of 10 doesn’t necessarily mean your entire application uses only 10 connections.

It could mean 50 across five workers, before accounting for overflow.

That’s why connection pool settings should be designed around the database’s actual connection limits.

Libraries: SQLAlchemy, psycopg

4. File Paths — The Folder That Suddenly Doesn’t Exist

This one looks almost too simple to cause production problems.

But it does.

Imagine writing a Python script that generates PDF reports.

Locally, you save them inside:

output_path = "reports/report.pdf"

The directory exists on your machine.

Everything works.

After deployment, the application throws:

FileNotFoundError

Why?

Because the working directory might be different, the folder might not exist, or the deployment environment might have a different filesystem structure.

I learned to stop treating relative paths as predictable.

Python’s pathlib makes file handling much cleaner:

from pathlib import Path
BASE_DIR = Path(__file__).resolve().parent
OUTPUT_DIR = BASE_DIR / "reports"
OUTPUT_DIR.mkdir(
    parents=True,
    exist_ok=True
)
output_path = OUTPUT_DIR / "report.pdf"

Now the application builds paths relative to the Python file rather than depending entirely on whichever directory happens to be active.

But there’s another production consideration.

Some hosting platforms use ephemeral filesystems.

That means files saved locally inside the application container might disappear when the application restarts or gets redeployed.

For user uploads, generated reports, and important application files, I prefer external object storage such as Amazon S3 or another compatible storage service.

Lesson: A file existing on your laptop doesn’t mean it exists in production.

5. CORS — The API Works, but the Browser Disagrees

I used to find CORS errors particularly frustrating.

The backend was running.

The API endpoint responded correctly when tested through Postman.

But the frontend refused to access the response.

At first, I suspected the API itself.

It wasn’t.

The problem was Cross-Origin Resource Sharing (CORS).

Browsers enforce security restrictions when a frontend application tries to communicate with an API hosted on a different origin.

For example:

Frontend: https://mywebsite.com
Backend:  https://api.mywebsite.com

These are different origins.

Even though both belong to the same domain family, the browser treats them as separate origins.

FastAPI makes CORS configuration straightforward:

from fastapi import FastAPI
from fastapi.middleware.cors import CORSMiddleware
app = FastAPI()
app.add_middleware(
    CORSMiddleware,
    allow_origins=[
        "https://mywebsite.com"
    ],
    allow_credentials=True,
    allow_methods=["GET", "POST", "PUT", "DELETE"],
    allow_headers=["Authorization", "Content-Type"],
)

One important detail: avoid using allow_origins=["*"] in production when credentials are involved.

Explicitly allow the origins your frontend actually uses.

Also, CORS isn’t an authentication mechanism.

It controls browser access to cross-origin responses. Your API still needs proper authentication and authorization.

Libraries: FastAPI

6. Logging — Stop Debugging Production With Print Statements

There’s a difference between debugging an application locally and debugging one running on a production server.

Locally, I can open the terminal, reproduce an error, and inspect what’s happening.

In production, things aren’t always that convenient.

A user reports that a request failed.

The application logs show a generic server error.

And now I’m trying to figure out what happened without being able to reproduce it.

This is where structured logging becomes incredibly valuable.

Python already includes a logging module, so there’s no reason to depend entirely on print() statements.

Here’s a simple setup:

import logging
logging.basicConfig(
    level=logging.INFO,
    format="%(asctime)s %(levelname)s %(name)s %(message)s"
)
logger = logging.getLogger(__name__)

def process_payment(payment_id):
    logger.info(
        "Processing payment: %s",
        payment_id
    )
    try:
        # Payment processing logic
        pass
    except Exception:
        logger.exception(
            "Payment processing failed"
        )
        raiseNotice the use of logger.exception().

When called inside an exception handler, it records the exception traceback automatically.

For larger applications, I also consider structured logging with libraries such as structlog.

This makes it easier to attach useful context to log events:

• Request IDs
• User IDs
• Processing times
• Task IDs
• Error details

One particularly useful practice is assigning a unique request ID to each incoming API request.

When something goes wrong, you can trace the request through multiple services instead of searching thousands of unrelated log entries.

Pro Tip: Never log passwords, API keys, authentication tokens, or sensitive personal information. Production logs should help you debug problems without becoming a security problem themselves.

Libraries: logging, structlog

7. Docker — Finally, a Consistent Environment

At some point, I got tired of hearing:

“But it works on my machine.”

It became one of those sentences that usually meant another debugging session was coming.

The problem was environmental inconsistency.

My laptop had one Python version.

The production server had another.

One machine had system dependencies installed.

The other didn’t.

Docker helped eliminate many of these differences.

Instead of manually configuring every machine, I could package the application and its runtime environment into a container.

Here’s a basic Dockerfile for a FastAPI application:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]Now the application can run inside a container with a predictable Python runtime and installed dependencies.

But Docker isn’t magic.

A container doesn’t automatically guarantee identical production behavior.

You still need to manage environment variables, persistent storage, networking, secrets, and external services correctly.

For production, I also recommend:

• Running as a non-root user.
• Using a .dockerignore file.
• Pinning your base image appropriately.
• Keeping secrets outside the image.
• Adding health checks where appropriate.
• Using multi-stage builds when they meaningfully reduce image size.

One more thing: don’t copy your entire development environment into the production image.

A smaller, carefully constructed image is generally easier to maintain and deploy.

Tools: Docker, Docker Compose

8. Production Testing — Passing Tests Doesn’t Mean You’re Ready

This might be the most important lesson of all.

For a long time, I treated successful local tests as a strong indication that deployment would go smoothly.

But tests only verify the behavior you’ve actually tested.

They don’t automatically check whether:

• Your production database is reachable.
• Your environment variables are configured.
• Your external API credentials are valid.
• Your application can handle concurrent requests.
• Your deployment has the correct permissions.
• Your server can recover from unexpected failures.

That’s why I’ve started treating production readiness as a separate engineering responsibility.

For Python applications, I commonly combine pytest with tools such as httpx for API testing.

For example:

from fastapi.testclient import TestClient
from main import app
client = TestClient(app)

def test_health_endpoint():
    response = client.get("/health")
    assert response.status_code == 200
    assert response.json()["status"] == "ok"This is a simple example, but the idea is important.

I like having a health endpoint that verifies whether the application is running.

For more serious systems, I distinguish between:

Liveness checks: Is the application process alive?

Readiness checks: Is the application prepared to receive traffic?

An application might be alive but unable to connect to its database.

Treating those conditions as identical can cause unnecessary problems during deployments.

I also use CI pipelines to run tests before code reaches production.

A deployment should be the final step of a verification process, not the first time the application gets tested in an environment resembling reality.

Libraries and tools: pytest, httpx, GitHub Actions

The Deployment Checklist I Now Use

After dealing with enough production failures, I stopped relying on memory to decide whether an application was ready.

I started using a simple checklist.

Before deploying a Python application, I check:

• Environment variables are configured correctly.
• Dependencies are pinned and reproducible.
• Database connectivity and connection limits are verified.
• Required directories and file permissions exist.
• CORS allows only the required frontend origins.
• Logging captures useful diagnostic information.
• Secrets are not included in source code or Docker images.
• Automated tests pass in CI.
• Health and readiness checks work.
• Important files use persistent storage.
• A rollback strategy exists.

It doesn’t eliminate every production issue.

But it catches many of the mistakes that used to consume my afternoons.

What I Finally Learned About Production

The biggest mistake I made early in my development journey was thinking that deployment was simply another step after writing code.

It isn’t.

Production introduces a completely different set of responsibilities.

Your application now has to deal with real users, unpredictable traffic, external services, network failures, security requirements, and infrastructure that you don’t completely control.

A Python script that works perfectly on your laptop is only the beginning.

The real engineering challenge is making it reliable when the environment stops being predictable.

And that’s where tools such as Pydantic, SQLAlchemy, Docker, FastAPI, and pytest become much more than convenient libraries.

They help turn working code into dependable software.

One thing I’ve learned after years of building Python applications is this:

Good developers write code that works. Better engineers build systems that keep working when things go wrong.

And honestly, that’s the difference I wish I’d understood much earlier.

Now, whenever I finish a feature, I don’t just ask whether it works locally.

I ask a much more important question:

What could break when someone else runs this code?

That question has probably saved me more debugging time than any new Python library ever has.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

Disclosure: This post includes affiliate and partnership links.

My Website Worked Perfectly Locally — Then Everything Broke in Production was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I first started building web applications, performance wasn’t something I worried about very much.

💥 Master AI & Tech Skills in 3 Months!
💰 One Subscription. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

My pages loaded quickly.

My API returned responses almost instantly.

My database queries worked perfectly.

Everything looked fine.

Then the projects grew.

The database accumulated more records. More users started hitting the same endpoints. Background tasks began competing with requests. Suddenly, operations that once took milliseconds started taking seconds.

The frustrating part?

Most of my code hadn’t changed. The amount of work it had to handle had.

That experience changed how I think about performance.

I used to assume that slow applications were caused by complicated algorithms or poorly written Python. Sometimes they are. But in real web applications, the biggest bottlenecks often hide in places that look completely harmless.

Here are the performance problems I learned to pay attention to after my applications started getting bigger.

1. My Database Queries Were Doing Far More Work Than I Realized

This was one of the first problems that changed how I approached backend development.

Imagine building an API that returns a list of blog posts.

A simple implementation might look something like this:

@app.get("/posts")
def get_posts():
    posts = db.query(Post).all()
return [
        {
            "title": post.title,
            "author": post.author.name
        }
        for post in posts
    ]It looks reasonable.

Fetch the posts, retrieve each author’s name, and return the results.

But there’s a potential problem hiding in that loop.

If the ORM lazily loads each author’s information, accessing post.author.name can trigger another database query for every post.

This is known as the N+1 query problem.

Instead of making one query to fetch posts, the application might execute one query for the posts and another query for each post’s author.

For 10 posts, that’s potentially 11 queries.

For 1,000 posts, it could become 1,001.

And that’s before considering other relationships or additional queries elsewhere in the request.

The application doesn’t necessarily become slow when you’re testing it with a handful of records. The problem becomes much more obvious as the dataset grows.

What I do differently now

I pay attention to the number of queries an endpoint executes, not just the amount of Python code it contains.

With SQLAlchemy, eager loading can help:

from sqlalchemy import select
from sqlalchemy.orm import selectinload
stmt = (
    select(Post)
    .options(selectinload(Post.author))
)
posts = db.scalars(stmt).all()Here, selectinload() fetches related authors in a separate query for the collection of posts rather than issuing a query for each author.

The exact loading strategy depends on the relationships and query patterns, but the principle is the same: fetch the data you need without making the database do unnecessary work.

I also inspect generated SQL, check query plans, and look for missing indexes when queries become expensive.

One important detail: adding indexes to every column isn’t the answer either. Indexes consume storage and add overhead to writes. They should support actual query patterns.

The lesson: Before optimizing Python code, find out how much work your database is doing on its behalf.

Sometimes the slowest part of a Python application isn’t Python at all.

2. My API Was Returning More Data Than Anyone Needed

Early in development, returning an entire dataset feels convenient.

You query the database, serialize the results, and send everything to the client.

What’s the problem?

Suppose your application has 50,000 products. A frontend requests the product list, and the API returns every product with its description, metadata, category, and other related fields.

Even if the database query is reasonably fast, the application still has to:

• Retrieve the records.
• Convert them into Python objects.
• Serialize the response into JSON.
• Transfer the response over the network.
• Parse the JSON in the browser.

Every step consumes resources.

And if multiple users make the same request simultaneously, the wasted work multiplies.

I learned that a query can be fast while the endpoint itself is painfully slow.

Pagination makes a real difference

Instead of returning every record, return a limited number at a time.

from fastapi import FastAPI, Query
from sqlalchemy import select
app = FastAPI()
@app.get("/products")
def get_products(
    limit: int = Query(default=50, ge=1, le=100),
    offset: int = Query(default=0, ge=0),
):
    stmt = (
        select(Product)
        .order_by(Product.id)
        .limit(limit)
        .offset(offset)
    )
    return db.scalars(stmt).all()Now the client can request a manageable page of results instead of downloading the entire table.

For larger datasets, cursor-based pagination can be more efficient than large offsets, especially when the query is supported by an appropriate index.

I also try to return only the fields the client actually needs. A product listing usually doesn’t need the full product description, internal metadata, and every associated record.

There’s no reason to send 20 fields when five will do.

The lesson: Performance isn’t only about how quickly your server calculates an answer. It’s also about how much unnecessary work you ask it to do.

3. I Thought Async Python Would Automatically Make Everything Faster

When I started exploring asynchronous Python, the appeal was obvious.

FastAPI supports asynchronous endpoints. Python has asyncio. Network requests can overlap instead of waiting for each other.

It sounds like a straightforward performance upgrade.

But there’s a catch.

async doesn't magically make blocking code asynchronous.

Consider this example:

import time
from fastapi import FastAPI
app = FastAPI()
@app.get("/report")
async def generate_report():
    time.sleep(3)
    return {"status": "complete"}The endpoint is declared with async def, but time.sleep(3) blocks the event loop.

While that blocking operation is running, other asynchronous requests sharing that event loop may be unable to make progress.

The function is asynchronous in syntax, not in behavior.

For a simple demonstration, replacing the sleep with await asyncio.sleep(3) allows other coroutines to run during the wait. In a real application, the same principle applies to network clients, database drivers, and other I/O operations.

import asyncio
@app.get("/report")
async def generate_report():
    await asyncio.sleep(3)
    return {"status": "complete"}

Of course, real report generation shouldn’t be replaced with a sleep. The example simply illustrates the difference between blocking and non-blocking waits.

When working with external APIs, I use asynchronous clients when the surrounding application benefits from concurrency. For CPU-heavy work, I consider a process pool or a dedicated worker instead.

There’s another detail worth remembering: asynchronous code can improve throughput, but it doesn’t automatically reduce the time required for an individual operation.

An API request that takes two seconds to complete may still take two seconds after you make it asynchronous.

The gain comes from handling other work while waiting.

The lesson: Choose concurrency based on the bottleneck you’re solving. Don’t add async everywhere and expect a performance miracle.

4. My Application Kept Repeating Work It Had Already Done

One of the easiest ways to waste computing resources is to repeatedly calculate or retrieve information that rarely changes.

Imagine an API that returns a dashboard containing:

• Total registered users.
• Monthly revenue.
• Number of active subscriptions.
• Recent activity.
• Popular products.

Every time someone opens the dashboard, the backend runs the same aggregation queries.

If the dashboard receives frequent requests and the underlying data changes infrequently, much of that work may be unnecessary.

This is where caching becomes useful.

A simple Redis example

Redis can store frequently requested results so that the application doesn’t need to recalculate them on every request.

import json
from redis import Redis
redis_client = Redis(
    host="localhost",
    port=6379,
    decode_responses=True,
)
def get_dashboard():
    cached = redis_client.get("dashboard:v1")
    if cached is not None:
        return json.loads(cached)
    dashboard = calculate_dashboard()
    redis_client.setex(
        "dashboard:v1",
        60,
        json.dumps(dashboard),
    )
    return dashboardThis example caches the dashboard for 60 seconds.

If another request arrives during that period, the application can return the cached result instead of repeating the aggregation.

But caching introduces its own engineering problems.

What happens when the data changes? What if two requests attempt to rebuild an expensive cache simultaneously? What if the cached result contains user-specific information?

A time-to-live helps limit how long old results remain available, but it doesn’t guarantee that every response is fresh. More demanding applications may need explicit invalidation, versioned cache keys, or protections against cache stampedes.

And I wouldn’t cache every endpoint just because Redis is available.

For frequently requested, expensive-to-compute data, caching can be valuable. For inexpensive queries against frequently changing data, it may add complexity without providing much benefit.

The lesson: The fastest computation is often the one your application doesn’t need to repeat.

5. My Background Tasks Were Making My API Feel Slow

At some point, an application stops doing only simple database operations.

It might generate PDF reports, process uploaded documents, extract text from hundreds of files, call several AI APIs, or generate embeddings for a collection of documents.

These tasks can take seconds or minutes.

The first implementation is often straightforward:

@app.post("/process-document")
async def process_document():
    result = process_large_document()
    return {"result": result}

There’s nothing inherently wrong with a synchronous workflow for a small task. The problem appears when expensive processing keeps the request open or blocks the execution environment.

Users end up waiting for work that doesn’t necessarily need to happen before the API responds.

For CPU-heavy operations, declaring the endpoint async doesn't solve the problem either.

Move expensive work out of the request

A more scalable design separates accepting a job from executing it.

The API receives the request, creates a job record, and sends the work to a background worker. The client receives a job ID and can check its status later.

Tools such as Celery can help manage distributed background tasks, retries, and queues.

A simplified workflow looks like this:

@app.post("/process-document")
def submit_document():
    job = create_job_record()
process_document_task.delay(job.id)
    return {
        "job_id": job.id,
        "status": "queued",
    }The worker performs the expensive processing separately.

The client can then poll a status endpoint or receive updates through another mechanism.

This approach makes the API more responsive, but it doesn’t make the underlying job disappear. You still need to consider queue length, worker capacity, retry behavior, duplicate execution, and failed jobs.

For example, if 10,000 documents arrive but your workers can process only 100 per minute, the queue will grow. Monitoring queue age and throughput becomes just as important as monitoring API latency.

I also avoid sending large files directly through a queue when storing them in object storage and passing a reference would be more appropriate.

The lesson: Your API should coordinate work, not necessarily perform every expensive operation before responding.

6. I Was Guessing Where My Code Was Slow

This was probably the most important change in my approach to optimization.

It’s surprisingly easy to spend an afternoon optimizing a function that has almost no effect on overall performance.

A loop looks suspicious, so you rewrite it.

A list comprehension seems inefficient, so you replace it.

You shave a few milliseconds off a calculation.

Meanwhile, a database query takes 800 milliseconds on every request.

I’ve learned to stop guessing.

Before optimizing, I try to answer three questions:

1. Where is the time actually being spent?
2. How often does that operation run?
3. Does it materially affect the user experience or system capacity?

Start with the right tools

Python includes a useful profiler:

python -m cProfile -s cumulative app_script.py

This helps identify functions consuming significant cumulative execution time in a script. For web applications, you may need to profile representative requests or workloads rather than simply running the application itself.

For more detailed analysis, tools such as py-spy can help inspect a running Python process with relatively low overhead.

I also measure individual requests.

For an API, I look at:

• Median response time.
• p95 and p99 latency.
• Request throughput.
• Error rates and timeouts.
• Database query duration.
• CPU and memory utilization.

Why p95?

Because an average can hide a terrible experience for a subset of users.

If most requests take 100 milliseconds but a small number take five seconds, the average might not reveal how frustrating the slow requests are.

The 95th-percentile latency tells you the response time below which 95% of measured requests completed.

I also test under realistic load. A website that responds quickly to one request may behave very differently when hundreds of requests arrive together.

Pro Tip: Never trust an optimization because the code looks faster. Measure the same workload before and after the change.

The goal isn’t to produce clever code. It’s to improve a measurable outcome.

7. My Memory Usage Became a Problem Before I Expected

Not every performance problem appears as a slow response.

Sometimes the application works perfectly until memory consumption grows, garbage collection becomes more frequent, or the process gets killed by the operating system.

A common example is loading an entire file into memory when the application only needs to process it incrementally.

Consider a CSV file:

import pandas as pd
df = pd.read_csv("large_dataset.csv")

For a dataset that comfortably fits in memory, this is perfectly reasonable.

But as the file grows, the DataFrame may consume substantially more memory than the original CSV because data must be represented as in-memory objects and arrays.

If the application processes several files simultaneously, memory usage can grow quickly.

For suitable workloads, Pandas supports chunked reading:

import pandas as pd
for chunk in pd.read_csv(
    "large_dataset.csv",
    chunksize=10_000,
):
    process_chunk(chunk)Instead of loading the entire dataset at once, the application processes smaller portions.

This works particularly well when each chunk can be handled independently or when intermediate results can be accumulated efficiently.

Of course, chunking isn’t always the answer. Operations that require comparing every record with every other record may need a different strategy. Sometimes a database, a streaming approach, or a more appropriate data-processing engine is a better fit.

I also pay attention to unnecessary copies of large DataFrames, unbounded in-memory caches, and lists that keep growing because old entries are never discarded.

The lesson: Design data processing around the amount of information you can afford to keep in memory, not just the size of the input file.

8. I Learned That Faster Code Doesn’t Always Mean a Faster Website

Here’s something that took me a while to appreciate.

An application can have efficient Python functions and still deliver a poor user experience.

Why?

Because overall response time depends on everything involved in serving the request.

A simplified request might spend its time like this:

OperationTimeDatabase query120 msExternal API call700 msPython processing30 msResponse serialization20 msTotal870 ms

These numbers are illustrative, not benchmark results.

In this example, optimizing the Python processing from 30 milliseconds to 10 milliseconds saves only 20 milliseconds. That’s a modest improvement to a request that takes 870 milliseconds.

Reducing the external API call’s latency, running independent requests concurrently, or caching an appropriate result could have a much greater impact.

This is why I like breaking request latency into separate stages.

Without that breakdown, it’s easy to optimize the most interesting part of the system instead of the most expensive one.

I also distinguish between latency and throughput.

Latency tells me how long an operation takes. Throughput tells me how much work the system completes in a given period.

An optimization that reduces individual request latency may not improve throughput if the database remains the limiting factor. Likewise, a system may handle more concurrent requests without making every request individually faster.

Both measurements matter, depending on the problem.

The lesson: Optimize the entire request path, not just the Python function you’re currently looking at.

The Small Habit That Changed How I Build Web Applications

I used to think about performance after a feature was finished.

First, I’d make it work.

Then I’d add more functionality.

If it eventually became slow, I’d investigate.

That approach wasn’t always disastrous, but it made some problems harder to diagnose because I hadn’t measured how the system behaved before it grew.

Now I try to build a few simple habits into my development process.

• Measure early. Establish a baseline before making major performance changes.
• Watch database queries. Pay attention to query count, execution time, indexes, and query plans.
• Limit unnecessary work. Use pagination, select only required fields, and avoid repeated calculations.
• Choose the right execution model. Use asynchronous I/O for suitable I/O-bound work and separate workers for expensive tasks.
• Test realistic workloads. Include larger datasets, concurrent requests, and slow external dependencies.
• Recheck every optimization. A change that helps one workload may hurt another.

I don’t try to make every function as fast as possible.

That would be a great way to spend weeks solving problems nobody has.

Instead, I focus on the parts of the application that affect users, consume significant resources, or limit how much work the system can handle.

Final Thoughts

The biggest performance problems I encountered weren’t always the most complicated ones.

They were the ones I didn’t notice.

A database query that ran a little too often. An API returning too much data. A blocking function inside an asynchronous endpoint. A background task that should never have been part of the request. A large dataset that no longer fit comfortably in memory.

Each problem looked manageable when the application was small.

Growth simply made the cost impossible to ignore.

That’s the part of backend development I find most interesting: scaling an application isn’t always about introducing more sophisticated technology. Sometimes it’s about understanding the work your existing code performs and removing what doesn’t need to happen.

You don’t always need another framework, a new database, or a complete rewrite.

Sometimes you need a query counter, a profiler, and an honest look at your request logs.

Build for correctness first. Measure performance before guessing. And when something becomes slow, find the bottleneck before reaching for a solution.

Because the code that works beautifully with 100 records isn’t necessarily the code that will behave beautifully with a million.

And learning to recognize the difference is one of the most valuable skills a Python developer can develop.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

Disclosure: This post includes affiliate and partnership links.

The Performance Problems I Didn’t Notice Until My Websites Got Bigger was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

read here.

When I first started writing CSS, I thought I was pretty good at it.

💥 Master AI & Tech Skills in 3 Months!
💰 One Subscription. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

I could center elements, change colors, build navigation bars, and make a page look reasonably close to a design.

Then I had to change that design.

A small adjustment to the layout broke three other sections. A heading looked perfect on my laptop but overflowed on mobile. And don’t even get me started on the mysterious margins that seemed to exist only to fix problems caused by other margins.

Sound familiar? 😅

For a while, I thought this was just part of frontend development.

It wasn’t.

The real problem was that I was learning how to make CSS work without learning how to make it maintainable.

After spending more time building websites, debugging layouts, and revisiting old projects, I started relying on techniques I had previously ignored.

Some of them looked too simple to matter. Others seemed unnecessarily complicated.

Today, they’re among the first things I reach for when writing CSS.

Here are eight techniques that genuinely changed how I approach frontend development.

1. Flexbox and Grid: Stop Fighting Your Layout

One of my earliest CSS habits was using margins to position everything.

Need an element farther to the right? Add margin-left.

Need some space above it? Add margin-top.

Need two elements aligned? Add a few more properties and hope for the best.

It worked until the content changed.

The moment a heading became longer or a container got narrower, the layout started falling apart.

That’s when I began taking Flexbox and Grid more seriously.

Use Flexbox for one-dimensional layouts

Flexbox works particularly well when you’re arranging elements in a row or column.

For example, consider a navigation bar with a logo on the left and navigation links on the right.

Instead of manually positioning both sides, I can write:

.navbar {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 1rem;
}

That’s it.

The browser handles the alignment and spacing between the two sides.

If the content changes, the layout can adapt without requiring me to recalculate margins.

Use Grid when rows and columns matter

Now imagine building a dashboard with several cards.

You could use Flexbox, but CSS Grid gives you a more natural way to define a two-dimensional layout.

.dashboard {
  display: grid;
  grid-template-columns: repeat(3, minmax(0, 1fr));
  gap: 1.5rem;
}

Each card occupies one column, and gap controls the spacing.

The interesting part is minmax(0, 1fr).

The zero minimum allows a grid track to shrink below its content’s intrinsic minimum size. This helps prevent long text or wide content from forcing a column wider than intended.

It’s one of those tiny details you might ignore when learning Grid but appreciate when debugging a real dashboard.

My rule of thumb: Use Flexbox when the arrangement primarily follows one direction. Use Grid when you need to manage rows and columns together.

Neither tool is inherently better. The trick is choosing the one that matches the problem.

2. CSS Custom Properties: Stop Repeating Yourself

I once worked on a layout where the same shade of blue appeared in buttons, links, headings, and several background elements.

Initially, that seemed harmless.

Then the design changed.

What should have been a simple color adjustment turned into a search through multiple stylesheets.

I had duplicated the same value everywhere, so every change required more work than it should have.

CSS custom properties solve this problem.

:root {
  --color-primary: #2563eb;
  --color-text: #1f2937;
  --color-muted: #6b7280;
  --spacing-md: 1rem;
  --radius-md: 0.75rem;
}
.button {
  background-color: var(--color-primary);
  border-radius: var(--radius-md);
  padding: var(--spacing-md);
}
.heading {
  color: var(--color-text);
}
.description {
  color: var(--color-muted);
}Now the design values live in one place.

If the primary color changes, I update one variable instead of hunting through the entire codebase.

But there’s a more important benefit.

Custom properties make design decisions explicit.

When I see var(--spacing-md), I understand that the value belongs to a spacing system. When I see 17px repeated throughout a stylesheet, I have to guess whether those values were intentional or simply accumulated over time.

For larger projects, this becomes especially useful when implementing themes.

:root {
  --surface: #ffffff;
  --text: #111827;
}
[data-theme="dark"] {
  --surface: #111827;
  --text: #f9fafb;
}
body {
  background: var(--surface);
  color: var(--text);
}Changing the data-theme attribute lets the same components use different colors without rewriting their individual styles.

One important distinction: CSS custom properties aren’t just preprocessor variables. They participate in the CSS cascade and can change at runtime.

That makes them useful for theming, component customization, and values controlled by JavaScript.

The lesson: If a value represents a reusable design decision, give it a name.

Your future self will thank you.

3. clamp(): Responsive Typography Without a Media Query for Everything

Responsive design used to mean writing media queries for every little adjustment.

A heading looked too large on mobile? Add a breakpoint.

It looked too small on a tablet? Add another.

Then the design changed, and the carefully chosen values stopped making sense.

CSS’s clamp() function offers a simpler approach for many of these situations.

It accepts three values:

clamp(minimum, preferred, maximum)

The browser tries to use the preferred value but keeps it within the specified minimum and maximum.

Here’s how I use it for a responsive heading:

.hero-title {
  font-size: clamp(2rem, 1.2rem + 3vw, 4rem);
  line-height: 1.1;
}

The heading scales with the viewport instead of jumping abruptly between fixed font sizes.

On smaller screens, it stays above the minimum. On larger screens, it stops growing at the maximum.

And I don’t need a separate media query just to adjust its size.

The same technique works for spacing:

.hero {
  padding-block: clamp(2rem, 6vw, 6rem);
  padding-inline: clamp(1rem, 4vw, 3rem);
}

This creates fluid spacing while keeping the extremes under control.

There is one detail worth remembering: vw alone can produce awkward results because text might become too small or too large at the extremes. Combining viewport units with a relative base value, then setting sensible limits, usually produces more predictable behavior.

Also, clamp() isn't a replacement for every media query. Sometimes a layout needs a genuine structural change rather than gradual scaling.

The takeaway: Let CSS handle continuous adjustments. Save media queries for changes that actually need a breakpoint.

4. :is() and :where(): Write Selectors You Can Maintain

As a stylesheet grows, selectors can become surprisingly complicated.

You might have several elements that share the same styling, but each one requires a different selector.

For example:

.card h2,
.card h3,
.card h4 {
  margin-block: 0 0.75rem;
}

There’s nothing wrong with this.

But imagine repeating the same pattern across a much larger stylesheet.

The :is() pseudo-class lets you group selector alternatives:

.card :is(h2, h3, h4) {
  margin-block: 0 0.75rem;
}

This becomes particularly useful when the selectors themselves are more complicated.

For example:

:is(.article, .sidebar) :is(h2, h3) {
  line-height: 1.25;
}

There’s also :where(), which looks similar but has a useful difference: its specificity is always zero.

Why does that matter?

Because specificity determines which competing CSS rule wins when multiple declarations apply to the same element.

Consider a reusable component stylesheet. If its default styles have unnecessarily high specificity, overriding them later can become frustrating.

Using :where() helps keep defaults easy to override:

:where(.card) h2 {
  margin-top: 0;
}

The selector contributes zero specificity for the entire :where() argument, making the rule easier to override with another appropriately scoped selector.

This is particularly useful when building reusable components, design systems, and base stylesheets.

One caution: :is() takes the specificity of its most specific argument, while :where() always contributes zero specificity. They look alike, but they aren't interchangeable in every situation.

My advice: Don’t optimize selectors just to make them shorter. Use these pseudo-classes when they improve readability or make your styles easier to override.

5. Mobile-First CSS: Start Small, Then Add Complexity

I used to build desktop layouts first and then try to squeeze them onto smaller screens.

Sometimes that worked.

Other times, the mobile version became a collection of exceptions.

The sidebar needed to disappear. The columns needed to stack. The font sizes needed to shrink. The navigation needed an entirely different layout.

The problem wasn’t that media queries were bad.

I had simply started with the wrong assumption: that the desktop layout should be the default everywhere.

A mobile-first approach starts with the smaller layout and adds complexity as more space becomes available.

.product-grid {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
}
@media (min-width: 40rem) {
  .product-grid {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}
@media (min-width: 64rem) {
  .product-grid {
    grid-template-columns: repeat(3, minmax(0, 1fr));
  }
}The default layout uses one column.

At wider viewport sizes, it expands to two and then three columns.

This is easy to understand because each breakpoint introduces a specific enhancement rather than undoing a collection of desktop assumptions.

But here’s something I learned later: mobile-first doesn’t mean designing exclusively for mobile.

It means establishing a sensible baseline and progressively adapting the layout.

You should still test at intermediate widths. A page can look perfect at 390 pixels and 1440 pixels but fall apart somewhere between them.

And don’t choose breakpoints simply because a particular phone or tablet exists. Choose them when your content needs the layout to change.

That’s a much more durable approach.

6. CSS Logical Properties: Make Layouts Less Dependent on Direction

This technique took me longer to appreciate than it should have.

Most developers learn properties such as:

margin-left: 1rem;
padding-right: 1rem;

They’re perfectly valid.

But they describe physical directions rather than the logical structure of the content.

That distinction becomes important when supporting right-to-left languages or different writing modes.

Logical properties let you describe spacing in terms of the content’s inline and block directions.

For example:

.card {
  padding-inline: 1.5rem;
  padding-block: 1rem;
}
.card-title {
  margin-block-end: 0.75rem;
}

Here:

• padding-inline applies padding along the inline direction.
• padding-block applies padding along the block direction.
• margin-block-end adds space at the end of the block direction.

For a typical left-to-right horizontal layout, the inline direction runs from left to right and the block direction runs from top to bottom.

In a right-to-left layout, the inline direction adapts accordingly.

That means your CSS can respond to the writing direction without requiring you to replace every left and right declaration manually.

For example, a component with an icon and text can use logical spacing:

.icon {
  margin-inline-end: 0.5rem;
}

The spacing stays on the end side of the inline content direction.

This is particularly helpful when building internationalized applications.

Even if you never plan to support right-to-left languages, logical properties can make your stylesheets more expressive because they describe relationships rather than fixed screen directions.

The bigger lesson: Write CSS that describes what you mean, not just where something happens to appear today.

7. Container Queries: Stop Making Every Component Care About the Viewport

Here’s a problem that appears when a project grows.

You build a beautiful card for a full-width page.

Then someone places the same card inside a narrow sidebar.

The viewport hasn’t changed, so your media queries don’t activate. But the card has much less room, and its layout no longer works.

This is where container queries become useful.

Traditional media queries respond to conditions such as viewport width.

Container queries let a component respond to the size of a designated container.

First, define the container:

.card-wrapper {
  container-type: inline-size;
}

Then style the component based on the container’s available width:

.product-card {
  display: grid;
  grid-template-columns: 1fr;
  gap: 1rem;
}
@container (min-width: 32rem) {
  .product-card {
    grid-template-columns: 10rem minmax(0, 1fr);
    align-items: center;
  }
}When the container reaches the specified width, the card changes from a single-column layout to a two-column layout.

The same component can now work in a wide content area and a narrow sidebar without relying on the overall viewport size.

This is a big deal for reusable UI.

Think about:

• Product cards used across multiple pages.
• Dashboard widgets.
• Article previews.
• Components inside resizable panels.
• Reusable components in a design system.

Instead of making every component aware of the page layout, you give it the ability to respond to the space it actually receives.

There is one important detail: a container query needs an appropriate containment context, such as the container-type: inline-size declaration above. Without it, the browser doesn't have the designated query container you're expecting.

My takeaway: Media queries help you adapt the page. Container queries help you adapt the component.

That distinction makes reusable CSS much easier to reason about.

8. min(), max(), and minmax(): Let the Browser Calculate the Layout

I used to write fixed widths for containers and then add media queries when they stopped fitting.

For example, a content section might need a maximum width of 1200 pixels while still leaving space around it on smaller screens.

You could solve that with multiple declarations and breakpoints.

Or you could write:

.container {
  width: min(100% - 2rem, 75rem);
  margin-inline: auto;
}

The min() function selects the smaller of its arguments.

So the container uses the available width minus two rems when space is limited, but it never exceeds 75 rems.

The result is a centered layout with responsive side spacing and a maximum width.

No additional media query is necessary for that particular behavior.

The related max() function chooses the larger value:

.section {
  padding-inline: max(1rem, 4vw);
}

This keeps the padding from dropping below one rem while allowing it to grow on wider screens.

Then there’s minmax(), which is especially useful with CSS Grid.

.gallery {
  display: grid;
  grid-template-columns: repeat(
    auto-fit,
    minmax(min(100%, 16rem), 1fr)
  );
  gap: 1rem;
}

This creates a flexible gallery where columns can fit into the available space without becoming narrower than the usable minimum. The nested min() also helps the grid behave when the container itself is narrower than 16 rems.

As the available width changes, the browser determines how many columns can fit.

You don’t need to write a media query for every possible number of cards.

That’s the beauty of intrinsic and fluid layout techniques: you describe the constraints, and the browser calculates a suitable arrangement.

Of course, these functions aren’t magic. You still need to understand the available space, minimum sizes, and content constraints.

But once you get comfortable with them, you can eliminate a surprising amount of breakpoint-specific CSS.

The principle: Describe the layout’s limits instead of hardcoding every possible outcome.

The CSS Habit That Made the Biggest Difference

Learning these techniques helped me solve specific problems.

But the biggest improvement came from changing how I approached CSS in the first place.

I stopped asking:

“How can I make this element look right? “

And started asking:

“What rules would keep this layout working when the content, screen size, or design changes?”

That question leads to different decisions.

Instead of adding arbitrary margins, I look at the layout system.

Instead of repeating colors, I define custom properties.

Instead of creating a media query for every font-size adjustment, I consider fluid sizing.

Instead of making reusable components depend on the viewport, I consider container queries.

None of these techniques is particularly difficult on its own.

The difference comes from knowing when to use each one.

Here’s a small checklist I use when reviewing CSS:

• Can Flexbox or Grid replace fragile positioning?
• Are repeated design values represented by custom properties?
• Can fluid sizing eliminate unnecessary breakpoints?
• Are selectors easy to override?
• Does the layout work at intermediate screen widths?
• Would logical properties make the component more adaptable
• Should this component respond to its container instead of the viewport?
• Can intrinsic sizing replace hardcoded dimensions?

You don’t need to apply every technique to every component. Overengineering a simple layout is still overengineering.

The goal is to choose the simplest approach that remains reliable as the project grows.

Pro Tip: Good CSS isn’t the CSS with the fewest lines. It’s the CSS that makes the next change predictable.

Final Thoughts

I used to think getting better at CSS meant memorizing more properties.

Now I think it means understanding the browser’s layout system well enough to stop fighting it.

Flexbox and Grid handle relationships between elements. Custom properties keep design decisions consistent. clamp() makes sizing fluid. Logical properties make components more adaptable. Container queries help reusable components respond to their surroundings.

Each technique solves a different problem, but they share one principle: write CSS around constraints and relationships rather than a collection of fixed values.

The web will keep changing. Designs will become more complex, components will be reused in unexpected places, and requirements will change halfway through a project.

That’s normal.

Your CSS shouldn’t need a complete rewrite every time that happens.

Start with one technique in your next project. Apply it to a real problem, see how it behaves, and build from there.

You might be surprised by how much easier your next redesign becomes.

And if you’re still using five different margins to center one element, don’t worry.

We’ve all been there.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

Disclosure: This post includes affiliate and partnership links.

The CSS Techniques I Ignored as a Beginner but Use in Almost Every Project was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

read here.

Every few weeks, the web development world seems to discover something new.

💥 Master AI & Tech Skills in 3 Months!
💰 One Subscription. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

A new JavaScript framework promises better performance. A new build tool claims to make development ridiculously fast. Then another library appears, and suddenly everyone on social media seems to be using it.

I’ve been there.

I used to treat every new release like homework. If experienced developers were talking about a tool, I felt I needed to understand it. If a framework was trending on GitHub, I wanted to try it.

My browser bookmarks were full of tutorials I planned to watch someday.

Some weekends, I’d start learning a new library before finishing the project I’d started the previous weekend.

Sound familiar?

The problem wasn’t that these tools were useless. Many of them were genuinely impressive.

The problem was that I was spending more time learning what was new than understanding what I already knew.

Eventually, I changed how I approached web development.

And surprisingly, I started writing better code, debugging faster, and making more confident technical decisions.

Here’s what changed.

1. I Realized That Knowing More Frameworks Didn’t Mean I Understood the Web Better

For a while, I thought becoming a better web developer meant adding more technologies to my toolkit.

React? Learn it.

Vue? Worth exploring.

Svelte? Better understand how it works.

A new meta-framework? Add it to the list.

There was always something else to learn.

But I noticed something frustrating when I started building more complicated applications.

I could follow a tutorial to create a component, connect an API, and display data on a page. Yet when something behaved unexpectedly, I sometimes struggled to understand why.

The framework wasn’t necessarily the problem.

My understanding of the underlying web platform was incomplete.

For example, consider a page that makes several API requests and suddenly feels slow.

You could spend hours looking for a framework-specific optimization. Or you could investigate the actual problem:

• Are requests running sequentially when they could run concurrently?
• Is the browser downloading unnecessarily large assets?
• Is JavaScript blocking the main thread?
• Is the server responding slowly?
• Are repeated renders doing expensive work?

These questions aren’t specific to React, Vue, or any other framework.

They’re web development questions.

Once I started investigating problems at that level, I became less dependent on whichever tool I happened to be using.

The lesson: Framework knowledge helps you build applications. Understanding the browser, HTTP, JavaScript, and rendering helps you understand why those applications behave the way they do.

That second skill travels with you.

2. I Started Learning JavaScript More Deeply Instead of Collecting Frameworks

JavaScript is one of those languages that looks deceptively simple when you’re following tutorials.

You can build a working application without understanding every detail of how the language behaves.

Eventually, though, your application becomes complicated enough to expose the gaps.

I learned this particularly well when dealing with asynchronous operations.

Consider this example:

async function loadDashboard() {
  const users = await fetch("/api/users");
  const orders = await fetch("/api/orders");
  const products = await fetch("/api/products");
return {
    users: await users.json(),
    orders: await orders.json(),
    products: await products.json()
  };
}

The code is readable, and it works.

But there’s a potential performance problem.

Each request waits for the previous request to finish before starting. If the three requests are independent, that waiting is unnecessary.

We can run them concurrently instead:

async function loadDashboard() {
  const [usersResponse, ordersResponse, productsResponse] =
    await Promise.all([
      fetch("/api/users"),
      fetch("/api/orders"),
      fetch("/api/products")
    ]);
const [users, orders, products] = await Promise.all([
    usersResponse.json(),
    ordersResponse.json(),
    productsResponse.json()
  ]);
  return { users, orders, products };
}Now the independent requests can run concurrently, although the actual improvement depends on network conditions, server behavior, and response sizes.

Notice what happened here.

We didn’t change frameworks. We didn’t install another package. We didn’t rewrite the application.

We simply understood asynchronous JavaScript a little better.

Of course, this example also assumes the responses succeed. In production, I’d check response.ok and handle failures deliberately.

That detail matters, too.

The more deeply I understood JavaScript, the more often I could solve problems without reaching for another dependency.

And honestly, that felt better than finishing another beginner tutorial.

3. I Stopped Rewriting Projects Just Because a New Tool Appeared

This was probably one of my most expensive habits.

I’d build something using a technology I understood reasonably well. Then I’d discover a newer alternative and start wondering whether I should rebuild everything.

Maybe the new framework had a better developer experience.

Maybe the new build tool was faster.

Maybe someone on YouTube had explained why my current stack was outdated.

Before long, I was considering a rewrite that nobody had asked for.

Here’s what I eventually realized: working software doesn’t automatically need replacing just because a newer option exists.

Imagine you’ve built a small e-commerce dashboard.

It works. Users can manage products, update inventory, and review orders. The code is reasonably maintainable, and the application performs well enough for its workload.

Then you discover a new framework.

Should you migrate?

Not necessarily.

I’d first ask:

• What specific problem does the new framework solve?
• Is that problem affecting my current application?
• How much migration work would be required?
• Will the new architecture make future changes easier?
• Can I measure a meaningful improvement?

If I can’t identify a concrete benefit, the migration probably isn’t worth prioritizing.

That doesn’t mean avoiding new technologies. It means having a reason to adopt them.

Sometimes a migration is absolutely the right decision. An outdated dependency, serious performance limitations, security concerns, or an architecture that makes every change painful can justify the effort.

But novelty alone isn’t a business requirement.

Pro tip: Before replacing a technology, write down the problem you’re trying to solve and how you’ll measure success. If you can’t do either, investigate further before starting the rewrite.

Your future self will thank you.

4. I Learned to Read Documentation Before Watching Another Tutorial

I still use tutorials.

They can be excellent for understanding unfamiliar concepts, seeing a workflow in action, or getting a project off the ground.

But I used to depend on them too much.

I’d watch someone build a feature, copy the implementation, and move on. Everything made sense while the instructor was explaining it.

Then I’d try to adapt the same code to my own project.

Suddenly, the easy part wasn’t so easy.

The tutorial assumed a different application structure. The API behaved differently. A library option had changed. My requirements didn’t match the example.

I needed to understand the tool, not just reproduce someone else’s solution.

That’s when I started spending more time with official documentation.

For example, when working with browser APIs, I’d consult the MDN Web Docs. When using a framework or library, I’d check its official documentation for supported behavior, configuration options, and limitations.

This changed how I approached unfamiliar problems.

Instead of asking, “Which tutorial shows me how to do this?” I’d ask, “What does this API actually guarantee, and what assumptions am I making?”

That question often leads to better code.

Documentation also teaches you things tutorials sometimes skip: edge cases, browser compatibility, error behavior, accessibility considerations, and performance implications.

You don’t need to memorize every API.

You need to become comfortable finding reliable answers.

That’s a much more useful skill.

5. I Started Caring More About Browser Performance Than Developer Hype

A development tool can feel incredibly fast while the website built with it feels slow.

These are two different things.

A fast development server makes your local workflow more pleasant. It doesn’t automatically make your production application load faster.

Similarly, a framework can offer a fantastic developer experience while your application still ships oversized JavaScript bundles, unoptimized images, or unnecessary network requests.

I started paying closer attention to what users actually experienced.

For example, when a page felt slow, I’d inspect it using Chrome DevTools rather than immediately installing another optimization library.

I’d look at:

• Network requests and response sizes.
• JavaScript execution time.
• Layout shifts and rendering behavior.
• Images that were larger than necessary.
• Expensive work happening on the main thread.

I’d also use Lighthouse as an initial diagnostic tool and investigate the results instead of blindly accepting every recommendation.

One particularly useful concept is Core Web Vitals.

Google’s metrics include Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). They help evaluate loading performance, responsiveness, and visual stability.

These metrics give developers something more useful than “the website feels kind of slow.”

They provide measurable signals to investigate.

Of course, a single Lighthouse run isn’t a complete picture of real-world performance. Lab conditions differ from actual users’ devices and networks, so field data is valuable when available.

The important shift was simple.

I stopped asking whether my stack was modern enough and started asking whether my application was delivering a good experience.

Users don’t care which framework I used.

They care whether the page loads, the buttons respond, and the checkout process works.

Fair enough.

6. I Became More Careful About Adding Dependencies

Every library solves a problem.

It can also introduce another dependency to maintain, update, understand, and occasionally debug.

Early on, I sometimes installed packages for tasks that required only a few lines of native JavaScript.

A utility package for a small formatting operation. Another library for something the browser already supported. Yet another dependency because a tutorial happened to use it.

Individually, these decisions seemed harmless.

Over time, they could make a project harder to maintain.

Now, before adding a dependency, I ask a few questions.

First, do I actually need it?

If a task is straightforward and the native solution is readable, a new package may add more complexity than value.

Second, is the problem complicated enough to justify a library?

Authentication, date and time handling, complex form validation, and specialized data processing can have enough edge cases to justify established solutions.

Reinventing these systems can be far more expensive than using a well-maintained package.

Third, can I trust the dependency?

I look at its documentation, maintenance activity, license, security history, compatibility, and whether it fits the project’s requirements.

I don’t expect every package to be perfect. I want to understand what I’m introducing into the application.

Here’s a small example.

If I need to check whether a string contains another string, JavaScript already provides includes().

const message = "Learning web development";
console.log(message.includes("web")); // trueInstalling a package for this would be unnecessary.

But if I need sophisticated date-time calculations across time zones, using a reputable date-time library may be a much better decision than writing a collection of fragile custom functions.

The point isn’t to minimize dependencies at all costs.

It’s to make every dependency earn its place.

7. I Started Finishing Projects Instead of Constantly Starting New Ones

This change had less to do with technology and more to do with how I learned.

Starting a project is exciting.

You choose a stack, create the initial files, install dependencies, and build the first few features. Everything moves quickly because you’re working through the parts you already understand.

Then the less glamorous work begins.

You need to handle invalid input, loading states, failed requests, accessibility, testing, deployment, and unexpected user behavior.

Suddenly, that exciting weekend project requires actual engineering decisions.

I used to get distracted around this stage.

A new tool would appear, and I’d convince myself that experimenting with it was a productive use of time.

Sometimes it was.

Often, it was an excellent way to avoid finishing the difficult part of my existing project.

So I changed the rule.

Before starting another project, I try to bring the current one to a useful stopping point.

That means different things for different applications, but it generally includes:

• Handling common error cases.
• Adding meaningful tests.
• Improving accessibility and usability.
• Documenting setup and configuration.
• Deploying the application somewhere it can actually be used.

This is where many of the most valuable lessons appear.

You discover that the elegant solution from a tutorial doesn’t handle real-world input. You find out that your deployment environment differs from your local machine. You learn that a component is difficult to test because its responsibilities are tangled together.

These are the problems that turn familiarity into experience.

A developer who has finished and maintained several applications has encountered challenges that someone who has only completed tutorials may not have seen yet.

And no new framework can give you that experience automatically.

8. I Finally Understood That Learning Less Can Mean Learning Better

Let me clarify something.

I’m not suggesting that web developers should ignore new technologies.

That would be a terrible strategy in a field that continues to evolve.

New frameworks, browser APIs, development tools, and architectural approaches can genuinely improve how we build software.

I still explore them.

I just don’t treat every new release as an obligation.

When I encounter an unfamiliar tool, I evaluate it based on the problems I work on, the skills I want to develop, and the value it could bring to a real project.

Sometimes I build a small proof of concept.

Sometimes I read the documentation and move on.

Sometimes I decide that the existing tool is perfectly adequate.

All three are valid outcomes.

I’ve also become more intentional about what I study.

Instead of learning a new framework every time I feel stuck, I might spend that time understanding:

• How HTTP caching works.
• Why browser rendering can become expensive.
• How JavaScript’s event loop affects responsiveness.
• How to design APIs with predictable error handling.
• How to test asynchronous code reliably.
• How to structure applications so that individual components are easier to maintain.

These concepts aren’t always exciting to post about on social media.

But they’re useful in almost every serious web development project.

And the knowledge compounds.

When you understand the browser, a new framework becomes easier to evaluate. When you understand asynchronous JavaScript, a new data-fetching library becomes easier to reason about. When you understand testing, a new architecture becomes easier to maintain.

Fundamentals don’t eliminate the need to learn new tools.

They make learning new tools much easier.

My Simple Rule for Evaluating Web Development Trends

Whenever I encounter a new framework, library, or development tool, I try to answer three questions:

1. What problem does it solve?

I want a clear explanation beyond “it’s modern” or “everyone is using it.”

2. Is that problem relevant to my work?

A tool can be excellent and still be unnecessary for my current projects.

3. Is the benefit worth the learning and maintenance cost?

Every new technology requires some investment. I want that investment to produce a meaningful return.

If a tool passes these questions, I’ll happily explore it.

If it doesn’t, I don’t feel guilty about skipping it.

There will always be another release, another announcement, and another developer insisting that the old way is dead.

You don’t have to attend every technological parade.

Sometimes, you just need to finish building your application.

Final Thoughts

I used to measure my growth as a web developer by how many technologies I knew.

Now, I pay more attention to how well I can solve problems.

Can I identify the real cause of a performance issue?

Can I debug a complicated failure without randomly changing code until something works?

Can I choose an appropriate architecture without overengineering a simple application?

Can I explain why I selected a particular library instead of simply saying it’s popular?

Those questions tell me much more about my development skills than the number of frameworks I’ve tried.

The web development ecosystem will continue to change. Some tools will become essential, others will disappear, and a few will solve problems we haven’t encountered yet.

I’ll keep learning.

I’ll keep experimenting.

But I no longer want to spend every week chasing something new while neglecting the skills that make me effective.

The goal isn’t to know every tool in web development. It’s to know enough to choose the right tool, understand what it does, and build something that works reliably.

That’s what made me a better developer.

Not following every trend.

Learning when a trend actually matters.

And sometimes, having the confidence to close the tutorial tab and finish the project I already started.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

Disclosure: This post includes affiliate and partnership links.

I Stopped Following Every Web Development Trend — and Became a Better Developer was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

read here.

When I first started building websites, I thought becoming a better developer meant learning more technologies.

💥 Master AI & Tech Skills
💰 One Plan. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

A new JavaScript framework? Interesting.

A faster CSS technique? I was in.

A new backend library? Time to experiment.

I spent plenty of time learning tools, trying frameworks, and looking for better ways to write code.

But after working on different kinds of web projects, I realized something unexpected.

Knowing how to build a website and knowing how to build a good website are two very different skills.

A page can look perfect on your laptop and break on a mobile phone. An API can work beautifully with ten users and struggle when hundreds of requests arrive simultaneously. A feature can take an hour to implement and three days to maintain.

These are the problems that tutorials don’t always prepare you for.

Here are the biggest lessons I’ve learned from building websites — and how they changed the way I approach development.

1. Clean Code Matters More When You Come Back to It

When you’re working on a small project, messy code doesn’t feel like a problem.

You know where everything is. You remember why you wrote a particular function. If something breaks, you can probably fix it in a few minutes.

Then the project grows.

Suddenly, one component handles authentication, form validation, API requests, and half the application’s business logic.

Changing one thing breaks something else.

I’ve learned that code isn’t just written for computers. It’s also written for the developer who has to understand it later.

Imagine building a registration form. You could put every validation rule directly inside the component. That might work initially, but adding password requirements, reusable error messages, and additional registration methods makes the component increasingly difficult to maintain.

Separating validation logic into its own function gives you a much cleaner starting point.

The same principle applies to backend services, database queries, and API integrations.

My rule now: If a function needs a long explanation before someone can understand it, I look for a simpler design.

You don’t need to abstract everything. You just need to make future changes less painful.

2. Responsive Design Is Not Something You Add at the End

One of the easiest mistakes in web development is designing for desktop first and treating mobile support as a final adjustment.

I’ve learned that this approach often creates unnecessary work.

A navigation bar that looks elegant on a wide screen might become unusable on a phone. A three-column dashboard might turn into a horizontal scrolling nightmare. Buttons that look perfectly spaced on desktop can become frustratingly difficult to tap.

The problem isn’t always the CSS.

Sometimes the layout itself needs a different approach.

For example, CSS Grid can handle a responsive card layout without requiring separate media queries for every possible screen width.

.card-grid {
    display: grid;
    grid-template-columns: repeat(
        auto-fit,
        minmax(min(100%, 250px), 1fr)
    );
    gap: 1rem;
}

This lets the browser fit as many cards as the available space allows while keeping each card at a reasonable minimum width.

Instead of manually defining every layout change, you let CSS handle much of the work.

I also test forms, navigation menus, tables, and modals on smaller screens early in development.

The lesson: Responsive design is an architectural decision, not a finishing touch.

3. The Happy Path Is Not Enough

It’s easy to build a feature that works when everything goes right.

A user submits valid information. The server responds immediately. The database connection works. Nothing times out.

Real applications aren’t that polite.

Users submit incomplete forms. Networks fail. APIs return unexpected responses. Someone clicks a button twice because the first click appears to do nothing.

And suddenly, your perfectly working feature isn’t so perfect.

Consider a form that sends data to an API. A basic implementation might show a success message when the request finishes. A more reliable implementation also handles loading, validation errors, network failures, and duplicate submissions.

For example:

async function submitForm(data) {
    try {
        const response = await fetch("/api/submit", {
            method: "POST",
            headers: {
                "Content-Type": "application/json"
            },
            body: JSON.stringify(data)
        });
if (!response.ok) {
            throw new Error(
                `Request failed: ${response.status}`
            );
        }
        return await response.json();
    } catch (error) {
        console.error("Submission failed:", error);
        throw error;
    }
}This doesn’t handle every production concern, but it makes an important distinction: a failed HTTP response is not the same as a successful one.

Depending on the application, you may also need request timeouts, retries, idempotency keys, and user-friendly error messages.

The most important question isn’t simply, “Does this work?”

It’s:

“What happens when this stops working?”

That question has helped me think more like an engineer and less like someone who is only trying to finish a feature.

4. Performance Problems Often Start With Small Decisions

You don’t always need a complicated optimization strategy to make a website faster.

Sometimes the biggest improvements come from fixing a few ordinary mistakes.

An oversized image can slow down an otherwise lightweight landing page. An API endpoint that performs repeated database queries can make a dashboard feel sluggish. Loading an entire JavaScript library for one small utility can increase the amount of code a browser needs to download.

The challenge is identifying which problem actually matters.

For frontend performance, I start by checking image sizes, unnecessary JavaScript, rendering behavior, and network requests.

For backend performance, I look at database query counts, slow endpoints, response payload sizes, and external API calls.

Tools such as browser developer tools, Lighthouse, and Python’s profiling utilities can help identify bottlenecks.

I try not to optimize based on intuition alone.

For example, if a dashboard takes three seconds to load, rewriting the frontend might accomplish very little if most of that time is spent waiting for an inefficient database query.

Measure first. Optimize second.

A small improvement in the right place can be more valuable than a complete rewrite of the wrong component.

5. Database Design Can Make or Break Your Application

When building a new feature, it’s tempting to focus on the interface first.

You create the form, connect the API, and store whatever data the frontend sends.

That approach works until the application needs more complicated queries, relationships, reporting, or data integrity.

Consider an e-commerce website.

If customer details, order information, and product data are all stored in one poorly structured table, updating a product name or retrieving a customer’s order history can become unnecessarily complicated.

A more thoughtful schema separates customers, orders, and products, then connects them through appropriate relationships.

Indexes can improve query performance, but adding indexes everywhere isn’t the answer either. They consume storage and can make writes more expensive.

The right design depends on how the application reads and writes its data.

I also pay attention to constraints, transactions, and migrations. These aren’t glamorous features, but they help protect the application from inconsistent data and risky deployments.

A beautiful interface cannot compensate for unreliable data underneath it.

6. Good APIs Make Frontend Development Easier

I’ve come to appreciate how much time a well-designed API can save across an entire project.

When an API has inconsistent response formats, unclear error messages, and unpredictable naming conventions, the frontend becomes responsible for compensating for those decisions.

Every endpoint starts to require its own special handling.

A more consistent API might return data in a predictable structure, use appropriate HTTP status codes, validate incoming requests, and document its expected inputs.

For example, a Python backend built with FastAPI can use Pydantic models to validate request data and generate an OpenAPI specification.

That makes it easier for frontend developers to understand what an endpoint expects without repeatedly inspecting backend code.

The same principle applies when working with external APIs.

I pay particular attention to authentication, rate limits, pagination, timeouts, and error handling. These details often determine whether an integration remains dependable after the initial demonstration.

A useful API isn’t merely one that returns the correct data.

It’s one that other parts of the system can depend on.

7. Testing Saves More Time Than It Costs

I used to think of testing as something that became important once a project grew large enough.

Now I see it differently.

Even small applications develop complicated behavior as features interact.

Imagine changing a shared authentication function. The change might fix one login issue but accidentally prevent password resets or break access to a protected page.

Without tests, you may discover the problem only after someone encounters it.

You don’t need thousands of tests to benefit from testing.

Start with the logic that would be expensive or embarrassing to break:

• Form validation and business rules.
• Authentication and authorization.
• Important API endpoints.
• Database operations.
• Critical user journeys.

For Python applications, pytest is an excellent starting point. For browser-level testing, tools such as Playwright can verify that users can complete important workflows.

I also distinguish between testing individual functions and testing how the entire application behaves. Both are useful, but they catch different kinds of problems.

A test suite won’t guarantee that your application has no bugs.

It does make many changes safer because you can catch regressions before they reach users.

8. Deployment Is Part of Development

A feature that works locally is not necessarily ready for production.

Your local machine may have environment variables that the server doesn’t. Your development database may contain data that doesn’t exist in production. File paths, permissions, dependencies, and network settings can all behave differently.

I’ve learned to treat deployment requirements as part of the project from the beginning.

That means keeping secrets out of source control, documenting environment variables, managing dependencies, and creating repeatable deployment steps.

It also means thinking about database migrations, logging, backups, and rollback strategies before they become urgent.

For applications that need them, health checks and monitoring help reveal problems that ordinary manual testing won’t catch.

There’s a big difference between deploying an application once and being able to deploy it reliably every week.

The second requires a process, not just a collection of terminal commands.

9. The Simplest Solution Is Often the Best One

New frameworks and architectural patterns can be exciting.

It’s tempting to use microservices for a small application, introduce a complex state-management library for a handful of components, or build an AI agent when a regular API call would do the job.

I’ve learned to resist that temptation.

Every additional dependency, abstraction, and service introduces another thing to understand, maintain, test, and potentially debug.

A straightforward application with clear boundaries may be a better choice than a complicated architecture designed for problems you don’t have yet.

This doesn’t mean avoiding advanced tools.

It means earning the complexity.

If background processing becomes necessary, introduce a task queue. If database queries become a bottleneck, profile them and consider indexing or caching. If separate services solve a genuine scaling or organizational problem, then consider splitting the application.

Pro tip: Don’t ask whether an architecture is sophisticated enough. Ask whether it solves the problem more reliably than a simpler alternative.

That mindset has helped me avoid plenty of unnecessary engineering.

10. Communication Is a Technical Skill, Too

Not every web development problem can be solved by writing more code.

Sometimes the real problem is an unclear requirement.

A client asks for a “fast dashboard,” but nobody defines what fast means. A designer expects a particular interaction that isn’t included in the specification. A teammate changes an API response without realizing another service depends on it.

These misunderstandings create rework.

Before implementing a feature, I try to clarify what success looks like, what the edge cases are, and which constraints matter most.

For a dashboard, that might mean agreeing on which metrics appear, how often the data refreshes, and how the page should behave when no data is available.

For a payment flow, it means discussing failed transactions, duplicate submissions, and confirmation states — not just the successful checkout.

Clear documentation and small, focused pull requests also make collaboration easier.

Good developers solve technical problems.

Great engineering teams also make sure they’re solving the right problems.

The Biggest Lesson of All

Looking back, the most important improvements in my web development workflow haven’t come from learning every new framework.

They’ve come from changing the questions I ask.

Instead of asking whether a feature works, I ask how it behaves when something fails.

Instead of asking whether code is clever, I ask whether another developer can maintain it.

Instead of asking whether an application runs locally, I ask whether it can be deployed, monitored, and updated safely.

And instead of adding another library, I ask whether the existing solution is actually insufficient.

These questions sound simple, but they change how you approach almost every project.

“Simplicity boils down to two steps: Identify the essential. Eliminate the rest.” — Leo Babauta

You don’t need to know every framework to become a better web developer.

You need to understand the problems your applications face, recognize the trade-offs behind your decisions, and learn from the mistakes you make along the way.

Because writing code is only one part of building software.

The real skill is building something that continues to work after the tutorial ends, the requirements change, and real users start depending on it.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

👉 CodeToDeploy Tech Community is live on Discord — Join now!

Disclosure: This post includes affiliate and partnership links.

The Biggest Lessons I Learned After Years of Building Websites was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.

read here.

The Article Outline

1. Everything Looked Easy in Tutorials

Start with the excitement of learning HTML, CSS, and JavaScript. A few tutorials later, you can build a landing page, add buttons, and make things look reasonably good.

💥 Master AI & Tech Skills
💰 One Plan. Multiple Courses. More Savings.
🔥 Get Up to 50% OFF | ⏰ Limited-Time Offer
👉 Enroll Now & Start Learning

Then you decide to build something from scratch.

That’s when things get interesting.

2. My First Real Project Exposed Everything I Didn’t Know

Explore the problems that tutorials often simplify:

• Making a responsive layout work across different screen sizes.
• Handling forms, validation, and unexpected user input.
• Connecting a frontend to a backend API.
• Managing loading states, errors, and missing data.
• Debugging code that works perfectly in one situation but fails in another.

3. The Frontend Was Only Half the Problem

Explain why a polished interface is not the same as a complete application. Real projects require data persistence, authentication when needed, API integration, security, and thoughtful error handling.

4. Debugging Became a Bigger Skill Than Writing Code

Share how reading error messages, using browser developer tools, inspecting network requests, and isolating bugs became essential parts of development.

5. I Started Understanding Why Developers Care About Code Quality

Introduce practical lessons about reusable components, clear naming, separating responsibilities, Git, environment variables, and testing.

The key insight: code that works today should also be understandable and maintainable tomorrow.

6. What I Would Do Differently Today

Offer practical advice for developers starting their first serious project:

• Build something small that solves a real problem.
• Finish one complete feature before adding another.
• Learn browser developer tools early.
• Handle errors instead of assuming everything will work.
• Deploy the application before considering it finished.
• Treat documentation and debugging as part of development, not interruptions.

Final Thoughts

The biggest lesson wasn’t that web development was impossibly difficult. It was that building a working application involves much more than writing code that looks right.

Tutorials taught me how to make things work. My first real project taught me how to make them keep working.

Thank you for being a part of the community

Before you go:

👉 Be sure to clap and follow the writer ️👏️️

👉 Follow us: Medium

👉 CodeToDeploy Tech Community is live on Discord — Join now!

Disclosure: This post includes affiliate and partnership links.

I Thought Web Development Was Easy Until I Built My First Real Project was originally published in CodeToDeploy on Medium, where people are continuing the conversation by highlighting and responding to this story.