Building automated tests is going to take time and effort. But it will also save time and effort in manual testing and may reduce the need for rework.
The trick is to find the right balance for your team. There are two approaches you might want to consider:
The first approach is to analyse your past bugs and try and target your automated tests at the components and functionality that fails the most often. This approach can provide the maximum benefit for the smallest investment of time and effort.
Another approach is to work with the stakeholders to determine which functionality is most important in the product. Add your automated coverage starting fom the most important feature and working your way down the list. I have worked with some teams where they submit the list of automated tests to the Product Owner for approval. The Product Owners may then say something like "that's great, the functionality you are covering is all the important features of the applications. Problems elsewhere we can live with if necessary".
FitNesse is a good tool as it allows for a lot of exploratory testing by testers or non-technical stakeholders. Possibly you would want to try a few FitNesse tests first to see if it fits in with the way your team works.
One piece of advice for web based automated testing is to make your tests as independent as possible from the page layout. For example you can use IDs to identify the elements on the page and these IDs can remain constant even if the layout changes.
FitNesse is a good tool as it allows for a lot of exploratory testing by testers or non-technical stakeholders. The idea with FitNesse is to separate the testing code from the test scenarios. As an example, say your team was working on a calculator application. The developer would write some code for adding together two numbers. They would also write a FitNesse 'test fixture' which passed numbers to the adding code and returned the answer. FitNesse then provides an interface for the tester (or even business users) to pass data to the test. So the tester might pass 2 + 2 and expect an answer of 4. One benefit of this approach is that the testers can focus on test scenarios and not worry about how to write the automated tests.
Cucumber is a tool that is used to do Behaviour Driven Development (BDD). With Cucumber you tie your requirements closely to your tests. Cucumber allows the team to write the requirements using business friendly language. Then Cucumber provides the hooks between these requirements and testing code. Using the calculator example again, you could write a scenario in Cucumber like "given I have two numbers (5, 7) when I add those numbers together then I will get a sum of 12". Cucumber would then link this scenario to an empty code method. It would be up to the developers/testers to write the code that made the test work.
You can see how these kinds of testing tools give you a neat way to integrate automated tests in to your work. But take note they don't actually include the test automation itself. I would suggest you try them out and see which ones your team finds to be useful.