DEV Community: Bharath Kumar_30

What Happens to Junior Developers When AI Becomes Better Than Junior Developers?

Bharath Kumar_30 — Tue, 15 Sep 2026 08:57:17 +0000

I don't think the biggest question about AI is "Will it replace developers?"

I think it's this: **Who gets the chance to become a developer in the first place?**

A few years ago, if you wanted to become a software developer, the path was relatively simple.

Learn a programming language.

Build some projects.

Break things.

Google the error.

Build more projects.

Get an internship.

Become a junior developer.

Make mistakes for a few years.

Eventually, become a senior developer.

Simple enough.

But now something strange is happening.

AI can already write code.

It can explain code.

It can find bugs.

It can generate tests.

It can create APIs.

It can help design systems.

And increasingly, AI coding agents can work across entire repositories rather than just generating a few lines.

So I started thinking about something that honestly bothers me a little.

What happens when AI becomes better than a junior developer?

Not better than a 10-year senior engineer.

Not better than a staff engineer designing massive distributed systems.

I'm talking about something much simpler.

What happens when an AI can do the work that companies traditionally give to junior developers?

Things like:

Create an API
Fix a bug
Write unit tests
Convert a SQL query
Add a feature
Create a CRUD application
Explain why a function is failing

If an AI can do these things in seconds...

why would a company hire someone who needs months to learn them?

And that's where things get interesting.

The Junior Developer Job Was More Than a Job

Here's the part I think we sometimes forget.

A junior developer wasn't hired because they were extremely productive.

They were hired because they had potential.

The company was essentially saying:

"You don't know everything yet. That's okay. We'll teach you."

The junior developer would slowly learn how real software works.

They'd see terrible legacy code.

They'd attend meetings where nobody understands the requirements.

They'd deploy something on Friday and immediately regret it.

They'd fix bugs at 11 PM.

They'd learn why:

"It works on my machine."

is not an acceptable production strategy.

Those experiences create senior engineers.

But if AI handles most of the beginner work...

where does the experience come from?

The Weird Paradox

Imagine the year is 2030.

You are a new developer.

You know JavaScript.

You know Python.

You've built five projects.

You understand databases.

You understand APIs.

You apply for a job.

The interviewer gives you a simple task:

"Build a REST API for managing users."

You start thinking about the architecture.

Then the interviewer says:

"You don't need to build it."

You look confused.

They continue:

"Our AI agent can already build it."

Now what?

Maybe Coding Won't Be the Entry Ticket Anymore

This is where I think the definition of a developer could change.

Today we often think:

Developer = Person who writes code

But maybe the future looks more like:

Developer = Person who understands problems deeply
             +
             designs solutions
             +
             directs AI
             +
             validates the result
             +
             takes responsibility

The ability to type code may become less valuable.

The ability to know what code should exist could become more valuable.

That's a very different skill.

"But AI Makes Mistakes!"

Yes.

Absolutely.

AI can generate terrible code.

It can misunderstand requirements.

It can hallucinate APIs.

It can introduce security vulnerabilities.

It can make a beautifully complicated solution to a problem that needed five lines.

So I'm not saying:

"AI will write everything perfectly."

That's not the point.

The interesting question is:

How much human coding is required when AI becomes 80–90% reliable at common development tasks?

Because even if the AI needs a human to review everything...

that's still a huge productivity change.

Imagine one engineer who can effectively operate like five engineers because AI handles much of the implementation work.

That changes hiring.

And This Creates a Problem Nobody Talks About Enough

Suppose companies need fewer junior developers.

Senior developers remain.

AI handles much of the repetitive implementation.

Then we have:

Today:

Junior → Mid → Senior → Staff
   ↑
Learning happens here


Possible future:

AI handles much of this
        ↓
Junior opportunities decrease
        ↓
Fewer people gain experience
        ↓
Where do future seniors come from?

That's the paradox.

We need experienced engineers.

But experienced engineers have to come from somewhere.

Maybe the Definition of "Junior" Has to Change

I don't think the answer is:

"Stop using AI."

That's unrealistic.

Instead, maybe junior developers need to learn things that AI cannot simply replace with a prompt.

For example:

1. Understanding Systems

Don't just learn:

for item in items:
    ...

Understand:

Why does this system exist?
Where does the data come from?
What happens when 1 million users use it?
Where can it fail?
What happens if the database goes down?

2. Debugging Instead of Only Generating

