HireRosterly Mobile + Cold Calling Agent • Weekly Technical Blog — Week 8

Prepared by Hassan

1. Introduction

This week marked a transition between two different kinds of engineering work. On HireRosterly Mobile, the priority was delivery: bring the application in line with the latest Web capabilities, verify the workflows that matter to employees and HR, correct a navigation-state defect, and produce a release-ready Android build. At the same time, I started a new project, Cold Calling Agent, where the focus was foundation rather than feature volume.

Working across a mature mobile product and a new web platform highlighted the same principle from two directions. Existing software needs careful synchronization and regression awareness; new software needs clear boundaries before automation is allowed to grow. The week therefore combined implementation, manual verification, automated checks, release preparation, database-backed application structure, and disciplined Git delivery.

2. HireRosterly Mobile: Synchronizing the Latest Web Capabilities

The main HireRosterly objective was to reduce the gap between the Web and Mobile experiences. Mobile was updated to reflect newer operational features, including attendance exceptions, contracts, gratuity, and support for multiple attendance locations.

This synchronization was more than copying visible controls. Each capability had to fit the Mobile role model and existing attendance/employee flows. Attendance exceptions needed to make sense within approval behavior; contract and gratuity information had to remain consistent with employee and HR responsibilities; and multiple attendance locations had to integrate with attendance behavior without weakening the existing workflow.

The result is a Mobile codebase that more closely follows the current product rather than becoming a separate, simplified version of HireRosterly.

3. Employee and HR Workflow Verification

After implementation, I manually tested the key employee and HR paths associated with the synchronized features. The checks covered attendance exception approval, contract-related behavior, attendance locations, and gratuity.

This manual pass was important because a successful build cannot prove that a user can complete a workflow correctly. The verification step focused on how the features behave from the perspective of the intended roles, whether the screens expose the expected state, and whether the flow remains understandable after navigation.

The work reinforced a practical testing habit: source validation answers whether the code is structurally acceptable, while manual workflow testing answers whether the product interaction actually makes sense.

4. Fixing the Bottom-Navigation State Bug

A separate usability issue existed in the bottom navigation. The visible active state could become inconsistent with the route currently displayed, which makes a mobile application feel unreliable even when the destination itself loads correctly.

I corrected the navigation-state behavior so Dashboard, Business, Attendance, Chat, and Profile now reflect the active route consistently. The fix improves orientation across the application and removes ambiguity about which primary section the user is currently viewing.

This was a relatively focused change, but it demonstrates why navigation state deserves the same attention as larger feature screens. Persistent navigation is present throughout the product, so a small inconsistency is repeatedly visible to every user.

5. Automated Validation, Android Release and Ticket 22

Once the synchronized features and navigation fix were in place, I completed automated validation and moved the Mobile application through the Android release path. The release APK built successfully, giving the week a concrete delivery artifact rather than ending at source-level completion.

The finalized work was then pushed to the Ticket 22 branch. Keeping the changes on a dedicated branch preserves a reviewable delivery history and makes the scope easier to understand for the rest of the team.

This checkpoint brought together four forms of confidence: feature implementation, manual workflow verification, automated validation, and release packaging. Treating those as separate gates makes the delivery claim clearer and more defensible.

6. Starting the Cold Calling Agent Project

Alongside HireRosterly, I began a new project called Cold Calling Agent. The long-term goal is an AI-assisted outreach platform that can support prospect management, business intelligence, personalized communication, follow-ups, and eventually multiple outreach channels.

The project is structured as a web application with a Next.js frontend and an Express backend, with PostgreSQL/Neon used for persistence. Rather than placing every concern inside the frontend, the architecture separates presentation, API behavior, database access, AI services, and future communication providers.

The complete application is maintained in one repository, with frontend and backend as normal project directories. Environment files and credentials are excluded from version control so the repository can be shared without exposing operational secrets.

7. Login and Registration: Building the Entry Point

The first user-facing milestone for Cold Calling Agent was authentication. I created Login and Sign Up experiences that establish how users enter the platform and how future workspace data will be scoped.

The authentication foundation is not treated as a decorative UI layer. It is connected to the backend structure so protected areas can depend on a real session and workspace context. Registration establishes the basis for a new account and workspace, while Login provides the returning-user path into the application.

