Pind's Rule of Five
A rule of thumb that I’ve coined since I did ACS workflow is Pind’s Rule of Five: Before trying to design a general solution to a problem, implement at least five different instances of it, different in as many aspects as possible. Only then will you know what the right generalization is.
It’s going to take longer than if you just dive in, but the result is going to be a lot better. Workflow would definitely have benefited from this strategy.
This is the strategy I’m currently pursuing by building a bug-tracker, that’s everything I want it to be. Then building a couple more workflow-centric apps that’s everything I want them to be. Then I can take a step back and ask myself: How can I best refactor these, so they’re all built on a shared workflow infrastructure?
That way you don’t lock yourself into a stiff system that won’t let you do something you’d like it to do. And you don’t create a generalized solution for something that it later turns out, you don’t actually want.
A crucial component is to let time pass and let the app prove itself with users before you accept your solution and start generalizing it.