Anyone can say:

"AI, fix this."

A good engineer asks:

"Why did this fail?"

There's a huge difference.

3. Understanding Trade-offs

AI can give you ten solutions.

But which one should you choose?

Solution A → cheaper

Solution B → faster

Solution C → easier to maintain

Solution D → more scalable

That's not purely a coding problem.

It's an engineering decision.

4. Learning to Question AI

This might become one of the most important developer skills.

Don't ask:

"Can AI write this?"

Ask:

"Should this be written this way?"

That's a completely different mindset.

I Actually Think AI Could Make Great Developers Even Better

Here's the optimistic side.

Imagine you're a developer.

Instead of spending three hours writing boilerplate code, AI does it.

You spend those three hours thinking about:

Architecture
Users
Security
Performance
Product design
Reliability
Edge cases

That's pretty exciting.

AI could remove some of the boring parts of software engineering.

And honestly...

there's a lot of boring code.

But There's One Thing I Don't Want AI to Remove

The struggle.

I know that sounds strange.

But some of the most valuable programming lessons come from things not working.

The bug that took five hours.

The database query that made absolutely no sense.

The deployment that broke everything.

The code you were embarrassed to look at six months later.

Those experiences teach something that tutorials don't.

They teach you how to think.

If AI fixes every problem before we have the opportunity to understand it...

we might become excellent at using AI while becoming terrible at understanding software.

And that's dangerous.

So Should You Still Learn Programming?

Absolutely.

But I think the reason is changing.

Don't learn programming only because:

"Companies need people who can write code."

Learn it because programming teaches you how to think precisely.

Learn:

Data structures
Algorithms
Databases
Networking
Operating systems
APIs
Distributed systems
Security
System design

And yes...

use AI while learning them.

Just don't let AI become the person doing all the thinking.

Maybe the Future Developer Looks Like This

Not this:

Human
  ↓
Writes code
  ↓
Runs code
  ↓
Fixes bugs

But this:

Human
  ↓
Defines the problem
  ↓
Designs the solution
  ↓
AI builds
  ↓
Human reviews
  ↓
AI tests
  ↓
Human validates
  ↓
AI deploys
  ↓
Human owns the outcome

The keyboard might become less important.

Judgment becomes more important.

And Then There Is AGI...

This is where things become much harder to predict.

If we eventually get something that genuinely deserves the name AGI — a system capable of broadly performing intellectual tasks at a very high level — then this conversation becomes much bigger than software development.

Because at that point, the question isn't:

"Will AI replace junior developers?"

It becomes:

"What work should humans do when intelligence itself becomes cheap?"

I don't know the answer.

I don't think anyone honestly does.

And maybe that's the most interesting part.

One Question I'd Ask Every Developer

Imagine tomorrow you receive access to an AI that can:

Understand your entire codebase
Write features
Fix bugs
Create tests
Review pull requests
Optimize queries
Deploy applications
Monitor production

You still have to keep your job.

What skill would you want to be paid for?

I'd love to hear your answer.

Because I don't think the future of developers is really about AI vs developers.

I think it's going to be about:

Developers who know how to use AI vs developers who don't.

And maybe, eventually...

something even more interesting.

Developers who know what humans should be doing when AI can do almost everything else.

What Do You Think?

Will AI make it harder for junior developers to enter the industry, or will it create completely new kinds of junior roles?

I'm genuinely curious what other developers think.

Drop your opinion in the comments.

Even if you disagree with me.

Especially if you disagree with me.

Designing a Multi-Agent AI Architecture for SiteGen AI

Bharath Kumar_30 — Wed, 08 Jul 2026 11:09:10 +0000

Designing a Multi-Agent AI Architecture for SiteGen AI

As SiteGen AI continued to evolve, I realized that asking a single AI model to generate an entire application wasn't the right approach.

The results were inconsistent.

Sometimes the frontend looked great.

Sometimes the backend was incomplete.

Sometimes the generated code didn't work together.

Instead of writing bigger prompts, I decided to redesign the entire architecture.

The Problem

The original workflow was straightforward.

A user entered a prompt.

The AI generated HTML, CSS, and JavaScript.

That worked well for simple landing pages, but it became difficult when users requested larger applications.

For example:

Build a Hospital Management System.

A complete software project requires much more than a homepage.

It needs APIs, authentication, databases, dashboards, documentation, and deployment configuration.

