Tech stack

In short

• A tech stack is every tool the product runs on, from interface framework to database and hosting.
• Pick well-known, well-supported tools the team already knows. Boring is usually right.
• The stack matters less than who owns it and how clearly it is documented.
• Changing a stack later is expensive, so the first choice deserves an hour of thought, not a month.

Also called: Technology stack, Software stack, Development stack, Stack.

The layers of a stack

When someone asks what a product is built with, they are asking about its stack. The answer usually runs from top to bottom, from what the user sees to where the data lives.

How to choose one

Founders sometimes treat the stack as the most important technical decision. For most products it is not. Many different stacks can build the same product well. What sinks projects is usually unfamiliar tools, abandoned libraries, and code nobody else can maintain.

1. Start from what the product needs. Web only or mobile too, real-time features, heavy data, strict compliance.
2. Prefer what the team knows. A team working in tools it knows ships faster and makes fewer mistakes.
3. Choose mainstream, maintained tools. Large communities mean more libraries, more answers, and easier hiring.
4. Think about who comes next. Can you hire for this stack where you are? Can another team pick up the code?
5. Use services for solved problems. Payments, email, and sign-in are rarely worth building yourself.

Ownership matters more than the logo

Whatever the stack, a few questions decide whether you are in control of it. Whose accounts are the hosting, database, and services in? Is the code in a repository your company owns? Is there a short document explaining how to run, deploy, and change it? A good stack in a contractor's personal account is a bigger risk than an unfashionable stack you fully own.

At Choie, everything is agreed in writing before work starts, and once the fees for a deliverable are paid, the designs and source code written for you are yours to use, change, and distribute. Third-party libraries and services stay under their own licenses. See who owns the code.

Stack choices and no-code tools

A no-code platform is a stack too, just one you rent rather than own. It can be the right first step, and the trade-offs are covered in no-code vs custom code. The same ownership questions apply: can you export your data, and what happens if the platform changes its pricing?

Tools that generate code from prompts sit somewhere in between. They often pick a stack for you. Check what they chose, and whether you could maintain it, before building a business on top of it. Weak early choices show up later as technical debt. Choie applies the same check to its own AI use: AI drafts code from a decided design, a senior person reads every line before it ships, and generated code that is not understood is not merged.

Common mistakes

• Choosing for the CV. A developer picks a new framework they want to learn, and the product pays for the learning.
• Too many tools. Five services where one would do means five bills, five dashboards, and five ways to break.
• Planning for scale you do not have. Infrastructure for millions of users before there are a hundred.
• Switching stacks mid-build. Rewriting in a different framework rarely fixes the problem that prompted it.

Common questions