What Is a Tech Stack? A Beginner's Guide to Building Your First Web Application Without Following the Hype

You've decided to build your first web application. Perhaps it's a school management system, a booking platform, an inventory tool, or an idea you've been thinking about for years.

You open ChatGPT, Gemini, or another AI coding assistant and ask a simple question: What technologies should I use to build my application?

Within seconds, you're presented with recommendations: React, Next.js, Node.js, PostgreSQL, Supabase, Prisma, Redis, Docker, and perhaps Kubernetes.

Suddenly, an exciting idea feels like a complicated engineering project.

But here's something worth understanding before writing your first line of code: you don't need every popular technology to build a reliable application. You need to understand what you're building, what each technology does, and why your application needs it.

Let's explore how technology stacks work, the different options available, and what we've learned from two real applications: Lyenk Insights Engine and Mietric ERP.

What exactly is a tech stack?

A technology stack, commonly called a tech stack, is the collection of technologies used to build, operate, and maintain a software application.

Think about a school attendance system. Teachers need to log in, register attendance, view student records, and generate reports. Although they interact with a single application, several technologies work together behind the scenes.

The frontend provides the interface teachers see. The backend processes requests and applies rules. The database stores attendance records. The hosting infrastructure makes the application accessible online. Other services may handle authentication, notifications, and background tasks.

Together, these technologies form the application's tech stack.

A tech stack is not the same as software architecture. The stack tells us which technologies are used. Architecture explains how those technologies are organised, connected, and operated.

That distinction matters because two applications can use the same frameworks and database while having very different capabilities, costs, and maintenance requirements.

Understanding the main components of a web application

Most modern web applications share several fundamental components, regardless of their size or purpose.

Frontend: What people interact with

The frontend is the visual and interactive part of an application. It includes dashboards, navigation menus, forms, buttons, and other elements visible in a browser.

HTML provides structure, CSS controls appearance, and JavaScript enables interactive behaviour. Frameworks and libraries such as React, Vue, Angular, and Svelte help developers build more sophisticated interfaces.

If a teacher opens a dashboard to mark students present or absent, that dashboard is part of the frontend.

Backend: Where application logic happens

The backend handles operations that should happen on the server rather than inside the user's browser.

It can validate attendance submissions, check permissions, calculate reports, communicate with databases, and integrate with external services.

Common backend technologies include Node.js with Express, Python with Django or FastAPI, PHP with Laravel, Java with Spring Boot, and Ruby on Rails.

Some frameworks, including Next.js, support both frontend rendering and backend operations within one application.

Database: Where information lives

An application needs a reliable place to store information that must remain available after a user closes their browser.

Popular databases include PostgreSQL, MySQL, MongoDB, and SQLite.

For applications with strongly related data, such as students, classes, attendance records, fees, and teachers, a relational database like PostgreSQL can be a practical choice.

The database is also where good data modelling becomes important. Choosing a popular database will not compensate for poorly designed relationships or unreliable data handling.

Hosting and infrastructure: Where everything runs

An application must run somewhere. That might be a managed cloud platform, a virtual private server (VPS), or infrastructure operated by a larger organisation.

Services such as Vercel, Azure, AWS, Google Cloud, and various VPS providers offer different approaches to hosting.

Infrastructure also involves deployment, security, backups, monitoring, and keeping the application available.

A simple web application may need very little infrastructure. A system handling sensitive records, integrations, and thousands of daily operations requires more planning.

Background processing: Work that doesn't need to happen immediately

Imagine generating a detailed annual attendance report containing thousands of records.

Should a teacher keep waiting while the application processes everything, or should the system prepare the report separately and notify them when it's ready?

That's where background jobs and workers become useful.

Technologies such as pg-boss, BullMQ, Celery, and other queue systems allow certain tasks to be processed outside the immediate web request.

These tools don't eliminate processing costs. They help organise workloads, improve responsiveness, and make long-running operations easier to manage.

Which technology stacks are commonly used?

There isn't one universal tech stack. Over time, developers have established common combinations of technologies that work well together.

These are illustrative combinations, not rigid recipes. A developer can replace individual components depending on requirements.

According to the 2026 Stack Overflow Developer Survey, Node.js and React remain among the most widely used web technologies reported by respondents. But popularity tells us what developers use, not necessarily which technology is most appropriate for a particular project.

What technologies do major companies use?

It's tempting to believe that large technology companies must use the newest or most complex architectures.

Their engineering stories often tell a more interesting story.

GitHub has publicly documented how Ruby on Rails powers its core web application. Shopify's engineering team has also written extensively about its Ruby on Rails monolith and the architectural changes required to manage complexity as the business grew.