Generating all of that in a single AI response wasn't reliable.

Thinking Beyond One AI Prompt

Rather than making one prompt increasingly complex, I started dividing the work into smaller responsibilities.

Instead of one AI doing everything, different modules would focus on different parts of the application.

This approach is inspired by how software teams work.

Frontend developers focus on the user interface.

Backend developers build APIs.

Database engineers design schemas.

Quality assurance engineers verify the final product.

I wanted SiteGen AI to follow a similar workflow.

The New Workflow

The new architecture begins with understanding the user's request.

The first module analyzes the project and determines what needs to be built.

Once the project requirements are understood, the remaining modules begin generating different parts of the application.

The workflow looks like this:

Project Planner
Frontend Generator
Backend Generator
Database Generator
Authentication Generator
API Generator
Documentation Generator
Deployment Generator
Project Reviewer

Each module has a single responsibility.

Instead of generating everything at once, each component focuses on solving one problem well.

Why Modular Design Matters

One of the biggest advantages of this architecture is maintainability.

If I want to improve backend generation, I only need to update the backend module.

The frontend generation process remains unchanged.

The same applies to authentication, databases, and deployment.

This separation makes the project easier to test, easier to debug, and much easier to extend.

Better AI Prompts

Another benefit is prompt specialization.

Instead of writing one enormous prompt, every module receives a prompt specifically designed for its task.

For example, the backend generator only thinks about APIs, business logic, and project structure.

The frontend generator only focuses on user experience and interface design.

This improves both consistency and code quality.

Building for the Future

My goal is not to create another AI code generator.

I want SiteGen AI to become a platform capable of planning, designing, generating, and reviewing complete software projects.

As the project grows, additional modules can be added without redesigning the entire system.

This makes the architecture scalable for future features.

Lessons Learned

One lesson became very clear during this redesign.

Complex software should not rely on one intelligent component trying to do everything.

Breaking a large problem into smaller, specialized tasks produces better results and creates a system that is easier to improve over time.

That principle now guides every new feature I build for SiteGen AI.

What's Next

The next step is teaching SiteGen AI how to generate complete production-ready projects, including frontend, backend, authentication, database design, documentation, and deployment configuration from a single user prompt.

That will be the biggest milestone in the project's journey so far.

Thank you for reading.

Building SiteGen AI v2: From a Website Generator to an AI Software Engineer

Bharath Kumar_30 — Wed, 08 Jul 2026 11:06:46 +0000

Building SiteGen AI v2: From a Website Generator to an AI Software Engineer

After migrating SiteGen AI to a more flexible AI architecture, I spent some time thinking about the future of the project.

The question I kept asking myself was simple.

"Do I really want to build another AI website generator?"

The answer was no.

There are already many tools capable of generating beautiful landing pages and portfolio websites.

If SiteGen AI was going to continue evolving, it needed a bigger purpose.

A Different Vision

Instead of generating only websites, I wanted SiteGen AI to generate complete software projects.

When developers start a new project, they don't just create an HTML file.

They create an entire application.

That application usually contains:

Frontend
Backend
Database
Authentication
REST APIs
Configuration files
Documentation
Deployment setup

Generating only the frontend solves a small part of the development process.

I wanted SiteGen AI to solve much more than that.

Thinking Like a Software Architect

I realized that code generation shouldn't be the first step.

Planning should be.

Before writing a single line of code, every software project begins with understanding the requirements.

What type of application is this?

Which technology stack should be used?

What database is appropriate?

How many user roles are required?

Which APIs should exist?

These questions are normally answered by software architects.

I wanted SiteGen AI to answer them automatically.

The New Architecture

Instead of sending one prompt to an AI model and expecting a complete application, I started designing a workflow where different parts of the project are generated independently.

The process begins by analyzing the user's requirements.

Once the project is understood, separate modules generate different parts of the application.

For example:

Project Planning
Frontend Generation
Backend Generation
Database Design
Authentication
API Development
Documentation
Deployment Configuration

Each module focuses on a single responsibility.

This makes the generated projects more organized and easier to maintain.

Why This Matters

As projects become larger, a single AI response becomes difficult to manage.

Breaking the work into smaller tasks improves consistency and allows each part of the application to be generated with more context.

It also makes future improvements much easier.

If I want to improve backend generation, I don't have to modify the frontend generation process.

Each module can evolve independently.

The Long-Term Goal

My goal is no longer to generate simple webpages.

