You've got a brilliant idea. You've gathered your friends - maybe 10-20 people who can code. Everyone's excited, the energy is incredible, and you're ready to build something amazing.

Then someone asks: "How should we actually build this?"

Suddenly you're confused. Should you use microservices? Do you need fancy cloud architecture? What even is Kubernetes, and do you need it?

Here's the truth: You're overthinking it.

Let's talk about the simplest way to turn your idea into reality.

The Big Question: Simple or Complicated?

Q: Everyone talks about splitting apps into tiny pieces (microservices). Is that what we need?

Imagine you're building a house. One contractor says: "First, you need to dig the foundation yourself. Then source all the materials. Then figure out the plumbing. Then the electrical. I'll supervise."

Another contractor says: "I've built 10,000 houses. I know exactly what you need. I'll handle the foundation, plumbing, electrical, everything. You just tell me how many bedrooms you want."

Which sounds easier?

Microservices are like hiring 10 separate contractors. Big companies like Google need this because they have thousands of programmers who can't all work on the same thing.

But you're not Google. You're a small team trying to build something people will love.

Q: But won't we need to scale eventually?

Yes, eventually. But here's what most people miss: GitHub handled millions of developers with a Rails monolith for years. Shopify processes billions in transactions on Rails. Basecamp has run profitably for decades without breaking into microservices.

The question isn't "will we need to scale?" It's "what's preventing us from building the product right now?"

Q: So what's the alternative?

A well-crafted monolith. And specifically, a Rails monolith.

What is Rails? Why Rails? Why Now?

Q: What is Rails? I haven't heard of this one.

Rails is a web application framework written in Ruby. Ruby is a programming language similar to Python or JavaScript. David Heinemeier Hansson (DHH) created the Rails framework to make web development faster and more enjoyable.

The Rails Philosophy: Two Core Principles

1. Convention Over Configuration

2. Don't Repeat Yourself (DRY)

Q: What does "Convention Over Configuration" actually mean in practice?

Let's get concrete. In many frameworks, before you can save a user to the database, you need to install a database driver, write configuration files connecting to the database, define your database schema manually, write queries or ORM mappings, set up connection pools, and configure transaction handling.

In Rails, you type:

rails generate model User name:string email:string

rails db:migrate

Done. You now have a User model that can save to the database. Rails assumed you want PostgreSQL or MySQL (you can change it), created the database table, set up all connections, and gave you methods like User.create(name: "Alice", email: "alice@example.com").

That's convention over configuration. Rails makes smart decisions so you don't have to.

Q: Give me another example.

Sure. Let's say you want to send password reset emails. In most frameworks, you'd need to choose an email library, configure SMTP settings, create email templates, write the logic to generate tokens, set up background job processing, and handle delivery failures.

In Rails, you run:

rails generate mailer UserMailer password_reset

Rails creates a complete email system. You write your email template in HTML and text versions. The mailer class handles everything. Want to send it in the background so your web request doesn't wait? Change UserMailer.password_reset(user).deliver_now to deliver_later. That's it.

Rails has been doing this for 20 years. It knows what you need.

Q: How does Rails keep code DRY?

"Don't Repeat Yourself (DRY)," which is a trademark concept for developers. You don't need to rewrite the same code again and again. Write it once in one place and reuse it throughout your application. It's a basic principle of software development, and Rails makes it incredibly easy.

Rails provides several tools for the DRY principle. Helpers extract logic from your views - as the name suggests, views are what's shown to the end user, and helpers keep them clean and focused. Concerns extract common controller logic into controller concerns and common model logic into model concerns. This promotes code reuse and keeps your codebase maintainable.

When you use these tools effectively, you avoid duplicating code across your application.

The Companies That Bet Big on Rails

Q: Who actually uses Rails? I hear it's outdated.

Let's look at the numbers:

GitHub - 100+ million developers, billions of repositories. Still Rails. They're not a small startup anymore - they're Microsoft-owned and processing some of the most critical infrastructure in software development.

