What Are You Actually Building? The Missing First Question
Every architecture discussion starts with “what pattern should we use?” or “monolith or micro services?”, actually starts for some weird reason that I will never entirely understand with DB entity modeling, but there’s a question that should come before all of that: what kind of thing are you actually building? Who is it for ?
A team building an internal HR dashboard with the same architectural rigor as a public-facing SaaS platform. Or the reverse: a team treating a developer platform like an internal tool, then wondering why every release breaks their consumers.
We’ve explored how context drives everything, how to choose architecture styles, and how NFRs guide decisions. This article fills the gap that sits upstream ( see what I did here 😉) of all of those: the nature of what you’re building fundamentally shapes every decision that follows.
THE FIVE ARCHETYPES OF SOFTWARE
Not all software is created equal. Five distinct archetypes, each with its own context, pressures, and survival strategies.
1. Internal Business Apps
The accounting tool. The HR dashboard. The compliance tracker. Built for a known, small group of people who all work in the same building (or at least the same company). Susan from accounting is your user, and she’ll tell you directly when something’s broken.
2. Internal Products
Shared libraries, reusable services, internal platforms. Still inside the company, but now your “users” are other teams. That notification service three teams depend on? That’s an internal product. The audience is still bounded, but suddenly you’re serving multiple needs.
3. External Products
SaaS apps, B2C products, anything where strangers pay you money to use your software. Your users are diverse, unpredictable, and they have options. They can leave.
4. Platform / API Products
Stripe, Twilio, Auth0. Your users are developers who build on top of you. Your API surface is your product. A breaking change isn’t a bug fix — it’s a betrayal.
5. Tech Components
CI/CD pipelines, observability tooling, infrastructure automation. Your users are technical teams, and they want one thing above all else: for your stuff to be invisible and reliable.
THE FOUR DIMENSIONS THAT SHIFT EVERYTHING
These five types aren’t just labels — they sit at different positions across four dimensions that fundamentally change your architectural decisions.
Dimension 1: Exposure — How Many People Touch It
From Susan-and-two-colleagues to millions of anonymous users. This isn’t just a scaling question — it changes your feedback loops, your error tolerance, your deployment confidence.
When 3 people use your app, you can deploy at lunch and fix it over coffee. When 300k people use it, you need canary releases and feature flags.
Dimension 2: Variance — How Diverse Are Those People
Three people from the same accounting department think alike, use the software the same way, and have the same mental model. The entire internet does not.
Variance drives how much you invest in UX flexibility, configuration, multi-tenancy, internationalization. Low variance = you can make assumptions. High variance = assumptions will unmake you.
Dimension 3: Persona — Who Are They
A business user wants the software to disappear — they want the outcome, not the tool. A developer using your API wants power, documentation, and predictability. A consumer wants delight and simplicity.
The persona shapes everything from your error messages to your versioning strategy to your DDD relationship patterns.
Dimension 4: Evolution Pressure — What Forces Change and How Fast
The source of change differs radically by type:
Internal business apps evolve because the business changes (new regulation, reorg, new process)
Internal products evolve because internal consumers discover new needs
External products evolve because competitors ship features and markets shift
Platforms evolve because developers build things you never imagined on top of you
Tech components ideally resist evolution — stability is the feature
This connects directly to how we think about stratification and rates of change — deeper layers change slowly, surface layers adapt quickly. Application type determines which layers are “deep” and which are “surface.”
WHERE EACH ARCHETYPE LIVES
Now let’s walk through each archetype and see how the four dimensions actually play out in practice. Same dimensions, wildly different realities.
The Internal Business App — Small World, Clear Rules
Three to fifty people use it. They all work in the same department, maybe the same floor. They think alike, use the same terminology, and have the same mental model of what the software should do. Your persona is a business user who doesn’t care how it works — they care that the invoice gets generated before 5 PM.
Evolution pressure comes from the business itself. A new regulation drops, accounting needs a new field, HR changes the onboarding process. These changes are infrequent but non-negotiable. When they come, they come as mandates, not feature requests.
The architectural luxury here? You know your users by name. The architectural trap? Building it like you don’t.
The Internal Product — Same Building, Different Worlds
Your exposure jumps to tens or hundreds of developers and business users across multiple teams. And here’s where variance sneaks in — the marketing team uses your notification service completely differently than the billing team. Same API, different assumptions, different expectations.
Your persona splits. Some consumers are technical (the dev team integrating your library), some are business (the ops team using your dashboard). You’re serving two mental models at once.
Evolution pressure comes from your consumers discovering new needs. Team A wants webhooks. Team B wants batch processing. Team C just wants you to stop breaking their integration every sprint. The pressure is real but contained — you can walk over and have a conversation about priorities.
The External Product — Open Ocean
Thousands to millions of users. They come from everywhere, think differently, speak different languages, and use your product in ways you never designed for. Variance is high and unpredictable — that feature you built for enterprise clients is being used by a teenager to plan a birthday party.
Your persona is an end user (B2C) or a business user (B2B) who has options. They can switch to a competitor with three clicks. They won’t file a bug report — they’ll just leave. You’ll see it in the churn numbers two months later.
Evolution pressure is relentless and external. Competitors ship features. Markets shift. User expectations rise because every other app they use got better this quarter. You’re not just building software — you’re running a race where the finish line keeps moving.
The Platform / API Product — Building for Builders
Your users are developers, and they’re building their own products on top of yours. Exposure is high — thousands of development teams — but variance is extreme. Someone is using your payment API for a corner coffee shop. Someone else is using it for a multinational marketplace. Same endpoint, completely different worlds.
The persona is technical and demanding. Developers want power, predictability, and documentation that doesn’t lie. They want your API to behave exactly the same way it did six months ago, because they wrote code that depends on it.
Evolution pressure here is paradoxical: your consumers innovate on top of you in ways you never anticipated, which creates pressure to expand — but every change risks breaking something someone depends on. Change is slow, deliberate, and sacred. A breaking change in a platform isn’t a version bump — it’s a breaking hard earned trust.
The Tech Component — Invisible by Design
Your audience is internal engineering and DevOps teams. Exposure is moderate — maybe dozens of engineers interact with it directly. Variance is low — they’re all technical, they all share similar mental models, they all want the same thing: reliability.
The persona is an engineer who wants your CI/CD pipeline, your observability stack, or your infrastructure automation to be invisible. The best compliment a tech component can receive is nobody talking about it. It just works.
Evolution pressure is intentionally slow. Stability is the feature. When your deployment pipeline changes behavior, people don’t celebrate — they panic. Every change needs to justify itself against the risk of disrupting every team’s workflow.
WHAT THIS MEANS FOR YOUR ARCHITECTURE
NFR Priority Shifts by Type
Your architectural north star changes based on what you’re building:
Internal business app → Maintainability first (you’ll be changing this for years based on business requirements)
Internal product → Extensibility first (multiple consumers = multiple extension directions)
External product → Availability + Performance (users don’t wait, users don’t forgive)
Platform / API → Extensibility + Reliability (backward compatibility is sacred)
Tech component → Reliability + Maintainability (invisible and unbreakable)
Architecture Style Alignment
Remember our architecture styles journey? Application type is the first filter.
Internal business apps thrive as monoliths. That’s not a limitation — it’s an advantage. Operational simplicity, fast debugging, easy deployment. Basecamp proved this at scale.
Internal products often land on service-based architecture — enough separation for multiple consumers, not so much that you’re managing a distributed system for an internal audience.
External products span the full spectrum based on scale, but they’re where event-driven and microservices patterns start to earn their complexity.
Platforms almost always need microservices or event-driven because independent evolution of capabilities is non-negotiable.
Tech components often benefit from microkernel/plugin architecture — stable core, extensible edges.
DDD Relationship Patterns by Type
The strategic DDD patterns we explored map almost directly to application types.
Internal business apps are usually conformists — they adapt to whatever the core systems give them, and that’s fine.
Internal products become customer-supplier relationships — formal agreements, negotiated interfaces, version management.
External products and platforms become open host services with published languages — standardized interfaces that serve many consumers.
Complexity Profile
The conservation of complexity plays out differently for each type.
Internal business apps have low essential complexity but high accidental complexity risk (because teams over-engineer them). Platforms have massive essential complexity that you can’t avoid — backward compatibility, multi-tenant isolation, API versioning.
THE DANGEROUS TRANSITIONS
This is where the Growth and Underinvestment archetype shows up.
The most common failure mode: something starts as one type and becomes another without the architecture evolving to match.
That internal tool that “went so well” that leadership wants to sell it? You just jumped from Type 1 to Type 3 without the architectural investment that gap demands. Your exposure went from 5 to 5,000, your variance went from “same department” to “entire market,” and your evolution pressure went from “whenever the VP asks” to “competitors are shipping weekly.”
The POC-to-Product valley is full of bones.
And it’s not just upward transitions. A platform that loses external consumers and becomes an internal-only product is equally dangerous — you’re maintaining platform-level complexity for internal-product-level needs.
Architect’s Alert 🚨
The escalation archetype loves misidentified application types. When a team building an internal business app adopts the same architecture as a team building an external platform, that’s not ambition — that’s CVDD (CV Driven Development) in disguise. The complexity isn’t serving the product; it’s serving the resume.
Before you reach for that architecture pattern, that framework, that infrastructure setup — ask: does this match the archetype of software I’m building? Or am I dressing up a goldfish tank like an ocean aquarium?