This question can seem strange. You didn't develop a Solver  then do it now! Many developers did  and look how popular their Solvers are! MATHEMATICA being an example. However, the truth is that any Solver is stillborn as a training program.
In fact, we did develop a Solver some years ago. This was a rather easy job as all EMTeachline programs are based on symbolic algorithms. Solutions are not stored in any format on a hard disk; on the contrary, the software generates solution during work and projects it to the screen. On this basis, by just adding an editor for examples entry, we have made a problemsolving program, our dear Solver. At first, the program seemed very attractive. However, when we have started testing our Solver, we were bitterly disappointed. The problems emerged as soon as users came into play. We understood at once that the Solver was an abortive project. Why? Because a training program is meant to teach problemsolving skills. The keyword here is "to teach". The user does not know math. Since he does not know math  he does not know what kind of skills he has to train and what kind of examples he has to solve. The Solver cannot help with this! To use the Solver, the user himself has to take an example somewhere, make titanic efforts to enter this example into program, and what's more, he has to know which method of solution to apply! Such knowledgeable user either does not exist or does not need much training.
Thus, we found ourselves in a vicious circle: the program is intended for training, but to use the program effectively, users should be aware of plenty of things we are going to teach them. For some time we resisted and tried to improve our Solver. We introduced an input by analogy, structured editors, lists with solution methods and other things. But the truth was that the Solver was stillborn as a training program. It is sad to attend funerals...
