tools
Build the Thing You Keep Wishing Existed
Every tool I have built started the same way: I was annoyed, repeatedly, at the same thing, for long enough that building the fix became less effort than continuing to suffer.
That is a genuinely good filter. If you are annoyed once, ignore it. If you are annoyed every single week for four months, you have found a real problem, and you have found the one user whose needs you understand perfectly, which is you.
The advantage researchers have
You know the domain. Most people building research tools have never actually done research, which is why so many of them are beautiful and slightly beside the point.
You know the difference between the workflow people describe and the workflow they actually have. You know that nobody organises their papers in advance, they organise them in a panic two days before a deadline. You can build for the real behaviour instead of the tidy imaginary version.
Ship something small
The instinct is to design the complete system: every feature, every edge case, a plugin architecture. Then you never finish, because you are building for imaginary users with imaginary requirements.
Build the smallest thing that removes today's annoyance. Use it yourself. Let the next feature be demanded by your own frustration rather than invented by your imagination. Almost every good feature I have added came from being irritated by my own software, which is a wonderful way to get honest feedback.
Constraints are a gift
When I built my research tracker I set one hard rule: everything stays on the user's machine. No server, no accounts, no telemetry.
That constraint eliminated a huge amount of work. No backend, no database, no authentication, no privacy policy to agonise over, no hosting bill. It also made the product better, because researchers are handling unpublished work and are rightly suspicious about where it goes.
A constraint that makes the build simpler and the product more trustworthy is not a limitation. It is the design.
It counts
There is a quiet snobbery in academia that software is not a real contribution. This is nonsense. A tool that a hundred researchers use every week has more effect on the field than a paper that gets cited twice out of politeness.
Build things. Put them somewhere people can find them. Write down how they work.