Your app doesn't crash because of bad code. It crashes because of the decisions you never made.
Where does your data actually live? What happens to your bill when you go from 10 users to 10,000? Who's responsible when something breaks at midnight? Most builders find out the hard way — you don't have to. Here's the 7-question checklist to run before you write your first line of code.
Before you write a single line of code, you make choices you'll be living with for years. Here's how to make them on purpose instead of by accident — explained with a real app.
Imagine two friends, Alex and Sam, decide to build a note-taking app together — think a simple version of Notion. They're excited. They open their laptops and start coding the login page that same night.
Six months later, Alex is up at 2 AM because the database is down and nobody knows how to restore it. Sam just found out a client in Germany can't legally use the app because user data is stored in a country with no privacy agreement. Neither of these problems was a coding bug. They were architecture problems — decisions that should've been made before the first line of code, not discovered in a panic afterward.
This is what "architecture" really means: not the fancy diagrams, but the small set of decisions that are expensive to undo later. Let's walk through seven of them, using Alex and Sam's note-taking app as our running example.
1. Where Should Your Data Be Stored?
Every app needs a home for its data — user accounts, notes, files, settings. The question is: where, physically and logically, does that home sit?
Alex and Sam had three real options:
- A managed cloud database (like Amazon RDS or Supabase) — someone else runs the servers, they just use it.
- Their own server — full control, but they have to maintain it themselves.
- A hybrid — some data in the cloud, some cached locally for speed (like notes stored on your phone so the app works offline).
They picked a managed cloud database. Why? Because neither of them had ever managed a production database before, and a managed service handles the scary parts — patching, scaling, security updates — automatically.
The beginner lesson: where your data lives determines your speed (how fast users can access it), your risk (who's responsible if it leaks), and how much of your time goes into "keeping the lights on" versus building features.
2. How Will Your Expenses Scale Over Time?
Here's a trap almost every new builder falls into: they check the price today and ignore the price at 100,000 users.
Alex and Sam started with a "free tier" database that costs nothing when you have 10 users. But when they modeled it out, they found the app's cost curve was not a straight line — image storage costs jumped sharply once they crossed a certain number of files, because their chosen provider charged much more per gigabyte after the free allowance.
The beginner lesson: ask "what does this cost at 10 users, 10,000 users, and 1,000,000 users?" before you commit. A tool that looks free today can quietly become your biggest expense once you succeed. Success should never accidentally bankrupt you.
3. How Much Say Does Your Team Really Have?
Control is a trade-off, not a free win. More control means more responsibility.
Sam wanted to self-host everything — "so we own our destiny." Alex pushed back: "We're a two-person team. If the server crashes at midnight, who's fixing it?"
They compromised: they used a managed database (less control, less burden) but hosted their own custom backend logic on a cloud server they controlled (more control where it actually mattered — their unique features).
The beginner lesson: don't ask "do we want control?" — of course you do. Ask "do we have the time and people to responsibly use that control?" A team of two rarely benefits from managing their own servers, load balancers, and security patches. A team of fifty engineers might.
4. Do You Need to Follow Any Regulations?
This is the one beginners skip entirely — until a customer's legal team emails them.
Alex and Sam's note app started getting interest from a healthcare company that wanted employees to store patient-related notes. Suddenly, "just store the text in a database" wasn't good enough. Healthcare data in many countries falls under strict rules (like HIPAA in the US) about who can access it, how it's encrypted, and how long it's kept.
They hadn't planned for this, and it meant weeks of re-work: encrypting data at rest, adding audit logs (a record of who accessed what and when), and picking a hosting region that met the requirement.
The beginner lesson: ask early — even if you think the answer is "no" — whether your app will touch health data, payment data, children's data, or data from users in regions with strict privacy laws (like the EU's GDPR). If there's any chance, design for it from day one. Retrofitting compliance is far more painful than building it in.
5. How Will You Recover If Something Goes Wrong?
This is the one that woke Alex up at 2 AM.
Their database provider did offer backups — but only if you turned the setting on, which they hadn't. A routine update accidentally deleted a table, and there was nothing to restore from.
A good backup strategy answers three questions:
- How often do we back up? (Every hour? Once a day?)
- How long do we keep backups? (A week? A year?)
- How fast can we actually restore, and have we ever tested it?
That last point matters most. A backup you've never tried to restore isn't a backup — it's a hope.
The beginner lesson: backups aren't a "nice to have" you add later. They're a seatbelt — invisible until the one moment they save you completely.
6. Do You Actually Need a Custom Setup?
Most apps don't need anything exotic. A standard web server, a standard database, a standard hosting platform — that's enough for the vast majority of ideas.
Alex and Sam briefly considered building their own custom search engine for notes, from scratch, because "existing tools felt slow." They spent a week on it before realizing an existing open-source search tool did 95% of what they needed, for free, already battle-tested by thousands of other apps.
The beginner lesson: a custom environment (custom infrastructure, custom frameworks, custom anything) should be the last resort, not the first instinct. Ask: "does a standard, boring, well-tested tool already solve this?" Usually, it does. Save your custom-building energy for the one thing that actually makes your app special.
7. How Much Say Do You Need Over How It Behaves?
This is about how predictable and adjustable your app's behavior needs to be — especially relevant now that many apps use AI features.
Alex and Sam added an AI feature that auto-summarizes long notes. Early on, they used a third-party AI service with default settings. But they quickly found they had almost no control over how it summarized things — it sometimes changed the tone or missed key details, and they couldn't adjust it.
They switched to a setup where they could give the AI clear instructions and guardrails, giving them far more control over its behavior — while still not having to build the AI themselves.
The beginner lesson: figure out, for each major feature, whether you need tight control over exactly how it behaves (important for anything user-facing or safety-related) or whether "good enough, out of the box" is fine. Paying for more control only where it truly matters keeps you fast and safe.
Putting It All Together
None of these seven questions have a single correct answer. The right answer for Alex and Sam's two-person note-taking app is different from the right answer for a 200-person fintech company. What matters is that you ask the questions on purpose, before you're forced to answer them during an outage, a legal notice, or a surprise bill.
A simple way to remember them:
| Question | What it protects you from |
|---|---|
| Where should the data be stored? | Slow, insecure, or inflexible systems |
| How will expenses scale? | A shocking bill at scale |
| How much say does the team have? | Burning out a small team |
| Any regulations to follow? | Legal trouble and lost trust |
| How will we recover from failure? | Losing everything in one bad moment |
| Do we need a custom setup? | Wasting time reinventing the wheel |
| How much say over its behavior? | Unpredictable, hard-to-fix features |
Good architecture isn't about picking the fanciest tools. It's about picking tools that match your team, your budget, and your users — and being honest about the trade-offs before they become emergencies.
Top comments (0)