Justifying React to the Business

React is fun to use. As a developer, this is (if we admit) one of the primary reasons for choosing it, or really any framework. Sure, there are good technical reasons too: functional programming is nice and clean, components are resuable, and all that good stuff.

But what happens when your boss or client asks “What framework will you use?”

You’ll say “React!”, naturally.

And when they ask why, you’ll go, “Because it’s awesome and it’s so hot right now!”

Then they will go: 😒

And you’ll be all: 😞

Business Justification

Just because a framework is currently popular, fun to work with, or used by Facebook, doesn’t necessarily make for a bullet-proof justification to the higher-ups why it’s the best choice for their next project.

They’re usually concerned with “business justification”. To us developers, that seems like weird boring double-speak, but it’s often pretty rational when you break it down.

Your bosses and clients want things like:

Speed of Development

Will this choice make the project more likely to be done on time and within budget? (very closely related, since many developers bill hourly, and we developers usually don’t come cheap).

Ease of Maintenance

Related to the item above: how easy (read: fast and cheap) will it be to maintain the project? From a business point of view, this means adding new features and changing existing functionality without burning a ton of time on expensive developers and things that go along with developers – like project managers, QA people, etc.

Long-Term Usefulness

Businesses look at software as an investment. They do not want to spend 8 weeks on 3 developers to build a thing that the next developer will suggest rewriting from scratch (for another 8 weeks).

On one hand, this means that the code should continue to work for a decent number of years. If you were still working for the company in 5 years, and this project were still in production, would it be viable to keep supporting it? Or will it be a jumbled mess of spaghetti code?

On another hand, if you leave the company after you finish this project (or this is a one-off for a client), how hard will it be to find another developer to take over when it’s time to add a new feature or two?

A Known Quantity

Is this some fly-by-night framework, or will it stick around for a while? Is it well-built? Battle-tested? The competition here is stuff with strong name recognition (e.g. jQuery) that has been used in previous successful projects.

And note: “successful” in the business sense usually means that it shipped, and it’s making (or saving) money. It doesn’t mean the codebase is a work of art. There is plenty of ugly code in the world making plenty of money.

Low-Risk

The inverse of all the above things causes increased risk. Businesses don’t like risk.

Risk can take many forms… things like:

the project might never be completed
- because the codebase turned into a medieval horror and velocity ground to a halt
- because the one developer who knew the Fancy New Framework quit and went to work for Google for 3x their salary
the project is completed but nobody is willing or able to work on it
it costs way more than expected (time or money or both)
the license scares away acquiring companies, customers, etc.
open source can be scary or misunderstood (e.g., fear that using GPL-licensed code would cause company code to become open source)

Businesses want to mitigate these things as much as possible.