Shopify - Over $200 billion in total sales processed. Rails handles Black Friday traffic spikes that would crush most systems. They've proven you can scale a monolith to handle millions of concurrent users.

Airbnb - Revolutionized an entire industry with Rails. They only started extracting services after they had millions of listings and needed specialized search functionality.

Basecamp - Built by DHH himself, profitable for 20+ years, never needed to break into microservices. They handle millions of users with a small team.

Q: So these companies never moved to microservices?

Some extracted specific services when they had a concrete reason. Airbnb pulled out search because Elasticsearch required specialized knowledge. GitHub extracted some Git operations for performance. But their core applications? Still monolithic Rails.

The key insight: They started with monoliths and only broke things apart when they had specific, measurable problems that required it. They didn't start with complexity.

Inside a Rails Application

Q: What does Rails actually give me when I start a project?

Run rails new my_startup and you get a complete application structure:

The app/ directory - Where you'll spend 90% of your time:

• models/ - Your business data and logic

• controllers/ - Handle HTTP requests

• views/ - HTML, JSON, or XML responses

• jobs/ - Background tasks

• mailers/ - Email templates and logic

• channels/ - Real-time WebSocket features

• assets/ - CSS, JavaScript, images

The config/ directory - Database, routes, environment settings, all configured intelligently by default.

The db/ directory - Database migrations tracked in code, so your entire team stays in sync.

The test/ directory - Because Rails believes good code has tests.

The Power of Rails Generators

Q: What is a generator?

A generator is a Rails tool that automatically creates code following Rails conventions. It eliminates thousands of tiny decisions that drain your energy. Because every generator follows the same conventions, code from one Rails app looks like code from another. New team members onboard faster, and you can move between projects without relearning the structure.

Q: What can generators create?

Everything. Here's a sampling:

Controllers: rails generate controller Products index show new create - Creates the controller, view templates, route entries, and test files.

Models: rails generate model Product name:string price:decimal inventory:integer - Creates the model, database migration, and tests. Automatically sets up the database table with correct data types.

Scaffolds: rails generate scaffold Article title:string body:text published:boolean - Creates everything - model, migration, controller, views, routes, tests. A complete CRUD interface in one command.

Mailers: rails generate mailer Order confirmation shipping_notification - Creates email templates and mailer classes.

Jobs: rails generate job ProcessPayment - Creates a background job class ready for Sidekiq or other job processors.

Q: Doesn't this generated code lead to bloat?

Only if you leave what you don't need. Experienced Rails developers generate the structure, then delete or modify what doesn't fit. The point is to get 80% of the boilerplate instantly, then customize the remaining 20%.

Everything You Need, Batteries Included

Q: What about features beyond basic CRUD?

This is where Rails truly shines. Most frameworks give you the basics. Rails gives you production-grade features:

Caching - Out of the box, Rails supports fragment caching, page caching, and Russian doll caching. Wrap slow operations in Rails.cache.fetch and Rails handles the rest. Your database query that takes 500ms? Now 5ms from cache.

File Uploads - Active Storage handles file uploads to your disk, Amazon S3, Google Cloud, or Azure. It processes image variants automatically. Upload a 5MB photo, Rails can generate thumbnails, handle responsive images, and serve them efficiently.

Internationalization (i18n) - Building for multiple countries? Rails has translation management built-in. Store text in YAML files, Rails handles plural forms, date formatting, and number formatting for every locale.

Action Cable - Real-time features without the complexity. Chat applications, live notifications, collaborative editing - WebSockets are first-class citizens in Rails.

Background Jobs - Send 10,000 welcome emails? Process video uploads? Rails queues jobs through Active Job, which works with Sidekiq, Resque, or other processors.

Q: What about security?

Rails takes security seriously with built-in protections:

Brakeman - Run bin/brakeman and get a security audit. It scans for SQL injection, cross-site scripting, unsafe redirects, and dozens of other vulnerabilities.

CSRF Protection - Every form automatically includes CSRF tokens. Rails rejects form submissions that don't have valid tokens.

