The CRAFT Framework: A Mental Model for Every Mobile Architecture Decision

Knowing that a decision counts as architecture is only half the problem. The harder half is actually making that decision well, and most developers don't have a repeatable way to do that. They have instinct, whatever pattern is trending on YouTube this year, and whatever their last project happened to use. None of those are wrong exactly, but none of them are a method either.

CRAFT is the mental model we use at Mobterest Studio to close that gap. It's not a pattern you implement. It's five questions you ask, in order, before you commit to any decision expensive enough to matter; Constraints, Responsibility, Adaptability, Fitness, and Tradeoffs.

---

Why a Framework Instead of a Checklist

A checklist tells you what to do. A framework tells you how to think. That distinction matters here because architectural decisions almost never repeat in the same shape twice; the right state management approach for a two-screen MVP looks nothing like the right one for an app with a five-person team and a year of history behind it. A checklist built for one of those situations actively misleads you in the other.

CRAFT works differently. It doesn't tell you which state management package to pick or whether your app should be offline-first. It gives you five lenses to look through so that whatever you decide, you decided it on purpose; with the actual shape of your situation in view, not by copying whatever worked for someone else's app.

---

The Five Lenses

Constraints

Every architectural decision happens inside constraints you didn't choose; team size, timeline, the platform you're targeting, the skill level of whoever maintains this code after you. Ignoring these constraints is how a solo developer ends up building infrastructure meant for a ten-person team, or a startup racing toward a deadline picks an architecture that assumes months of runway they don't have.

Constraints come first in CRAFT because they shrink the decision space before you even start comparing options. Half the "which architecture is best" debates online are actually pointless, because the two people arguing are building under completely different constraints and don't realize it.

Responsibility

This is about where logic lives, and who, or what layer, is responsible for which decisions. Should your UI know how data is fetched? Should your data layer know what a specific screen does with the result? Getting this wrong is what produces the specific kind of mobile codebase where fixing a bug in one screen mysteriously breaks a feature three screens away, because responsibilities were never actually separated; they just happened to work, until they didn't.

Assigning responsibility clearly is what makes an app testable, debuggable, and safe to hand off to someone who didn't write it.

Adaptability

Requirements change. That's not a failure of planning; it's the default condition of building software for actual users. Adaptability is about how much pain a requirements change causes your architecture. Can you swap a backend, add offline support, or support a new platform without rewriting everything, or does every new requirement feel like starting over?

You're not trying to predict the future here. You're trying to avoid architecture so rigid that any change in direction becomes a rebuild instead of an extension.

Fitness

Fitness is the lens most developers forget entirely, because it's not about the decision at the moment you make it, it's about whether that decision still fits the app you're building six months or two years later. An architecture that was exactly right for a five-screen MVP can become the exact thing slowing your team down once that app has thirty screens, three developers, and real production users.

Checking fitness means periodically asking whether an old decision still earns its keep, instead of assuming that because it was right once, it's right forever.

Put a recurring reminder on your calendar (quarterly is enough) to ask one question about your app's core architecture:

[!NOTE] "would I make this same decision again today?" If the honest answer starts becoming "no," that's fitness telling you something before it becomes an emergency.

Tradeoffs

Every architectural decision gives something up. Offline-first buys resilience and costs you sync complexity. A strict layered architecture buys testability and costs you some upfront ceremony on small features. There is no option that wins on every axis at once, and pretending otherwise is how teams end up disappointed by a decision that was actually working exactly as designed, just not in the dimension they were hoping for.

Naming the tradeoff explicitly, before you commit, is what turns "I didn't realize this would be slower to build" into "we knew this would take longer upfront, and we chose it anyway because it protects us later." Same outcome. Very different experience for the team living with it.

---

Putting the Five Together

CRAFT isn't meant to be applied as a rigid five-step ritual for every decision you make, including the trivial ones. It's meant to be the lens you reach for when a decision passes the reversibility test; when getting it wrong would mean touching most of your app, not just one feature.

For those decisions, walking through Constraints, Responsibility, Adaptability, Fitness, and Tradeoffs in order gives you something most developers are missing when they make architecture decisions under deadline pressure: a way to know you thought about the right things, even if you can't be certain you got every detail right. That's a realistic bar.

Certainty isn't available in software. Deliberateness is.

A good framework doesn't remove judgment from a decision. It makes sure judgment gets applied to the right questions, in the right order, before the decision becomes expensive to undo.

---

Where This Goes Next

Each of these five lenses deserves more depth than a paragraph can give it. Constraints alone changes shape completely depending on whether you're a solo developer or leading a team, and Tradeoffs is where most architecture debates online quietly go wrong. Treating CRAFT as a mental model rather than a one-time read is what makes it useful two years into a project, not just on day one.

If you want to go through all five properly with real mobile scenarios, that deeper walkthrough is exactly what the 100 Days of Mobile Architecture bootcamp inside the Engineering Residency is built around.

---

Written by Mobterest Studio: a mobile engineering brand helping developers and founders build better mobile products through architecture-first thinking. Follow along on YouTube for video breakdowns of the concepts covered here.