I want SiteGen AI to become a development assistant capable of creating production-ready software projects from natural language.

A user should be able to describe an idea, and the platform should generate a complete project structure that developers can continue building upon.

This is an ambitious goal, but every new feature brings the project one step closer.

What I've Learned

One of the biggest lessons from this journey is that software architecture matters more than writing code quickly.

Good architecture allows a project to grow.

Poor architecture eventually limits what the project can become.

Building SiteGen AI has taught me much more than AI integration.

It has helped me understand project planning, modular design, scalability, and maintainability.

Looking Ahead

SiteGen AI is still evolving.

There are many challenges ahead, and many features I want to build.

In future articles, I'll share the progress of SiteGen AI v2, the technical decisions behind it, and the lessons I learn while building it in public.

This project started as a simple experiment.

Today, it has become one of the most valuable learning experiences of my software development journey.

Thank you for reading.

Migrating from Gemini API to OpenRouter: Building a More Flexible AI Platform

Bharath Kumar_30 — Wed, 08 Jul 2026 11:04:56 +0000

Migrating from Gemini API to OpenRouter: Building a More Flexible AI Platform

As SiteGen AI continued to grow, I started testing it with different types of prompts and larger projects.

The application was working well, but one issue kept interrupting development.

The AI service frequently returned quota-related errors, making it difficult to continue testing and improving the project.

At first, I assumed there was something wrong with my implementation.

After debugging the application, checking API requests, and verifying my credentials, I realized the issue wasn't in my code.

The limitation was related to the AI service configuration and usage quotas.

Why I Decided to Migrate

One lesson became very clear.

An application should never depend entirely on a single AI provider.

If the provider changes its pricing, limits requests, or introduces new restrictions, development slows down immediately.

I wanted SiteGen AI to remain flexible regardless of which AI model it used.

Instead of designing the project around one provider, I decided to redesign it around a common interface that could support multiple providers.

That decision led me to OpenRouter.

Why OpenRouter

OpenRouter provides access to multiple language models through a single API.

Instead of rewriting my backend every time I wanted to test a different model, I could simply change the model name while keeping the rest of the application unchanged.

This approach makes experimentation much easier.

Instead of being tied to one provider, SiteGen AI can evolve alongside the AI ecosystem.

Refactoring the Backend

The migration required more than replacing an API endpoint.

I reorganized the backend to separate AI communication from the rest of the application.

Instead of embedding AI logic directly inside the website generation workflow, I created a dedicated service responsible for handling AI requests.

This separation makes the codebase easier to maintain and prepares the project for future integrations.

Benefits of the Migration

After completing the migration, several improvements became immediately noticeable.

Easier model switching
Cleaner backend architecture
Better separation of responsibilities
Improved maintainability
Greater flexibility for future development

Most importantly, SiteGen AI is no longer tightly coupled to a single AI provider.

Looking Beyond Website Generation

While working on this migration, another idea started taking shape.

I realized that changing the AI provider solved only one part of the problem.

The bigger opportunity was changing what the application actually generates.

Instead of producing only HTML, CSS, and JavaScript, I wanted SiteGen AI to understand complete software requirements and generate structured projects.

That idea eventually became the foundation for SiteGen AI v2.

Lessons Learned

Building AI-powered applications isn't only about choosing the most capable language model.

Architecture matters.

Abstraction matters.

Designing software that can adapt to new technologies is often more valuable than optimizing for a single provider.

This migration reminded me that investing time in a flexible architecture always pays off in the long run.

What's Next

In the next article, I'll introduce the vision behind SiteGen AI v2 and explain why I decided to move beyond website generation toward building an AI-powered full-stack project generator.

Why HTML Generation Wasn't Enough: The Evolution of SiteGen AI

Bharath Kumar_30 — Wed, 08 Jul 2026 11:03:21 +0000

Why HTML Generation Wasn't Enough: The Evolution of SiteGen AI

After building the first version of SiteGen AI, I was excited to see websites being generated from simple prompts.

The application could generate HTML, CSS, and JavaScript based on user input. It was a great milestone because it proved that the core idea worked.

However, after testing more prompts and creating different types of websites, I started noticing a pattern.

The generated websites looked functional, but they weren't complete applications.

The Limitation

If a user asked for a portfolio website, SiteGen AI could generate a portfolio page.

If someone requested a restaurant website, it could generate a landing page.

