I used to be a development infrastructure team leader. Part of my job, as I decided it to be, was to provide tools for teams to communicate with their customers and provide tools to build better and more relevant software.
The team itself worked like a startup company within the organization. We didn't force people to use any of our solutions – we tried to make them thrilled and excited about them, so they would support our products and use them with their own will.

While I had success in some cases, there are couple of failures I still carry with me in my head, and lately I figured out that they all share the same problems.

I worked alone

Most of the time, I worked on these tools for too long, alone. They all began with me starting to hack at night, and evolved to real projects, with no one but myself writing them with me. Although it was very fun to begin with it, working alone on these tools wasn't rewarding because I had no one to be excited as me about the projects.

It taught me that demo time is important. Make time to show your projects to your colleagues. Many team leaders, with me included, had this problem that we haven't asked for a demo. I just didn't wanted to interrupt my employees. Just agree on the demo on a specific time, and make it seven, eight, fifteen minutes long demo.
It can be a fun thing to do, and the team can learn and get inspired from the act.

I had no real users

I always seen myself as the user, when I clearly wasn't. This is a basic rule in UX design: thinking about myself as the user makes me to make wrong assumptions about the tools and the way I solve the problems. Hell, I am sometimes wrong about the problems themselves, without consulting with a real (or another) user. One example is my love for command line utilities and VIM in particular, while other colleagues are terrified by it.

Go out for a walk, think about your problem and characterize your users. Who are they? If they're your coworkers, talk to them. If they are 23 years old bartenders, go to a nice night out with a pen and a piece of paper and just talk to a bartender.

The important thing here is to talk to another human being. Even if you are a future user for the app, you should understand what to address first. Many times we see the big picture and we want to solve it from one end to the other – but sometimes providing a really simple and basic tool is enough for start.

Providing a good MVP to your users is the most important thing. It might feel like a simple CRUD application, but it might solve a tiny bit of the problem. The only way to have a good MVP is to understand what HAS to be in the app and what is just NICE TO HAVE for now.

I tried to satisfy others

I showed one of the tools to my boss. The tool was a micro-blogging/blogging/mailing list tool, making teams interact with their customers. My boss took my demo and showed it to some department managers in our organization. They loved it, and asked for a couple of features. One of the features, was to create a “secret” mailing list, changing the solution surface and actually changing the problem that the tool solved.

I just needed to say “no”. However, I'm not used to it, and I really hate to be a no-man, since I really believe in making people happy. Because I had no “real users” either, I thought that my vote doesn't count.

You can't satisfy everyone, so most of the time, you better satisfy yourself.

Now, I know what the vision of the tool should have been: “Open communication between teams and their customers”. Providing this specific vision could make these department managers understand what the tool is for and what it isn't for.
Making sure you address the right problems is an important part of your application. This way you can measure yourself against your competitors and have some agenda why you provide a better tool. You can also get more customers this way, and have people believe in your way, and make FANS for your software. Which is pretty damn wicked.

I was more excited about the code than the product

I saved this one for last. Not that long ago, I worked on a kind-of a Medium clone. In this project, I used Draft.js for the first time, and spent most of the time trying to add images with drag and drop and making a great user experience. I actually wrote an article about Composable SQL in JavaScript while working on this project because I was so thrilled about the way I queried the database.

I'll say it again. I was thrilled about the way I queried the database. I was thrilled how I queried a SQL database, I used for years with Rails, PHP and even plain ASP.

You can't say it's a bad thing, because it is the opposite. Yet the fact that I tried to implement the things I read on Brian Lonsdorf's (drboolean) awesome and life-changing book about JavaScript made me put so much time and effort on the way my code looks and acts. This is awesome for a side project or just testing a feature inside your project, but it should not slow you down in a real project.

If the only thing that excites you in a project is how you write it, well, let me tell you something, the product won't be as good as your code. Try to be a boring programmer. Make decisions about your product and not about your code. Remember that you have to deliver a product. Your users probably don't care about your functional programming skills as long as your product works. They just want to use it.

So,

Is jQuery enough for this app or you should use React? Just build the damn thing, show it to your coworkers and give it to your real users already. That's how you deliver, and that's what you're paid to do basically. 💰