When starting a new project, the first thing most of us do is wrong: we try to decide which technology to use. We start thinking "React or Vue, Postgres or Mongo, monolith or microservices." Yet none of these questions mean anything until you've answered the questions that should come first.

In this article I'll describe how I make architecture and technology decisions when starting a project — that is, the questions I ask before picking a tool. The goal here isn't to say "use this stack"; it's to build a thinking framework for how to decide.

Start with questions, not technology

Architecture isn't a list of technologies. Architecture is your answer to your constraints. So the first job is to clarify the constraints. Before choosing any tool, I need to know the answers to these:

• What is the scale? 100 users or 1 million? 10 requests a day or 10,000 a second? The real answer for most projects is far smaller than you think — and that simplifies a lot.
• What does the team know? Not the "best" tool, but the one the team knows best is often the right choice. The cost of starting with a technology you don't know can outweigh the advantage it offers.
• How fast does it need to ship? A two-week MVP and a product that will live five years don't make the same decisions.
• What does the data look like? Is it relational (are users, orders and comments linked to each other), or loose and unstructured? This single question answers most of the database decision.
• How interactive / real-time is it? Are you writing a blog, or an app with simultaneous editing?
• Who will maintain it, and for how long? Will you keep running the project six months from now, or hand it off?

Choosing technology without answering these is like tailoring a suit without taking measurements.

The most useful framework: is it reversible?

I split every decision I make with one question: is this decision easy or hard to undo later?

Some decisions are "one-way doors" — once you walk through, going back is very expensive. Changing the database after the project has grown, rebuilding the core data model from scratch, collapsing a microservice architecture back into a monolith... These are one-way doors, and they deserve your time.

Other decisions are "two-way doors" — if you don't like it, you go back easily. A CSS framework, a logging library, the folder structure... Arguing about these for hours is a waste; pick the most reasonable one and move on. If you're wrong, you change it in half a day.

Much of the difference between a junior and a senior developer is here: the experienced developer quickly tells which decision is which kind of door and puts their energy in the right place. Fast on two-way doors, slow and careful on one-way doors.

Architecture choice: almost always start with a monolith

The "microservices or monolith" question is debated far too much on new projects. My practical answer is clear: start with a monolith.

The problems microservices solve — independent scaling, teams working independently, fault isolation — are real, but they are the problems of large projects. Moving to microservices while you still have a handful of users is like taking medicine for a disease you don't have. In return you buy distributed-system complexity, network latency and deployment difficulty for free.

The right path is this: start with a monolith split into good modules. Keep the boundaries clean. The day a piece really needs to scale independently, then split it out. This means opening the "one-way door" as late as possible — and usually you never need to open it at all.

Database: let your default be relational

The database decision is a one-way door, so it needs care. My practical rule: if the data is relational (and in most applications it is), start with a relational database. Postgres is more than enough in most cases and is a safe default that won't make you regret it later.

NoSQL (like Mongo) has its place — genuinely unstructured data, very large scale, or cases where the schema keeps changing. But starting with NoSQL "to be flexible" usually means losing the relationships and consistency guarantees you'll have to build by hand later. If you have relationships — a user's orders, an order's products — a relational database is already designed for that job.

Rule: choose NoSQL not because it's "cool," but because a measurable need makes it necessary.

Avoid over-engineering: solve today's problem

The most insidious mistake on new projects is designing for a future that doesn't exist yet. Adding complexity today by asking "what if millions of users come?" or "what if we add that feature later?" is almost always waste. Because:

• That future often never arrives.
• When it does, the needs turn out different from what you predicted.
• Meanwhile, the unnecessary complexity you carry slows you down every day.

Start with the simplest working solution. When you feel real pain — when you really slow down, when you really hit a limit — that's when you add complexity. Premature optimization is a bill you pay up front for a problem you don't have.

In practice: my checklist before starting

Here's the order I run through my mind before diving into a project:

1. What am I building, and for whom? Can I explain it in one sentence?
2. What are the real constraints? Scale, time, team, data shape.
3. Which part is the riskiest / most uncertain? Clarify that first; the rest takes shape around it.
4. Which decisions are one-way doors? Spend time on those, move fast on the rest.
5. How do I do this in the simplest possible form? Save complexity for later, for when it's truly needed.

Conclusion

Good architecture isn't choosing the newest or most powerful tools; it's giving the simplest answer that best fits this project's real constraints. There's no such thing as "the best architecture" — there's the architecture that best fits its context.

So on your next project, instead of starting with "which technology should I use," ask "what is this project's real problem, which decision is hard to undo, and what is the simplest thing that works." The technology choice will fall out of the answers on its own.

When you start a new project, what's the first question you ask? What do you pay most attention to when deciding? I'm curious.