The right order for board selection: scenario, constraints, then the board

1.1 A familiar script

You want to build something — say a temperature and humidity meter you can check remotely. You open a shopping site, search for "development board", sort by sales and find a board with impressive specs: a few hundred MHz, dozens of GPIOs, and "free tutorials included". The price is reasonable. You order.

Three days later the board arrives. Then you discover the tutorials are five years old, the bundled IDE will not install, and searching the error message returns three ancient posts on an English forum. A week later, the board goes in a drawer.

The problem is not you, and not entirely the seller. The problem is that the order of selection is reversed.

1.2 Wrong order vs right order

The wrong order (the instinct of 90% of beginners): specs → price → order → then figure out what to build.

The right order: scenario → constraints → board.

Why does the order matter so much? Because a development board is not a fast-moving consumer good — it is an entry point into an ecosystem. You are not just buying a PCB; you are buying the tutorials, libraries, community and documented pitfalls behind it. The clock speed on a spec sheet does not determine project success — the ecosystem does.

1.3 Step one: describe the scenario clearly

"I want to build a smart device" is not a scenario, it is a wish. A proper scenario description answers four questions:

Fill in this template and you have already eliminated more than half of the candidate boards.

1.4 Step two: three typical constraints

Constraints filter the candidate set from "dozens of boards" down to "two or three". In order of importance:

Constraint one: connectivity

• No connectivity (local control, offline operation) → every MCU board remains a candidate
• Wi-Fi/Bluetooth → narrows to boards with built-in wireless such as the Espressif ESP32 family, Pico W and Arduino Nano ESP32
• Long-range low power (hundreds of metres or more) → LoRa solutions, usually "main board + LoRa module"
• New protocol (NearLink) → the NearLink series, but accept that the ecosystem is still young

Many selection mistakes come from applying this filter last: you buy a board without wireless, discover halfway through that you need connectivity, and have to start over with an add-on module.

Constraint two: real-time requirements

Ask yourself: if the system responds 0.1 seconds late, could that cause an accident?

• Yes (motor control, closed-loop PID, balance bots) → you need hard real-time; choose a traditional MCU such as STM32 and stay away from any board running Linux
• No (temperature/humidity reporting, human-machine interaction, data logging) → far more options, including Linux boards

A one-line test: any delay the human eye tolerates is fine for an MCU; any delay a motor cannot tolerate is unacceptable for Linux.

Constraint three: ecosystem maturity

This is the highest-weight factor for beginners and can be relaxed for experienced makers. Check three things:

1. Are there plenty of tutorials in your language? (Search the board model — if you find fewer than 10 decent tutorials, beginners should stay away.)
2. Is there an existing library for every peripheral you plan to use? (OLED, servo, sensors — check each one.)
3. Can you find answers to error messages? (Search the board model plus a common error keyword and see what comes back.)

This is why beginners are advised to start with ESP32 or STM32 — not because they are the most powerful, but because every step where you get stuck, someone has been stuck before and written down the answer.

Secondary constraints (budget, power consumption) come after these three. The reason is simple: the difference between ¥30 and ¥60 matters far less than whether you can finish the project at all.

1.5 A complete walkthrough

Back to the remote temperature/humidity meter from the opening. Here is the full reasoning:

Scenario: home use, living room/balcony, long-running
  ↓
Constraint 1 (connectivity): needs Wi-Fi → eliminate all boards without wireless
  ↓
Constraint 2 (real-time): humans read the data, half a second late is fine → no filter
  ↓
Constraint 3 (ecosystem): first beginner project, needs plenty of tutorials → Espressif wins
  ↓
Secondary constraints: budget-sensitive → ESP32-C3 (¥ tier);
         want to play with a screen too → ESP32-S3 (¥¥ tier)
  ↓
Conclusion: ESP32-S3-DevKitC or ESP32-C3-DevKitM

The whole walkthrough takes less than two minutes, but every step has a reason. It does not guarantee the most powerful board — it guarantees a board you can finish the project with.

1.6 Three thinking traps

Trap one: spec worship. "This one runs at 240 MHz and that one only 133 MHz, so buy the faster one." — The compute your temperature meter needs was available on chips twenty years ago. Excess specs will not make you succeed; a barren ecosystem will definitely make you fail.

Trap two: architectural sentiment. "RISC-V is the future, I want to learn it in one go." — There is nothing wrong with believing in the architecture, but starting your first project on a RISC-V Linux board means facing three unknowns at once: a new architecture, a new OS and a new project. Challenge one layer at a time.

Trap three: the "do everything" mindset. "Buy a board that can do everything, then I am set for any future project." — There is no do-everything board. Boards with Wi-Fi are not great at hard real-time; boards running Linux are not power-efficient. Development boards are consumables, not heirlooms.

1.7 Chapter checklist

• □ Have I written a four-part scenario description? (what / who for / where / how long)
• □ Is the connectivity requirement clear? (none / Wi-Fi / long-range / new protocol)
• □ Have I judged the real-time requirement? (would a 0.1-second delay cause an accident?)
• □ Have I searched how many tutorials exist for the candidate boards? (fewer than 10 → switch)
• □ Have I confirmed an existing library for every peripheral I need?
• □ Have I considered the budget constraint last?
• □ Am I choosing a board for "this project" rather than for "all future projects"?