“Can we just add a field?”
That sentence is how small requests sneak into a system wearing a friendly face. Everyone in the room hears simple. Everyone imagines a quick change. And almost nobody sees what a BA sees: “just” is never describing the work—it's describing the speaker’s mental model.
In software, “just” doesn’t mean “easy.” It means “I’m only thinking about the part I can see.”
That’s why “just” is expensive. It’s a discount applied before the cost is known. It turns real work into surprise work, and surprise work is where trust, timelines, and quality go to get quietly taxed.
So here’s the move: don’t argue about “just.” Translate it. Give it a price tag people understand.
The “Just Tax” (a BA framework that makes hidden work visible)
When someone says “just,” you can assume a set of costs will show up. Not because your team is slow—because systems are connected. The “Just Tax” is simply the set of hidden work that appears when a change becomes real.
Data Tax is the cost of meaning. A new field requires a definition, a value set, validation rules, defaults, and often a mapping to something downstream that already has a similar-but-not-identical concept. If you don’t pay this tax up front, you pay it later in reconciliation, reporting discrepancies, and messy backfills.
Decision Tax is the cost of agreement. A “small” change has to answer big questions: who approves it, what “done” means, what gets deprioritized, and what happens in edge conditions. Teams don’t get stuck because they can’t build—teams get stuck because they can’t decide.
Dependency Tax is the cost of touching other things. The UI isn’t the system; it’s a window into the system. Downstream integrations, analytics pipelines, vendor tools, permissions, and interfaces all need to be checked. “Just” becomes expensive when you discover the change crosses system boundaries.
Documentation Tax is the cost of being able to explain yourself later. Traceability, release notes, audit trails, updated requirements, test cases, and business rules. Documentation isn’t bureaucracy when you’re regulated, distributed, or operating at scale—it's how you prevent re-learning the same lessons.
Deployment Tax is the cost of making it safely real. Testing, regression checks, rollout plans, feature flags, monitoring, rollback, training materials, support scripts. This tax is often ignored because it’s not “building,” but it’s what prevents the build from becoming a late-night incident.
Diplomacy Tax is the cost of humans. Updating expectations, negotiating tradeoffs, managing the “I thought you meant…” moments, and preventing stakeholders from feeling ignored. This tax is invisible until it’s overdue—and then it’s the most expensive one.
None of these taxes are optional. The only choice is whether you name them and manage them, or let them arrive as “unexpected complexity.”
Three quick scenes: how “just” creates requirements debt
1) “Just add a field”
The request seems harmless: add one field to capture a customer attribute.
Then the BA questions start:
What does it mean? Is it required? What are valid values? Does it replace something that already exists under another name? Which system is the source of truth? What happens when it changes?
Now the Data Tax arrives: definitions, value lists, validation, defaults, historical values. If you’re in mortgage or financial services, this is where mapping conversations show up—MISMO/industry schemas, reporting definitions, downstream warehouse alignment.
Then the Dependency Tax: the field needs to appear in one screen, then two, then the portal, then the integration feed. A vendor platform can’t accept the new value length. Reporting wants it standardized. Support wants to know what to tell customers when it’s blank.
A week later someone says, “Why did a ‘field’ take so long?”
Because you didn’t add a field. You added meaning to a system.
2) “Just change a label”
This one is the classic trap because it sounds like pure UI.
“Change ‘Applicant’ to ‘Borrower.’ It’s just a label.”
But labels aren’t just labels. They’re contracts.
Decision Tax shows up immediately: Is this purely cosmetic, or are we aligning to a regulatory definition? If “Borrower” has a different legal meaning than “Applicant,” you’ve changed more than text—you’ve changed interpretation.
Documentation Tax follows: training materials, screenshots, user guides, SOPs, and release notes. Support scripts have to change because users will call and say, “Where did Applicant go?” QA has to validate not just the new word but whether that word appears in emails, PDFs, disclosures, and error messages.
And then Diplomacy Tax: someone in compliance asks why the new term appears in a customer-facing communication before legal approved the language. Someone in operations says, “We trained people for months on the old wording.”
The team didn’t “change a label.”
They changed a shared vocabulary—and that’s never free.
3) “Just add an exception”
“Can we just add an exception for these cases?”
Exceptions are where simplicity goes to get multiplied.
The moment you add “except when…,” you create branches: business rules, decision tables, conditions in the rules engine, and a test matrix that balloons. Now QA isn’t testing one flow—they’re testing the flow plus the exception across roles, channels, products, and edge scenarios.
Deployment Tax arrives: feature flags, rollout, monitoring. Exceptions love to break silently because they only trigger occasionally—until they trigger constantly.
And when the exception causes a downstream mismatch, it’s suddenly not just a rule. It’s a reconciliation problem, a reporting problem, and an audit question: “When did this change, why did we do it, and who approved it?”
“Just add an exception” is never just code.
It’s a long-term maintenance subscription.
The BA move: keep “just” small by forcing a tradeoff (not a debate)
The best BAs don’t respond to “just” with resistance. They respond with translation.
You don’t need to say: “That’s complicated.”
You need to say: “That’s possible. Let’s price it correctly.”
A “just” request becomes manageable when you turn it into a change with boundaries:
- What problem does this solve?
- Who benefits and how will we know?
- What will we not do if we do this now?
- What systems does this touch?
- What does “done” mean (including edge cases)?
When you do that, you’re not slowing the team down—you’re preventing surprise work from ambushing the sprint later.
Simple lines that stop “just” politely (and keep momentum) going:
- “Happy to—what are we trading off to fit it in?”
- “What problem does this solve, and for whom?”
- “If we do this now, what won’t we do this sprint?”
- “Let me confirm what ‘small’ means by checking downstream impacts.”
- “Can we log this as a change with owner, value, and acceptance criteria?”
Turn ‘Just’ Into a Tradeoff
“Just” is how complexity gets approved without being seen.
It’s not a technical problem. It’s an expectations problem.
Your job isn’t to kill small requests. It’s to stop small requests from becoming surprise commitments. The moment you name the taxes—data, decisions, dependencies, documentation, deployment, diplomacy—“just” stops being a shortcut and becomes a choice.
And choices are manageable. Surprises aren’t.
So when “just” shows up, don’t say, “That’s hard.”
Say, “That’s possible—here’s what it costs.”
Because in tech, the most expensive word isn’t “impossible.”
It’s “just.”
Author: Maria Santos, Senior Systems Analyst
Maria Santos is a seasoned systems analyst with a passion for unraveling complex technological puzzles. Armed with a background in computer science and a keen eye for detail, Maria thrives in the dynamic world of software development, where she combines technical expertise with creative problem-solving to deliver innovative solutions. With years of experience collaborating with multidisciplinary teams, Maria has honed her ability to navigate ambiguity and translate disparate stakeholder perspectives into cohesive system designs. Her dedication to continuous learning and adaptability has enabled her to stay at the forefront of emerging technologies and industry best practices.
Outside of her professional endeavors, Maria is an avid reader and aspiring writer, with a penchant for exploring diverse topics ranging from technology trends to personal development. She is excited to share her insights and experiences with readers, hoping to inspire and empower others on their own journeys in the ever-evolving landscape of technology.