JavaEE rockstar wanted - microprofile with wildfly swarm - responsive UI

We want to implement a website with responsive UI, which provides location based services in cars for the driver and his guests The service shall provide guest details to potential guests, like how many free places are left and what estimated time of arrival (ETA) the car will need to reach their location. Some example: assume you want to order a specific shared car (taxi), and now you want to know if you book this car, will you have enough free places left and what time will it arrive at your location. The service will have during the POC 2-4 cars. Later it may get up to about 20 vehicles (car, bus, ...). infrastructure: car side A tablet or a smartphone, which is always cable-powered and connected to the car will be connected via wifi to the car internet access point. The position of the car shall be read from the smartphone and pushed to the server for historical reasons. the server side is a docker based environment, which will have these dockers - a apache webserver container - a wildfly swarm container - a postgresql container - a keycloak oauth container for user authentication user-side: - smartphone of any vendor (ios, android, ...) - Tablet of any vendor - Laptop OS of any vendor (Windows, Mac, Linux, ...) - PC of any vendor what needs to be developed: - server side - client side User groups/roles We have two types of user groups: - the driver - the guests - controlling users Security: - the driver has a dedicated UI (driverUI) and he can reach it only via a username and password - the guests have also a dedicated UI (guestUI) and they can also reach it only via username and password Payment(-gateway): see [login to view URL] The web application: driver features - the driver have to be able to enter amount of guests entering the car and the amount leaving the car with a very simplistic UI which contains buttons +1, -1, +2, -2, +5, -5, +10, -10 the buttons have to be big sized (about 1cm x 1cm) for easy handling (good UX) - on the same UI, shall have two simple buttons available: - planned destination reached, which immediately pushes the current position - planned departure, which immediately pushes the departure - the driver shall be able to enter operating issues like - this car is broken and unavailable (results the car will not be available anymore in the ETAs for the users) - this car has only fewer seats, due to some issues (results the free seats are reduced) - some other textual issues, which the driver can enter - fallback UI - the driver shall be able to update his position manually in the case of the position detection is failing (gps out of order). The possible positions are predefined and can be considered as masterdata - the driver shall be able to update his ETA manually controlling features: - a scheduler shall create and send via E-Mail a monthly report with the details: - Date, Time, Guest-Entry-Location, amount of guests joined, amount of guests left end user features: - ETA - the user shall see a table of the next ETAs of the cars to his nearest locations, if location detection is available. The table shall be similar like on subways or on airports. The table contains: ETA to the next arrival point of the car, current position (named by the track inbetween departure and arrivial points "departurePoint-arrivialPoint"), amount of guests, free places left, any issues - if location detection is not available, the user shall be able to pick his nearest location - the position of the car on a real time map - the position of the interesting car shall be available on a real time map on the users device - this map is only visible if the user clicks on it Please share us your questions and especially we need a credible fixed price proposal. Our payment plans: we pay in milestons, which we define together. On the beginning we define small and short frame milestones. The better we know each other we expand the milestones and the timeframes.