Constraints: Why Every Good Architecture Starts With What You Can't Do

Two developers can ask the exact same question: "what's the best way to manage state in this app?", and arrive at completely different, equally correct answers. Not because one of them is wrong. Because the question itself is incomplete without the context neither of them said out loud: who's building this, how much time do they have, and who has to maintain it after.

That context is what Constraints, the first lens in the CRAFT framework, is actually about. It's easy to skip, because it doesn't feel like architecture work. It feels like admin; the stuff you note down before the "real" decisions start. In practice, it's the thing that makes half the online debates about "the right way to architect a Flutter app" pointless, because the people arguing are quietly building under completely different constraints and don't realize it.

---

The Constraints That Actually Matter

Not every limitation is worth naming. A slow laptop isn't an architectural constraint. These are the ones that genuinely change what the right decision looks like.

• Team size. A solo developer and a five-person team are not building the same kind of app, even if the feature list is identical. Heavy abstraction layers, strict dependency injection, and elaborate module boundaries exist to help teams coordinate without stepping on each other. A solo developer paying that same cost is buying coordination overhead for a coordination problem they don't have.

• Timeline. An architecture that's right for a six-month runway can be actively wrong for a two-week deadline, and vice versa. Building for long-term flexibility takes upfront time you may not have, and building purely for speed creates debt you may not be able to afford to pay off later. Neither is universally correct. The timeline is what tells you which one you're actually facing.

• Skill level of whoever maintains this. An elegant, layered architecture is only elegant if the person maintaining it understands why it's shaped that way. Handing a junior developer a codebase built around patterns they've never seen doesn't make the codebase more maintainable, it makes it a black box they're afraid to touch, which produces exactly the kind of fragile, defensive code that clean architecture was supposed to prevent.

• Platform and infrastructure reality. What backend you already have, what your team already knows, what your hosting budget actually allows, these aren't creative constraints, they're just facts. Designing an architecture that ignores them isn't ambitious. It's designing for a project you don't actually have.

Most "which architecture is better" debates aren't really disagreements about architecture. They're two people assuming the same constraints and never checking whether that assumption is true.

---

Why Constraints Come First in CRAFT

It would be reasonable to assume Constraints matters least of the five; that Responsibility, Adaptability, Fitness, and Tradeoffs are the "real" architectural thinking, and Constraints is just scene-setting. The opposite is true. Constraints comes first because it shrinks the decision space before you spend any energy comparing options that were never realistic for your situation in the first place.

If you're a solo developer with three weeks to ship an MVP, an elaborate clean-architecture setup with five layers of abstraction isn't a more rigorous choice than a simpler structure; it's a worse one, because it spends your scarcest resource, time, on a problem you don't have yet. You're not being lazy by skipping it. You're reading your constraints correctly.

The reverse mistake is just as common, and arguably more expensive. A team of five building a product meant to scale for years sometimes reaches for the fastest, simplest structure because it's what a tutorial recommended, without acknowledging that their actual constraint (multiple developers working in the same codebase for a long time) calls for more structure, not less.

---

Constraints Change, and So Should Your Reading of Them

None of this is a one-time exercise. A project's constraints at week one are rarely its constraints at month six. A solo side project that gains a second developer, a startup that closes a funding round and buys itself more runway, a maintenance-mode app that suddenly needs a new platform target; each of these is a constraint shifting underneath a decision that was made when the old constraints applied.

This is where Constraints connects directly to Fitness, the fourth lens in CRAFT: an architecture that fit your constraints perfectly a year ago can stop fitting the moment those constraints change, even if nothing about the code itself got worse. Recognizing that your constraints have shifted, and being honest that the old decision was right for the old situation, not wrong in some absolute sense, is what keeps a team from either clinging to an outdated structure or blaming a decision that was actually sound when it was made.

[!NOTE] Most "which architecture is better" debates aren't really disagreements about architecture. They're two people assuming the same constraints and never checking whether that assumption is true.

---

What This Looks Like in Practice

Naming your constraints honestly is uncomfortable in a specific way: it means admitting things about your situation that don't feel impressive. "I'm one person with three weeks" or "nobody on this team has touched Riverpod before" aren't confessions you want to lead with. But they're exactly the information that separates a decision that fits your actual project from one that fits an imagined, more resourced version of it.

The upside is that this is also the fastest of the five CRAFT lenses to apply. It doesn't require deep technical analysis; it requires honesty about your team, your timeline, and your skill level, stated plainly before you compare a single option. Get that part right, and the rest of the decision usually gets easier, because half the options you'd otherwise be debating were never realistic for your situation to begin with.

Every developer's constraints are different, which is exactly why generic advice tends to fall apart in practice; what's right for someone else's team size, timeline, or skill level may not translate cleanly to yours. If you want to work through your specific constraints with someone who can actually respond to your situation instead of a general audience, that's exactly what Ask Joy (Mobterest Studio's async mentorship) is built for.

---

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.