These examples do not mean Rails powers every component of either company. They demonstrate something more useful: established technologies can remain central to successful platforms when teams understand how to maintain and evolve them.

The lesson isn't to copy Shopify or GitHub. It's to recognise that good engineering is about continuously solving real problems, rather than constantly changing technologies to follow trends.

Inside Lyenk Insights Engine: A React and Express approach

Let's bring this closer to a real application.

Lyenk Insights Engine is a customer feedback and insights platform that helps businesses collect, organise, and understand customer experiences.

Its core technologies include React, TypeScript, Vite, Node.js, Express, PostgreSQL, and pg-boss. Google Gemini supports AI-assisted sentiment analysis.

The public-facing Lyenk website uses a separate, simpler static website architecture. The interactive Insights Engine operates as a full-stack web application.

Why is that interesting?

Because a public website and a business application don't necessarily need identical infrastructure.

The marketing website primarily presents information. The Insights Engine must process submissions, manage records, generate reports, and communicate with external services.

The frontend and backend are also clearly separated. React provides the interface, while Express handles application APIs and communicates with PostgreSQL.

Earlier versions of the project used Supabase, a Backend-as-a-Service platform. The application subsequently evolved toward a self-managed PostgreSQL database and custom backend.

That transition illustrates an important architectural choice: managed services can accelerate development, while operating your own backend provides greater direct control but also increases maintenance responsibilities.

Neither approach is automatically better.

Inside Mietric ERP: A different application, different requirements

Now consider Mietric ERP, an integrated management platform designed for NGOs, social enterprises, and other mission-driven organisations.

Unlike a focused feedback platform, an ERP connects multiple operational functions. These may include fundraising, grants, finance, procurement, fleet management, assets, human resources, and monitoring and evaluation.

These areas involve related records, permissions, reports, approvals, and business processes.

Mietric uses Next.js, React, TypeScript, PostgreSQL, Prisma ORM, and pg-boss. It also integrates Payload CMS for content management and uses a modular monolith architecture.

A modular monolith means different business functions are organised into distinct modules within a shared application, rather than being deployed as numerous independent microservices.

This allows the system to maintain clear functional boundaries without immediately introducing the infrastructure complexity of a distributed architecture.

Mietric also uses Next.js Server Components and server-side application logic. This allows suitable operations to happen close to the database, while interactive features continue to use browser-side JavaScript when needed.

The important difference isn't that Next.js is universally better than React with Express. Next.js itself uses React.

The difference is how each application organises its responsibilities.

For Mietric, integrating related business functions within one structured application is a reasonable architectural approach. For Lyenk, a separate React frontend and Express backend provides a different model for organising a more focused platform.

Both choices can be valid.

An interesting similarity: Why both applications use PostgreSQL and pg-boss

Despite their architectural differences, Lyenk and Mietric share an important decision.

Both use PostgreSQL for relational data and pg-boss for background processing.

pg-boss stores and manages background jobs using PostgreSQL. Applications can use it to schedule work, retry failed tasks, and process operations separately from immediate user requests.

This matters because developers are often introduced to Redis as though every application needs it.

Redis is a valuable technology. It can support caching, fast data access, message delivery, and queue-processing architectures. But whether an application needs Redis depends on the actual problem.

If an application already uses PostgreSQL and requires a manageable number of durable background jobs, pg-boss may provide the necessary functionality without another datastore to operate.

On the other hand, a system with demanding caching requirements, specialised real-time workloads, or a queue architecture suited to Redis may benefit from it.

Background workers also still consume CPU, memory, and database resources. Moving work into a queue does not make the work disappear.

The question should never be whether Redis or pg-boss is more fashionable. It should be which approach meets the application's workload, reliability, and operational requirements.

Managed backends versus self-hosted infrastructure

For someone building their first application, this is one of the most important choices.

Managed backend platforms such as Supabase and Firebase provide services that might otherwise require separate development and administration.

Supabase, for example, offers PostgreSQL alongside authentication, storage, APIs, and other capabilities. Firebase provides managed services including authentication, databases, and application hosting.

These tools can be especially useful when a developer wants to focus on building functionality rather than administering infrastructure.

Self-hosting provides another approach.

By operating your application and database on infrastructure you manage, you can gain more direct control over configuration, deployment, and service selection.

But control comes with responsibility. You must consider patching, backups, access management, monitoring, recovery, and the time required to maintain the environment.

Self-hosting is not automatically cheaper, safer, or more scalable. Managed hosting is not automatically more restrictive or expensive.