But what happened when someone asked for something larger?

For example:

Build a Hospital Management System.

The application still generated a single webpage.

A real hospital management system requires much more than a homepage.

It needs authentication, dashboards, APIs, databases, user roles, appointment management, and many other components.

That's when I realized my application wasn't generating software.

It was only generating webpages.

The Difference Between a Website and a Software Project

A modern software project usually consists of multiple parts.

Frontend
Backend
Database
Authentication
REST APIs
Deployment configuration
Documentation

Generating only HTML, CSS, and JavaScript solves only one part of the problem.

The remaining architecture still has to be built manually.

Rethinking the Architecture

Instead of improving the HTML generator, I started thinking differently.

The first question became:

"What does the user actually want to build?"

Instead of immediately generating code, the application should first understand the project requirements.

For example, if a user asks for an e-commerce application, the system should identify that it requires:

Product management
Shopping cart
Authentication
Payment integration
Database
Admin dashboard
User dashboard

Only after understanding these requirements should the code generation begin.

This approach completely changes how the application works.

A New Direction

This realization marked the beginning of SiteGen AI v2.

The goal is no longer to generate individual webpages.

The goal is to generate complete software projects.

Instead of returning three files—

index.html
style.css
script.js

—I want SiteGen AI to generate an organized project structure with frontend, backend, database, documentation, and deployment configuration.

This is a much larger challenge, but it also makes the project far more useful.

Lessons Learned

One of the biggest lessons from building the first version is that writing code is only one part of software development.

Understanding requirements, planning architecture, and generating maintainable project structures are equally important.

The quality of an AI-generated application depends on the quality of its planning before any code is written.

What's Next

In the next article, I'll explain why I migrated from the Gemini API to OpenRouter, what challenges I faced with API quotas, and how abstracting the AI provider made the project more flexible for future development.

Thank you for reading.

Building the First Version of SiteGen AI – Turning an Idea into Reality

Bharath Kumar_30 — Wed, 08 Jul 2026 11:00:55 +0000

Building the First Version of SiteGen AI – Turning an Idea into Reality

In my previous article, I shared how the idea for SiteGen AI was born.

In this article, I want to talk about how I built the first working version of the project.

Spoiler alert...

It wasn't perfect.

But it worked.

And that's where every great project starts.

The Goal

The first version had only one objective.

A user types something like:

Build a modern portfolio website for an MCA student.

The application should automatically generate:

HTML
CSS
JavaScript

and display the result instantly.

Sounds simple.

It wasn't.

Choosing the Tech Stack

Since I'm comfortable with Python, I decided to use FastAPI for the backend.

My initial stack looked like this.

Backend

Python
FastAPI

Frontend

HTML
CSS
JavaScript

AI

Google Gemini API (initially)

Database

SQLite

I intentionally kept the first version simple.

The goal wasn't to build the perfect architecture.

The goal was to make something work.

How It Worked

The first workflow looked like this.

User Prompt

↓

FastAPI Backend

↓

Gemini API

↓

Generated HTML

↓

Browser Preview

The user entered a prompt.

The backend sent it to the AI.

The AI generated the website.

The browser rendered it immediately.

When I saw my application generate its first webpage, it felt amazing.

The First Success

One of the first prompts I tested was:

Build a portfolio website for a software developer.

Within seconds, the application generated:

HTML

CSS

JavaScript

It wasn't beautiful.

It wasn't production ready.

But it proved that the idea worked.

The Problems Started

As I continued testing, I noticed several issues.

Sometimes the generated websites looked almost identical.

Sometimes the AI ignored parts of the prompt.

Sometimes the design was too generic.

The more prompts I tested...

the more problems I discovered.

At first I thought the AI was the problem.

Later I realized the real problem was my architecture.

What I Learned

One of my biggest lessons was this:

Good AI output depends on good prompts and good system design.

Simply sending:

Build a business website

isn't enough.

The AI needs context.

It needs structure.

It needs clear instructions.

That realization completely changed how I thought about AI development.

Looking Ahead

The first version of SiteGen AI was only the beginning.

It could generate simple websites.

But my vision became much bigger.

I didn't want to build another HTML generator.

I wanted to build an AI Software Engineer.

A system capable of generating complete applications, not just webpages.

That vision became SiteGen AI v2.

I'll talk more about that in the next article.

Final Thoughts

Looking back, the first version wasn't impressive from a technical standpoint.