Parameter Filtering - Passwords and sensitive data automatically filtered from logs.

SQL Injection Prevention - Active Record parameterizes queries. Writing User.where("email = ?", params[:email]) is safe by default.

Q: How does Rails help maintain code quality?

RuboCop - Run bin/rubocop and Rails checks your code style. Inconsistent indentation? Extra whitespace? Long methods? RuboCop flags them. Better yet, run bin/rubocop -a and it auto-corrects most issues.

Built-in Testing - Every generator creates test files. Rails encourages test-driven development from day one. Run rails test to verify everything works.

Database Migrations - Changes to your database schema are versioned. Every migration is timestamped. Rolling back a bad deploy? Just roll back migrations too. Your entire team's databases stay synchronized.

TLDR;

Stop overcomplicating your startup's tech stack. Rails gives you a complete, production-ready framework that powers GitHub, Shopify, Airbnb, and Basecamp. With convention over configuration, you'll spend less time on infrastructure decisions and more time building features your users will love. Start with a monolith, ship fast, and scale when you actually need to - not because someone told you microservices are "the future." Rails has 20 years of battle-tested wisdom baked in. Use it.

Let's Connect

Found this helpful? Connect with me on LinkedIn to continue the conversation and share your experiences with Rails or monolithic architecture. What's your take - monolith first or microservices from day one?

https://www.linkedin.com/in/manask-pradhan/

contact@devmanas.in

Before getting into the story, let me remind you of something.
When computers first became a thing, people were scared. They thought it would take away all the jobs. And yes, it did replace some—like the clerk who used only pen and paper. But fast forward to today, and look around: computers have created way more jobs than they replaced. That same clerk? He probably learned how to use Excel and got even better at his job.

Now, here we are again. Same fear, new tech. This time, it’s AI.

So... Is AI Going to Steal Our Jobs?

Let’s be real. This is the question almost every tech student is thinking about lately.

With headlines shouting about layoffs at Google, Microsoft, Meta, Apple, TCS, and more, it’s hard not to stress.
A report by Goldman Sachs even estimates that 300 million jobs could be displaced globally by 2030.
And already, 25% of routine tasks are being automated.
According to Statista, 46% of office/admin work is highly vulnerable to AI.

Sounds intense, right?

On top of that, AI can already automate 70% of workforce tasks, says McKinsey.
And 23% of existing roles are expected to change completely by 2027.
If you’re aiming for an entry-level job, it’s natural to feel nervous. That’s where the pressure hits first.

But Hold On — It’s Not All Doom and Gloom

Before we spiral into panic, here’s the flip side: AI is also creating jobs. A lot of them.

In fact, a recent survey suggests that 170 million new jobs will pop up globally this decade, even while AI is automating so many other roles. And guess what? 69 million new positions will emerge, even as 92 million disappear – so that’s a net gain of 14 million jobs in the next five years. Seems like there’s still hope, right?

So yeah, AI will change the game—but it doesn’t mean we’re out of the game.

The Real Gamechanger: People Who Know AI

It’s not about competing against AI—it’s about working with it.

Magnus Grimeland, venture capitalist and founder of Antler, said:

“The demand for great software engineers will only increase in the coming decades.”

Why? Because even the smartest AI can mess up. That’s where you come in—to clean up, guide, and make better decisions. It still needs us humans to fix things.

Mark Zuckerberg, CEO of Meta, put it this way:

“AI allows small startups to do what only large teams could do before.”

That’s huge. With just a small team and the right AI tools, you can launch products that once needed full departments.

Even big companies are taking note. JP Morgan is training 200,000+ employees on AI tools because they see AI as a must-have skill, not a fancy add-on.

And guess what?
70% of companies are expected to be using AI by 2030.
Not knowing how to use it might be the new “not knowing how to use email.”

It’s Not AI vs You — It’s AI with You

This might be the most important line in this whole article:

It’s not AI vs YOU — it’s AI + YOU.