The right choice depends on the resources, expertise, and operational requirements of the project.

What should you do when AI recommends a tech stack?

AI coding assistants have made software development more accessible. You can describe an idea, ask technical questions, generate code, and explore architecture options without starting from a blank page.

That's exciting, especially for someone building their first application.

However, an AI-generated recommendation should be treated as a proposal to examine, not an architectural decision that has already been validated.

An assistant might suggest Next.js, Prisma, Supabase, Redis, Docker, and several additional services. Individually, these technologies can be excellent. Together, they may introduce responsibilities your first version doesn't need.

The 2026 Stack Overflow Developer Survey offers an interesting perspective: 48% of respondents reported trusting AI output when they could easily verify it, while only about 7% trusted it with important work decisions.

That reinforces a useful habit: ask AI to explain its recommendations and challenge them against your actual requirements.

For example, rather than asking:

What's the best tech stack for a school management system?

Try asking:

I'm building a school management system for one school, initially serving 300 students and 20 staff members. It needs attendance tracking, fee records, role-based access, and downloadable reports. I have a limited hosting budget and will maintain the system myself. Compare three suitable tech stacks. Explain their costs, operational complexity, security responsibilities, and trade-offs. Do not recommend Redis, Kubernetes, or microservices unless you can justify their necessity.

The second question gives the AI something meaningful to evaluate.

It also encourages the developer to think about the system before deciding which technologies should power it.

How do you choose the right tech stack for your first application?

Start with the problem, not the technology.

Write down what your application needs to do, who will use it, what information it must store, and which actions are genuinely important.

Then evaluate your options against five practical considerations:

1. Application requirements: What must the first version accomplish?
2. Your technical capacity: Can you understand, develop, and maintain the selected technologies?
3. Operational costs: What will hosting, third-party services, backups, and maintenance require?
4. Security and reliability: What data must be protected, and how important is continuous availability?
5. Future growth: Can the architecture evolve without introducing unnecessary complexity today?

A simple application that works reliably and can be maintained is more valuable than an elaborate architecture that nobody fully understands.

You can introduce additional technologies when there is evidence that the existing approach no longer meets your needs.

That is not underengineering. It is making deliberate engineering decisions.

Frequently asked questions about tech stacks

What is the best tech stack for beginners?

There is no single best stack. A beginner can start with HTML, CSS, and JavaScript, then add a backend when the project requires one. Full-stack frameworks such as Django, Laravel, Rails, or Next.js can also be reasonable starting points, depending on the developer's interests and the application's requirements.

Is Next.js better than React?

Next.js is a framework built on React. React focuses on building user interfaces, while Next.js provides additional capabilities such as routing, server rendering, and server-side application features. Choose based on how you want to structure and deliver your application.

Do I need Redis to build a scalable web application?

No. Redis is useful for specific caching, data access, and messaging requirements, but it is not a mandatory component of every scalable application. Evaluate your workload before introducing it.

Is Supabase a complete backend?

Supabase provides several backend services, including a PostgreSQL database, authentication, storage, and APIs. Many applications can use these services without building every backend capability from scratch, although custom server-side logic may still be required.

Can I host a modern web application on a VPS?

Yes. A VPS can host modern web applications, APIs, and databases. However, its suitability depends on resource requirements, expected traffic, reliability needs, and your ability to manage infrastructure responsibly.

Can I change my tech stack after building an application?

Yes, although the difficulty depends on how tightly your system depends on particular frameworks, databases, and services. Good architecture can make future changes easier, but migrations still involve cost, testing, and potential operational risk.

Final thoughts: Build what you understand

One of the most valuable lessons from working with different applications is that technology choices should follow the problems you're solving.

Lyenk and Mietric use different application architectures, yet both demonstrate how familiar technologies can be combined to support distinct operational needs.

You don't have to master every framework before building your first application. Start with a small problem, understand the fundamental components, choose tools you can maintain, and learn from how they behave in practice.

Use AI to explore ideas, compare alternatives, and accelerate learning. But don't let the confidence of an AI-generated recommendation replace your own understanding.

The real skill isn't knowing which technologies are trending. It's knowing why a technology belongs in your system—and when it doesn't.

Your first application doesn't need the most impressive tech stack. It needs a thoughtful foundation you can build on.

Further reading

• Stack Overflow Developer Survey 2026 — Technology
• Stack Overflow Developer Survey 2026 — Trust in AI
• GitHub Engineering — Building GitHub with Ruby and Rails
• Shopify Engineering — The State of Shopify's Monolith
• Next.js Documentation — Server and Client Components