But it taught me one of the most important lessons in software engineering:

Start simple. Learn. Improve. Repeat.

Every feature I add today is built on top of that first working prototype.

If you're building your own AI project, don't wait until it's perfect.

Build the first version.

You'll learn far more from a working prototype than from endless planning.

Thanks for reading!

If you're also building AI applications, I'd love to hear about your journey in the comments.

Happy Coding!

How I Started Building SiteGen AI-website builder

Bharath Kumar_30 — Wed, 08 Jul 2026 10:58:23 +0000

How I Started Building SiteGen AI — My Dream AI Website Builder

Tags:

ai #python #fastapi #opensource #webdev

Introduction

Hi everyone!

I'm Bharath Kumar, an MCA student and Python developer from India.

Over the past few months, I've been learning AI, FastAPI, automation, and modern web development.

One question kept coming to my mind.

"What if anyone could build a website just by describing it?"

That simple question became my biggest side project.

I named it SiteGen AI.

The Idea

There are many AI website builders available today.

But I wanted to understand how they actually work.

Instead of using them, I decided to build my own.

The first goal was very simple.

A user types:

Build a portfolio website for a software developer.

And my application generates the website automatically.

Version 1

The first version was very basic.

It generated:

HTML
CSS
JavaScript

using AI.

Seeing my own application generate an entire webpage from a prompt was an amazing feeling.

It wasn't perfect.

But it worked.

The Challenges

As I continued developing, I started facing many problems.

Some generated websites looked generic.

Sometimes the AI ignored the prompt.

Sometimes API limits stopped development.

Instead of giving up, I treated every problem as an opportunity to improve the project.

My Goal

SiteGen AI is not just another website generator.

My long-term vision is much bigger.

I want to build an AI software engineer that can generate complete production-ready applications.

Instead of only generating HTML, I want it to create:

Frontend
Backend
Database
Authentication
APIs
Documentation
Deployment files

All from a single prompt.

Why I'm Writing This Series

I want to document my entire journey.

Not only the successful days.

But also the bugs, mistakes, failures, redesigns, and lessons learned.

Hopefully this series helps someone else who wants to build AI applications.

What's Next?

In the next blog, I'll explain the architecture behind SiteGen AI and how I built the first AI-powered website generator.

Thanks for reading!

If you're building something interesting, I'd love to hear about it.

Happy Coding!

Setting Up Docker on My Hosting Server (selfmade.lab)

Bharath Kumar_30 — Fri, 24 Apr 2026 08:09:00 +0000

Today I started setting up Docker on my hosting server as part of my project. My goal is to run PostgreSQL and backend services in containers and manage everything cleanly.

This post is a simple log of what I did today — step by step

Goal for Today

Set up Docker on my hosting server
Prepare environment for database and backend
Begin container-based development
Lab name: selfmade.lab

Step 1: Connected to My Server

First, I connected to my hosting server using SSH:

ssh root@your_server_ip

After login, I confirmed I’m inside the server.

Step 2: Installed Docker

Then I installed Docker using basic commands:

apt update
apt install docker.io -y

After installation, I started Docker:

systemctl start docker
systemctl enable docker

To check if Docker is working:

docker --version

Step 3: Tested Docker

I ran a simple test container:

docker run hello-world

This confirmed Docker is installed and running correctly.

Step 4: Started PostgreSQL Container

Next, I started my database container:

docker run -d \
--name selfmade-postgres \
-e POSTGRES_PASSWORD=1234 \
-p 5432:5432 \
postgres

Now PostgreSQL is running inside Docker.

Step 5: Opened Database Port

To allow external connection:

ufw allow 5432

Step 6: Connected Using pgAdmin

From my local system, I connected using:

Host: your_server_ip
Port: 5432
Username: postgres
Password: 1234

Connection was successful

Step 7: Planning Next Steps

Today I only completed the base setup. Next, I plan to:

Use docker-compose for better management
Add FastAPI backend
Secure database using .env
Setup domain for selfmade.lab
Add Nginx for reverse proxy

Challenges I Faced

Initial confusion with Docker setup
Understanding server vs local environment
Port access configuration

But step by step, everything started working.

What I Learned Today

Docker can be installed easily on a server
Containers simplify backend setup
PostgreSQL runs smoothly inside Docker
Remote connection using pgAdmin is very useful

Final Thoughts

Today was a strong start for my project infrastructure. Setting up Docker on my hosting server gave me more confidence to move forward with deployment.

