Ever notice how every blog post about greenfield architecture follows the same sanitized script? “Understand the business workflow. Create flow diagrams. Pick a tech stack.” It reads like someone asked ChatGPT to write the most consultant-friendly version of a thought process that never actually happened.
The reality is messier. It’s shaped by organizational politics, sunk cost fallacies, and the quiet desperation of knowing your database choice will be scrutinized by a VP who once read a blog post about MongoDB.
When a Reddit user named Fine-Variety-9759 asked how experienced engineers actually approach new projects, specifically for an AI-powered healthcare appointment system, the responses revealed something important. The checklist approach most junior architects carry around isn’t wrong. It’s just dangerously incomplete.
The First Question Isn’t About Technology
Your first instinct is probably to ask about the tech stack. Maybe you’re already mentally comparing databases or weighing cloud providers. Stop.
An experienced architect starts with a completely different question, one that the commenter holger-woltersdorf framed perfectly: “Get into a face-to-face assessment with the client and ask for the reason why this software is needed. What are the actual pain points for patients and the reception staff?”
This isn’t just warm fuzzy collaboration talk. It’s the single highest-leverage activity you’ll perform.
When you’re building a healthcare product that handles appointment booking and clinic inquiries through AI, the difference between “we need an AI scheduling system” and “the reception staff spends 40% of their day on the phone explaining insurance coverage” leads to radically different architectures. One requires natural language understanding. The other might just need a well-structured FAQ that integrates with the existing phone tree.
The biggest determining factor, as Acrobatic-Ice-5877 pointed out, is whether your product is new or a new version of an existing product. An existing product has specific dependencies you can’t touch. The ecosystem comes with political constraints that dwarf any technical decision you’ll make.
The Constraint Trinity That Actually Matters
Before you draw a single box in your architecture diagram, you need to answer three questions that chills716 identified:
Constraints: What can’t you change? What’s non-negotiable? For a healthcare product, this means HIPAA compliance, maybe FHIR standards, probably a requirement about data residency. These aren’t trade-offs. They’re walls.
Goals: Not the “scale to a million users” generic goal. The actual, specific, measurable goal. Is this system replacing paper-based scheduling? Then success isn’t about concurrency. It’s about adoption by staff who’ve been doing things the same way for fifteen years.
The “ilities”: Availability. Scalability. Reliability. Fault tolerance. Maintainability. You can’t prioritize all of them. Pick two. Maybe three if you’re feeling ambitious.
Why “Estimate Traffic and Scalability” Can’t Be Last
Your initial list put scaling estimates at the end. This is backwards. This needs to be up front, because it determines your tech stack, which determines your flows, which determines whether you need a cache, a queue, or a completely different database architecture.
Lilacsoftlips made this point directly: “Estimating scaling can’t be last though, it needs to be up front. This helps you choose the tech stack, which will determine your flows.”
If you’re building an internal tool with double-digit users, you’re designing a completely different system than if you’re building a consumer-facing product. One can get away with basic auth on the enterprise intranet. The other needs horizontal scaling, multi-region failover, and a plan for when your cloud provider has an outage.
This is where the concept of architectural change cases becomes invaluable. Rather than trying to predict the future, you create specific scenarios that would break your current assumptions. What happens if adoption is 50% higher than your highest estimate? What if you need to add support for RVs and boat renters? What if you expand to a second state with completely different insurance regulations?
These change cases force you to evaluate whether your current architecture choices create expensive reversibility problems.
The Modular Monolith Debate (And Why Microservices Probably Suck for You)
Every greenfield project eventually faces this decision. The experienced architects in the Reddit thread were surprisingly unanimous: start with a modular monolith.
Acrobatic-Ice-5877 said it plainly: “I would lean towards a modular monolith unless I knew I needed independent deployments and had a very specific reason for it.”
R2r_rrr agreed: “Start simple, monoliths are alright if modularized correctly. You can carve out services if/ever needed.”
The mistake isn’t choosing microservices. It’s choosing them by default. Microservices are an optimization for team topology, not for technical performance. If your organization isn’t big enough to have multiple teams needing independent deployment cadences, you’re adding distributed systems complexity for no benefit.
A modular monolith gives you the clean separation of concerns without the operational nightmare. You can carve out services later when you actually need them.
Vendor Selection: The Hidden Debt Trap
This is where junior architects make their most expensive mistake. They evaluate vendors based on features, documentation quality, and maybe pricing. The experienced architects evaluated them based on something else entirely: the cost of losing access.
Acrobatic-Ice-5877 shared a painful personal lesson: “I am relying on one payment processor. If there is a service disruption or I receive an account ban, it would be crippling. I’ve also made the mistake of deeply tying my code and database to this one payment processor.”
This is the vendor lock-in problem that nobody talks about in tutorial videos. Your payment processor, email service provider, object storage provider, and authentication provider are all potential single points of failure. And unlike your own infrastructure, you have exactly zero control over them.
The solution isn’t to avoid vendors. It’s to design agnostic interfaces around them. Abstract the payment gateway behind an interface. Make your email provider swappable. Think about what would happen if your database provider raised prices by 10x, and design accordingly.
This connects directly to the broader problem of why GitHub stars and popularity metrics can mislead architecture decisions. A vendor with six million GitHub stars can still disappear tomorrow. The popularity of a tool doesn’t guarantee its longevity.
The Process That Actually Works
Here’s the synthesis of what multiple experienced architects actually do, distilled from the Reddit thread and enriched with the architectural change cases framework:
Phase 1: Discovery (Not Requirements Gathering)
This is the phase most engineers skip because it feels like “business stuff.” You need to understand the actual pain points, not the features someone imagined would solve them.
hardik1399 described the approach: “Ask questions. Understand what the requirements are and what does the final version of the tool/platform look like to your stakeholders.”
Use AI tools to create mockups and get initial feedback. This is one place where AI genuinely accelerates the process, letting you iterate on the visual design before writing a single line of backend code.
Phase 2: Constraint Identification
Document everything you can’t change. Not “we prefer relational databases.” The actual constraints: compliance requirements, existing system dependencies, team skill sets, budget limitations, timeline.
This is also where you identify what holger-woltersdorf called the “political limitations around the ecosystem.” The system that “can’t be touched” because it takes weeks for approval and months for implementation.
Phase 3: Vertical Sliced Flow Modeling
This is the most underrated skill in architecture. Instead of drawing abstract layers, model the actual flows as vertical slices. For each slice, ask: “What decisions lead to the next state?” This reveals preconditions and possible outcomes that you’d miss with a top-down layer-first approach.
holger-woltersdorf uses a specific technique: “Visualize the described processes in chapters of vertical sliced trigger-intent-event-state flows. Ask what decisions lead to the next state for each slice.”
This produces diagrams that are actually useful for discussion with stakeholders, not just decoration for a documentation folder.
Phase 4: Architectural Change Case Creation
Before committing to a stack, build a small table of what-if scenarios. For each scenario, estimate the probability and the cost of reversing your decision.
| Change Case | Probability | Impact | Reversibility Cost |
|---|---|---|---|
| 50% higher adoption than estimates | Medium | Storage and compute costs | Medium |
| New state with different regulations | Low | Business logic changes | High |
| Primary database vendor acquisition | Low | Data migration | XL |
| AI model provider changes pricing | Medium | Integration code changes | Medium |
This table, adapted from the InfoQ article on architectural change cases, forces you to evaluate which decisions create the most dangerous debt.
Phase 5: Stack Selection Based on Irreversibility
Choose your stack based on one criterion: how expensive is it to change this decision later?
Your programming language? Hard to change. Your database? Painful but doable. Your cloud provider? Expensive but possible. Your event streaming platform? Depends on how tightly coupled your code is.
This is where why documenting architectural decisions is critical for long-term maintainability becomes apparent. The decisions you make with minimal information now will be second-guessed by engineers who don’t have the context. Write them down.
Phase 6: Start with the Simplest Architecture That Handles the Change Cases
Don’t build for a future you can’t predict. Build for a future you’ve explicitly defined through your change cases.
A client calling a service that uses a SQL database. That’s your starting point. From there, you add infrastructure as the change cases demand it. An API gateway when you have multiple services. A cache when the read path becomes the bottleneck. A queue when you need to offload slow work.
This is the progressive architecture approach taught in hands-on system design: start with the most fundamental components and compose them into scalable architectures only when the need is proven.
The Vibe Coding Trap
Since the original Reddit post was about an AI-powered healthcare product, let’s address the elephant in the room: AI code generation.
The temptation is to use an AI coding agent to generate the MVP rapidly. The risk is that you lose control of the architectural decisions because they get embedded in generated code that nobody fully understands.
The architectural change cases framework identifies specific risks for AI-generated code: the AI company goes out of business, the model changes significantly, the generated code is unrepeatable.
The solution isn’t to avoid AI tools. It’s to be explicit about the architectural decisions before you let the AI generate code. The team needs to spend time defining objectives, writing specifications, including code samples, and defining acceptance tests. These artifacts are more important than the AI-generated code itself.
This connects to the broader problem of how AI tools can skew architectural decisions and create hidden risks. The AI generates what you ask for, but it doesn’t know what you’re not asking about.
The Real Art Edge Case Handling
Most architecture tutorials focus on the happy path. The experienced architects focused on something else entirely.
hardik1399 outlined the data considerations that most people don’t spend enough time on: “How do you ensure ACID properties? What if there are multiple concurrent users and you run into a race condition? How do you ensure authentication and authorisation? Archival? Data retention? Data quality? Schema enforcement?”
And the final question: “What is the breaking point of each and every service and what are the edge cases?”
This is the actual skill of architecture. Not drawing boxes. Not knowing the latest framework. Understanding where your system will fail and designing for that failure.
What This Means for Your Next Project
If you’re building a new system from scratch, the experienced architect’s process looks like this:
- Start with the constraints, not the choices. Document what you can’t change before you think about what you can.
- Scale estimation is a first-stage activity, not a last-stage afterthought. It determines everything else.
- Build modular monoliths. Carve out services only when you have a concrete, proven need for independent deployment.
- Design agnostic vendor interfaces. Every vendor should be swappable, even if you never plan to swap them.
- Create architectural change cases before you commit to a stack. The cost of reversing decisions is the most important metric you never measure.
- Document decisions with context. The rationale behind a decision is more valuable than the decision itself.
- Start simple and add complexity only when change cases demand it. A SQL database and a single service can handle more than you think.
The difference between a junior architect and an experienced one isn’t knowledge of patterns. It’s knowing which patterns to apply based on the specific constraints of the system you’re building, and knowing that the constraints are more important than the patterns.
As one commenter noted, the communication challenge senior architects face isn’t explaining the architecture. It’s explaining why the architecture exists in the first place. The decisions are only half the battle. The rationale is where the real value lives.