Instead of being scared, look at AI like your teammate. It can handle all the boring, repeat work, and leave you with the creative, strategic stuff.

Jensen Huang, CEO of NVIDIA, put it perfectly:

“You won’t lose your job to AI, but to someone who uses it.”

And Bill Gates backed that up too. He said:

“AI will free us up to do things that software never helped with before—like teaching, caring for patients, and supporting the elderly.”

So basically, AI isn’t stealing your future. It’s reshaping it.

Heard About Vibe Coding?

Let’s take a quick detour to talk about something buzzing in the dev world lately: vibe coding (or vibecoding).

No, it’s not a programming language—it’s more of a mindset and approach.

It’s like coding based on your gut, your flow—the vibe of the project. You don’t overthink every line. You just start building. It's about being experimental and going with what feels right.

But here's the twist...

According to Wikipedia, vibe coding also refers to a new AI-driven way of programming, where you describe your problem in natural language (like a prompt), and a large language model (LLM) like ChatGPT writes the code for you.

The term was introduced by Andrej Karpathy (former OpenAI co-founder and Tesla AI lead) in February 2025, who said:

“It’s not really coding — I just see things, say things, run things, and copy-paste things, and it mostly works.”

He uses this method for weekend projects, calling it “conversational coding” — using voice prompts and letting AI do the typing.

Now, vibe coding isn’t perfect. Yeah, it can get messy. Bugs can creep in. And in big projects, things can break. But for small hacks, MVPs, or personal stuff? It helps you stay in the zone and avoid burnout.

So whether you’re vibing with your keyboard or vibing with an AI, next time you’re stuck, don’t overthink it — just vibe code it.

What You Can Actually Do About All This

Alright, so what now?

Here’s how you future-proof yourself in the age of AI:

• Learn AI tools – Not just ChatGPT, but tools that fit your field.

• Build hybrid skills – Pair your tech knowledge with creativity, communication, and problem-solving.

• Stay curious and open-minded – Like Anima Anandkumar, Director of ML at NVIDIA, says:

  “Don’t fear AI. Focus on the things AI can’t do—like solving new, hard problems.”

Most importantly: don’t just follow trends. Adapt to them.

Marketing, customer support, analytics—all being reshaped by AI.
But fields that need human judgment—like design, writing, education, or mental health—are still super relevant.

TL;DR – The Future of Jobs Is Still Yours

AI’s not here to destroy us. It’s here to change how we work.

So here’s what you need to ask yourself:

• Will you let AI handle the repetitive stuff while you level up?

• Will you use it to build smarter, faster, and more creatively?

• Will you adapt—or be replaced by someone who does?

Because in the end, the future of work won’t be written by AI.

It’ll be written by people who know how to use it.

So next time someone says, “Will AI take your job?”
You say:

“Only if I ignore it.”

All images proudly brought to you by AI, approved by vibes.