More updates coming soon as I build selfmade.lab

From Docker Failure to PostgreSQL Success: My Real Backend Learning Experience

Bharath Kumar_30 — Wed, 01 Apr 2026 15:58:35 +0000

Hey everyone,

This is a continuation of my journey.

After struggling with PostgreSQL integration, I decided to try something new:

Docker

I thought it would make things easier.

But again… reality had other plans

Trying Docker

I installed Docker Desktop and started setup.

At first, everything looked fine.

But then…

Issues Started

I faced multiple problems:

Disk space errors
WSL not working
Installation failures
“Catastrophic failure” errors

It was frustrating.

I spent time fixing:

Environment variables
WSL updates
System settings

Still, it didn’t work smoothly.

Reality Check

At that moment, I realized:

I’m still learning
I need a simpler path

So I made a decision.

Switching Back to Local Setup

Instead of forcing Docker, I went back to:

Local PostgreSQL setup

This time, I focused step by step:

Installed PostgreSQL properly
Opened pgAdmin
Created database
Ran my schema

Finally… Success!

Then came the best moment:

Tables created successfully
Database working
Connection from Python working

Everything finally clicked

What I Learned

Tools are important, but timing matters
Docker is powerful, but not always beginner-friendly
Simplicity wins when learning

My Growth

Today I:

Understood PostgreSQL deeply
Integrated it into my project
Learned from real errors
Built confidence

Final Thought

It’s okay to fail.
It’s okay to change direction.
What matters is moving forward.

Today, I didn’t just build a feature.
I built experience.

And that’s what truly matters

From SQLite to PostgreSQL: My First Integration Attempt (Failures, Learning & Direction Change)

Bharath Kumar_30 — Wed, 01 Apr 2026 15:55:39 +0000

Hey everyone,

Today was one of those days where I didn’t just code… I struggled, failed, learned, and improved.

I started with a clear goal:

Replace SQLite with PostgreSQL
Store all my project data in a real database

Sounds simple right?
But the journey had some twists.

My Initial Plan

My project was using SQLite. It was easy, but not scalable.

So I decided:

Remove SQLite completely
Integrate PostgreSQL
Use .env for security
Store everything in database

Step 1: Database Setup

I installed PostgreSQL and opened pgAdmin.

Then I:

Created a database → social_media_db
Designed tables using DDL
Ran SQL successfully

That moment felt good — my database was ready.

Step 2: Integration Attempt

Next, I started integrating it into my code.

Removed sqlite3
Added psycopg2
Created a db.py connection file
Updated queries (? → %s)

Problems I Faced

This is where things got real.

Connection errors
Query syntax mistakes
Forgot commit()
Small bugs everywhere

At first, I thought:

“Why is this so hard?”

But slowly I understood…

What I Learned

SQLite and PostgreSQL are NOT the same
Small syntax changes matter
Database connection must be handled properly
Errors are part of learning

Change in Thinking

At one point, I felt:

“Maybe I should try a better setup…”

That’s when I started thinking about Docker.

Because:

It gives clean environment
Easy to manage services
Industry-level approach

My Realization

Today I understood something important:

Learning backend is not just coding…
It’s about understanding systems.

My Takeaway

I successfully designed and created my PostgreSQL database
I started integrating it into my project
I faced real-world problems
And I didn’t give up

Final Thought

Today was not perfect.
But it was real.

Failures taught me more than success.

And tomorrow… I come back stronger

# Setting Up PostgreSQL Locally and Connecting It to My Project (Beginner Journey)

Bharath Kumar_30 — Wed, 25 Mar 2026 17:44:50 +0000

Hey everyone,

Today I worked on something very important in backend development — setting up a database and connecting it to my project.

Until now, I was mainly focused on coding features. But today I understood that without a proper database setup, a project is not complete.

So I decided to set up PostgreSQL locally and integrate it step by step.

What I focused on today

My main goal was to:

Set up PostgreSQL locally
Create a database
Configure environment variables
Connect database using Python
Execute my database schema

Step 1: Creating the database

After installing PostgreSQL, I created a database for my project:

```sql id="y2y3g1"
CREATE DATABASE social_media_db;




This is where all my project data will be stored.

---

##  Step 2: Managing credentials using .env

Instead of writing database credentials directly in code, I used a `.env` file.



```env id="3hkgmq"
DB_HOST=localhost
DB_PORT=5432
DB_NAME=social_media_db
DB_USER=postgres
DB_PASSWORD=your_password