Starting with authentication also reduces rework later. Leads, companies, campaigns, messages, and AI-generated data all need an owner and workspace boundary, so establishing that boundary early gives later features a consistent security and persistence model.

8. Dashboard and CRM Foundation

After authentication, I built the dashboard and the main application shell. The dashboard provides a central overview for the product and introduces the navigation structure for Leads, Companies, Campaigns, Inbox, Templates, Analytics, and Settings.

The CRM foundation is designed around a future outreach lifecycle. A prospect can exist as a lead linked to a company, move into campaign or follow-up activity, generate conversations, and later receive AI-assisted analysis or messaging. Even before outbound providers are enabled, the product already has a place for the data those providers will act on.

This approach keeps the project useful during development. The platform can be tested with manually created companies and leads while automated prospect discovery and outreach are still being built.

9. Business Intelligence and AI-Ready Design

The new platform also includes a business-intelligence onboarding flow. It captures the business being represented, the product or service, target market, decision makers, value proposition, campaign objective, communication tone, call to action, and preferred channels.

That information is essential for meaningful AI personalization. A model should not generate outreach from a lead name alone; it needs context about what is being offered, who the ideal customer is, and what action the campaign is trying to achieve.

The backend therefore uses a provider-neutral AI service boundary. Lead analysis, business analysis, message drafting, reply classification, suggested replies, and call context can be implemented through the same application layer without tightly coupling the CRM to a single provider. Communication providers for email, WhatsApp, and calling remain separate so the core system can be tested without accidentally executing outbound activity.

10. Engineering Challenges and Decisions

This week involved different technical risks across the two products. HireRosterly required parity work without disturbing established Mobile behavior. The bottom-navigation issue required tracing route state rather than patching individual buttons. Cold Calling Agent required a clean full-stack structure, database-backed boundaries, and careful handling of environment configuration.

Repository organization was another important decision. The Cold Calling Agent frontend initially had its own Git history while the backend lived outside it. The project was reorganized into one root repository so the Next.js frontend and Express backend can be versioned and delivered together. Secret environment files, dependency folders, and generated build output remain ignored.

The shared lesson was to identify the actual layer responsible for a problem before changing architecture. UI state, API behavior, persistence, environment configuration, provider authentication, and release packaging can create similar visible symptoms but require different fixes.

11. Quality and Delivery Discipline

The week continued a reporting standard used in earlier work: implementation, static validation, runtime verification, release build, and external-provider testing are not interchangeable claims.

For HireRosterly, feature synchronization was followed by manual employee/HR checks, automated validation, an Android release build, and a Ticket 22 push. For Cold Calling Agent, local application validation and database-backed workflows were kept separate from paid AI-provider testing. This prevented unnecessary external calls while still allowing the platform foundation to be tested thoroughly.

The same discipline applies to security. Real environment files are not committed, provider credentials are not placed in documentation, and the project repository contains examples and source code rather than operational secrets.

12. Next Development Plan

The next HireRosterly work should continue from the synchronized Mobile baseline and focus on any remaining regression or release feedback around the newly aligned workflows.

For Cold Calling Agent, the next phase is to continue from the verified platform foundation. Provider integrations should be enabled deliberately: first confirm configuration and error handling, then add controlled email and WhatsApp execution, scheduling, retries, webhooks, suppression rules, and campaign orchestration. Calling remains a later milestone after the non-voice outreach foundation is stable.

The priority is not to make the system autonomous as quickly as possible. The priority is to make each layer observable, testable, and safe so automation can be added without losing control of CRM state or outbound behavior.

13. Conclusion

Week 8 combined a delivery checkpoint on an established product with the beginning of a new product architecture. HireRosterly Mobile was synchronized with newer Web features for attendance exceptions, contracts, gratuity, and multiple attendance locations. Employee and HR workflows were manually tested, the bottom-navigation state issue was corrected, automated validation completed, an Android release APK was built, and the finalized work was pushed to Ticket 22.

Cold Calling Agent progressed from a new project into a usable full-stack foundation with Next.js, Express, PostgreSQL, authentication, Login and Sign Up flows, a dashboard, CRM-oriented navigation, business-intelligence onboarding, and AI-ready service boundaries.

The strongest outcome of the week was not simply the number of screens or files created. It was the ability to move between two engineering modes—shipping a mature Mobile product and structuring a new automation platform—while keeping validation, security, persistence, and delivery evidence explicit.

Week 8 Highlights