One urgent role became a nine-person team
A North American equipment rental business needed one full-stack developer in two weeks. Three years later, nine Aalam engineers are still on the team.
Sector | Equipment rental |
Markets | North America, Canada, Europe, Australia |
Engagement | Started June 2023 — still running, 3+ years |
Team placed | 9 engineers: 6 full stack, 2 MAUI, 1 database |
Tech stack | .NET, Angular, DB2, SQL Server, Xamarin, MAUI |
Overlap | About 5 hours a day with the client's team |
The problem
The client had a single full-stack developer role open and a two-week window to fill it. They came to us to see whether we could move faster than their own hiring process.
The role was not an abstract headcount gap. They were launching a new product — a scheduling system for their field technicians — and the work could not start without the engineer.
What we did
They asked in the last week of May 2023. The engineer started on 1 June 2023, inside their two-week window.
Our engineers joined the client's own way of working rather than running a parallel process: their daily standups, their Jira board, their code review process. We held roughly five hours of overlap each day in our evening, so questions were answered in real time instead of waiting a day for a reply.
The team built and owned the technician scheduling system end to end — the work assignment engine that automates how technicians are matched and managed for jobs.
What was hard
The honest difficulty was people, not technology: finding engineers with the right skills who would also hold a consistent standard of work over years rather than months. We handled it by being selective on who we put forward, setting explicit expectations on ownership and quality, and keeping review and collaboration frequent enough that drift was caught early.
The result
Time to start | Under two weeks from request to first working day |
Team growth | 1 engineer in June 2023 → 9 engineers today |
Retention | 3+ years, the engagement is still running |
Delivery | Ticket throughput and release frequency both improved |
Expansion | The client has repeatedly added engineers to the team |
The strongest number here is the simplest one. A client who is unhappy does not go from one engineer to nine, and does not keep a team for three years.
In the client team's words
“They work well with the team, take accountability for their work, and consistently deliver releases to a high-quality standard. They are also flexible and able to adjust timelines when priorities or requirements change, while keeping delivery on track.”
[ATTRIBUTION AND APPROVAL PENDING]
How our engineers used AI on this codebase
We publish this because buyers now ask, and most vendors cannot answer it.
Tools used | Claude Code and GitHub Copilot, for code suggestions, troubleshooting and development support |
Client policy | The client had an AI and data-security policy. We followed it. |
Client data | No real client data or sensitive information was put into AI chat tools |
Review | Every AI-assisted change was reviewed by an engineer before it was committed |
Security | GitHub security checks plus the client's normal review, testing and quality gates — the same checks as any other code |
What we learned: AI tools are useful for routine development and troubleshooting, but engineer review is not optional. Existing coding standards, security requirements and client-specific patterns all have to be weighed before an AI-generated change is accepted.