This made my setup cleaner and more secure.

Step 3: Connecting PostgreSQL with Python

To connect my project with the database, I used psycopg2.

```python id="s6x3jm"
import os
import psycopg2
from dotenv import load_dotenv

load_dotenv()

conn = psycopg2.connect(
host=os.getenv("DB_HOST"),
port=os.getenv("DB_PORT"),
dbname=os.getenv("DB_NAME"),
user=os.getenv("DB_USER"),
password=os.getenv("DB_PASSWORD")
)

print("Database connected successfully!")




Seeing this connection work was a great moment.

---

##  Step 4: Executing my database design

Earlier, I had designed my database structure using DDL.

Today, I executed that design in PostgreSQL.

My schema includes:

* Users table
* Platforms table
* Credentials table
* Posts table
* Post logs table

Now my design is no longer just an idea — it’s a working database.

---

##  Step 5: Updating from SQLite to PostgreSQL

My project was previously using SQLite.

So I started adapting it to PostgreSQL.

I learned small but important differences:

* `AUTOINCREMENT` → `SERIAL`
* `DATETIME` → `TIMESTAMP`

These changes helped me understand how different databases work.

---

##  What I learned today

Today was not about writing a lot of code.

It was about understanding how things actually work behind the scenes.

I learned that:

* Database setup is a core part of backend development
* Environment variables are important for security
* Designing and executing a schema are two different steps
* Migrating between databases requires attention to detail

---

##  My takeaway

I feel more confident now working with databases.

Instead of just using default setups, I now understand how to:

* Create and manage databases
* Connect them to applications
* Structure data properly

---

##  Final thought

Every day I’m learning something new.

Some days it’s coding,
Some days it’s understanding systems.

Both are equally important.

This is just one more step in my journey — more learning ahead 🚀

Designing My First Real Database Schema with DDL (PostgreSQL)

Bharath Kumar_30 — Wed, 25 Mar 2026 06:12:06 +0000

Hey everyone,

Today was a different kind of learning day for me.

Instead of writing APIs or working on frontend, I focused on something very important in backend development — database design using DDL commands.

At first, I thought database means just creating tables. But today I understood that it’s much more than that.

What I worked on today

My guide asked me to:

Design the database structure
Write DDL commands (CREATE TABLE)
Apply constraints (for data integrity)
Think about optimization

So I didn’t just create tables — I designed a proper structure for my project.

What is DDL?

DDL stands for Data Definition Language

It is used to define the structure of the database.

Some common commands:

CREATE TABLE
ALTER TABLE
DROP TABLE

Today, I mainly worked with CREATE TABLE.

My Database Design (Project Based)

My project is about social media automation, so I designed tables based on real use cases.

Users Table

Stores user details like username, email, and password.

Important:

Email is unique
Password is stored securely

Platforms Table

Instead of hardcoding platforms like Telegram or Twitter, I created a separate table.

Benefit:

Easy to add new platforms later
No need to change code

Credentials Table

This table connects users and platforms.

Key points:

Stores API keys (in encrypted format)
Prevents duplicate connections using UNIQUE constraint
Uses ON DELETE CASCADE

Posts Table

Stores content that users want to post.

Includes:

Content
Status (pending, sent, failed)

Post Logs Table

This was a very important part.

One post can go to multiple platforms
Each platform result is stored separately

Example:

Telegram → Success
Twitter → Failed

So logs help track everything clearly.

Data Integrity (Important Learning)

Today I understood that just creating tables is not enough.

We must protect the data.

I used:

PRIMARY KEY → unique identification
FOREIGN KEY → relationships
UNIQUE → no duplicates
NOT NULL → required fields
CHECK → restrict valid values
ON DELETE CASCADE → automatic cleanup

Optimization (Small but powerful)

I also added indexes.

Why?

Because:

Faster queries
Better performance

What I realized today

Earlier, I used to think:

“Database = just store data”

Now I understand:

“Database design = foundation of the entire application”

If the structure is wrong, everything becomes difficult later.

My takeaway

Think before creating tables
Design based on real use cases
Always include constraints
Plan for scalability
Keep it clean and structured

Final thought

Today I didn’t just write SQL.

I learned how to think like a backend developer.

Still learning, still improving — one step at a time.

More updates coming soon