AI’s not here to take over—it’s here to work with us! You can read my other article over on Hashnode (https://pkmanas22.hashnode.dev/). Let’s connect on Twitter or LinkedIn (I’m pkmanas22 everywhere) and share thoughts or questions. And if you enjoyed this piece, leave me a comment or give me a little love on Hashnode!

You might be surprised by this subtitle, but it’s true: in JavaScript, everything is an object—either directly an object or it inherits from Object. After learning some jargon like __proto__, prototype, we circle back to this core concept. So, let’s start with the basics: What are Prototypes?

What is a Prototype?

A prototype is the mechanism by which JavaScript objects inherit properties from one another. Every object has some built-in properties—these come from its prototype.

const arr = [1, 2, 3, 4, 5];

const user = {
    name: "Manas"
}

In the code above, we created an array that inherits from the Array prototype. This means we can access methods like map, filter, sort, reverse, etc., even though they weren’t explicitly declared. Similarly, the user object also inherits from JavaScript’s default Object.

JavaScript also has a typeof operator, which is a unary operator (takes only one operand). It's used to determine the type of a variable.

console.log(typeof arr)    // object
console.log(typeof user)    // object

When we access user. (user dot) in editor, we’ll notice more properties than just name. These additional properties come from the Object prototype.

Prototype Chaining

Earlier, we explored prototypes. The process by which inheritance flows is called the prototype chain.

Take the array example again. The variable arr inherits properties from the Array class, which itself inherits from the Object class. Eventually, this chain ends at null.

This hierarchical lookup is called the prototype chain—a term that sounds complex but is simple in practice.

You can try this with arrays or regular objects. Keep inspecting the prototype until you reach null—that’s the end of the chain.

__proto__ vs prototype vs Object.getPrototypeOf()

1. __proto__

   Used to access or set the internal [[Prototype]] of an object.
   Syntax: arr.__proto__

2. prototype

   Used as a blueprint for creating objects (usually with constructor functions or classes).
   Syntax: Array.prototype

3. Object.getPrototypeOf( )

   Used to retrieve the prototype of a specific object.
   Syntax: Object.getPrototypeOf(arr)

All three methods help you access or understand the prototype chain—but they serve different purposes.

Why Is Everything an Object in JS?

Now that you understand __proto__, you can better appreciate that everything in JavaScript, even primitives like strings and numbers, inherit from Object—either directly or through their respective wrappers.

Shadowing Properties (Overriding Inherited Properties)

const date = new Date();

console.log(date.getFullYear())     // 2025;

date.getFullYear = () => "Hijacked";

console.log(date.getFullYear())    // Hijacked

In the code above, we override the built-in getFullYear() method of the Date object. Initially, it returns the current year (2025), but after shadowing, it returns "Hijacked".

How does this work?

• First, JavaScript checks if the property exists on the object itself.

• If not, it looks up the prototype chain.

• If still not found, it returns undefined.

const obj = {
    name: "Manas",
    age: 21,
    greetings () {
        console.log("Good morning");
    }
}

When you type obj. in your editor, you’ll see your own properties and some inherited from Object. You can override any inherited method, which is what shadowing means.

Pre-ES6 Prototypes and Inheritance

Initially, JavaScript didn’t have classes. The class keyword was introduced in ES6. Before that, developers used constructor functions and prototypes for object creation.

const userA = {
    fname: "Manas",
    lname: "Pradhan",
    fullName () {
        return `${this.fname} ${this.lname}`;
    }
}

const userB = {
    fname: "John",
    lname: "Doe"
}

console.log(userA.fullName())    // "Manas Pradhan"
console.log(userB.fullName())    // Uncaught TypeError: userB.fullName is not a function

In these two objects, we have to maintain the coding principle DRY (Don’t Repeat Yourself). Instead of writing again, we can add the below line.

userB.__proto__ = userA;

console.log(userA.fullName())    // "Manas Pradhan"
console.log(userB.fullName())    // John Doe

But this approach overrides the original prototype chain. Now userB inherits from userA directly and loses the default Object prototype.

ES6 Classes and Constructors

When we use the class keyword and create instances using new, the memory and prototype relationships look something like this:

• userA and userB are stored in the stack, holding references to the actual objects in the heap.

• The heap stores the object instances created using the User class.

• These instances have their own properties (fname, lname) and link back to shared methods (like getFullName()).

• userA.__proto__ points to User.prototype.

  You can see this includes the constructor: class User and the method getFullName().

• User.prototype.__proto__ points to Object.prototype, which includes built-in methods like toString, hasOwnProperty, etc.

Finally, Object.prototype.__proto__ is null—this ends the chain.

userA → User.prototype → Object.prototype → null

Conclusion

Understanding prototypes gives you deep insight into how JavaScript works under the hood. Whether you're debugging tricky inheritance bugs or explaining concepts in an interview, mastering prototypes is a powerful skill.
Now, open your browser console and explore the prototype chain yourself — it’s the best way to make it stick! 💻✨

Thanks for reading till the end!
I hope this helped you truly understand how prototypes work in JavaScript.
If you found this useful, feel free to share it or drop your thoughts in the comments — happy coding! 🚀