1. Introduction
Week 3 was focused on taking the HireRosterly Mobile application further than the role-based dashboard foundation completed in the previous week. The main goal was to add new HR and Employee screens, introduce a Leaves section for both roles, continue API testing and implementation, and support the product side of the project through lead collection and audit-report preparation.
The work was split between application development and practical delivery tasks. Mock data was used where it was useful for validating the new screens, while available backend endpoints were tested and integrated into the Login, Signup, HR, Employee and Admin flows. At the same time, a lead sheet was collected and website audit reports were prepared from that research.
2. HR & Employee Screen Implementation
One of the main tasks this week was implementing new HR and Employee screens based on mock data. The purpose of starting with mock data was to validate the UI, navigation and screen states without making the frontend completely dependent on backend availability.
- New HR screen structure implemented and prepared for backend data.
- New Employee screen structure implemented with role-specific presentation.
- Mock data used to validate layouts, states and user flows.
- Screen-level work was kept separate from the data source so real APIs can replace temporary data later.
- The implementation continues the role-based approach established in the previous week.
3. Leaves Section Added for Both Roles
The Leaves section was added to both the HR and Employee experiences. This gives the application a clearer foundation for a leave-management workflow in which HR can work with leave-related information and employees can consume the information relevant to them.
Because the section was built as part of the existing role-based structure, the same UI approach can later be connected to real leave APIs without requiring a complete redesign. For this stage, the focus was on getting the screens and flow in place and keeping the implementation ready for backend integration.
4. API Testing & Implementation
API work continued across the main areas of the mobile application. Login, Signup, HR, Employee and Admin APIs were tested and implemented where the required backend functionality was available. This helped verify that the frontend was not only visually prepared but could also communicate with backend services.
- Login API testing and authentication flow validation.
- Signup API testing and implementation for registration-related behavior.
- HR API testing and integration with HR-related screens.
- Employee API testing and implementation for employee-facing functionality.
- Admin API testing and implementation for administrative workflows.
- Remaining APIs were identified for continued testing and implementation in the next week.
A key part of this work was maintaining a clear separation between the screen and the service/API layer. This makes it easier to troubleshoot API problems without unnecessarily changing the UI.
5. Lead Collection
Alongside the application work, I collected new business leads and organized the information needed for follow-up and website review. The lead sheet includes fields such as business name, niche, city or suburb, website, website score, mobile score, UI issues, CTA issues, speed issues, contact name, email and phone details.
This process turns unstructured business research into a usable list that can support both outreach and audit-report preparation. It also provides a repeatable workflow for collecting new leads in future weeks.
6. Audit Reports Preparation
Audit reports were prepared from the collected website leads. The purpose of the reports was to convert the lead research into a clearer business-facing review of website quality and visible issues.
- Website review information was organized for each lead.
- Website, mobile and UI scores were used as review signals.
- CTA and speed issues were captured as actionable points.
- Business and contact details were kept with the audit information for follow-up.
- The audit process creates a repeatable path from lead collection to outreach material.
7. Testing & Integration Workflow
This week required balancing two types of work: feature implementation and integration testing. The HR and Employee screens could progress with mock data, while API testing could proceed independently as backend endpoints became available. This reduced the risk of blocking all frontend progress when a backend issue appeared.
The overall workflow was: build or update the screen, connect the relevant service/API, test request and response behavior, handle the integration issue if one appeared, and keep the remaining work clearly separated for the next cycle.
8. Issues / Failures Faced & Learnings
There were several practical blockers during the week. First, the audit-report PDF workflow reached a limit while working in GPT, which affected the ability to continue generating reports in the same way. Second, the React Native APK build was not completed. Third, a CORS issue from the backend affected API connectivity and required further backend-side investigation.
These issues were useful from a development perspective because they showed that feature implementation is only one part of delivery. Tool limits, build configuration and backend integration settings can also determine whether a feature can be fully tested and shipped.
- API integration issues should be checked early instead of waiting until the end of a feature.
- Android build validation should be treated as its own delivery checkpoint.
- Audit-report generation should have a repeatable process that is not dependent on one temporary tool path.
- Frontend service boundaries make it easier to continue UI work while backend problems are being resolved.
9. Punctuality & Team Participation
The week maintained a steady mix of application development, testing and delivery support. Development tasks were aligned with the available backend functionality, while lead collection and audit preparation provided additional deliverables that could continue independently.
- Requirements were translated into new HR and Employee screens.
- Leaves functionality was introduced on both sides.
- API testing and implementation continued across multiple roles.
- Lead research and audit preparation were completed alongside development work.
- Integration blockers were identified and documented for follow-up.
10. Next Development Plan
Next week will focus on closing the remaining integration work and increasing the amount of repeatable lead and audit output.
- Test the remaining APIs that were not fully covered this week.
- Implement the remaining HR, Employee and Admin API integrations.
- Work with the backend to resolve the CORS issue.
- Complete and validate the React Native Android APK build.
- Collect new business leads.
- Prepare the next batch of website audit reports.
11. Improvement Plan & Support Required
The main improvement area is making the delivery process more independent of individual blockers. API calls should remain organized inside service modules, CORS and API contracts should be checked early, and the Android build should be verified as a separate milestone rather than only at the end.
Support would also improve delivery speed. Paid Codex access would help with coding, debugging and implementation work. In addition, guidance on completing the React Native APK build would help move the application from development/testing toward a usable Android build. Backend assistance is also needed to resolve the CORS issue and confirm the remaining API contracts.
- Paid Codex access for faster coding and debugging support.
- Help with the React Native Android APK build and build troubleshooting.
- Backend support for CORS configuration and remaining API contracts.
12. Conclusion
Week 3 expanded HireRosterly from its role-based dashboard foundation into a broader implementation and delivery cycle. New HR and Employee screens were introduced, the Leaves section was added to both roles, and API testing and implementation continued across Login, Signup, HR, Employee and Admin areas. In parallel, business leads were collected and audit reports were prepared.
The main remaining work is now clear: finish the outstanding API testing and implementation, resolve the backend CORS issue, complete the APK build, collect new leads and continue producing audit reports. With the required technical support in place, the next cycle can focus on turning these remaining items into a more complete and testable delivery.
Author: Hassan Shafique