Three of us. That's the whole (Product and Engineering) team.
Pretty much
When I joined Payd as Head of Product Engineering, I built a new team from scratch: me plus two product engineers. Coming from roles where I managed 50-100 developers across multiple domains, this felt... different. Smaller. More intimate.
Turns out, that was exactly the point.
What We Built
PaydFlex is a mobile app for casual workers in Malaysia and Thailand. If you're not familiar with the term, "casual workers" are people who work on-demand shifts - typically in hospitality. They're not full-time employees. They pick up shifts at hotels, restaurants, and events as needed. One day they might be serving at a wedding, the next day running room service at a hotel.
The problem? Managing casual workers is messy. Hotels need to find workers, workers need to find shifts, and everyone needs to get paid - often on different schedules with different rates. It's a lot of phone calls, WhatsApp messages, and manual spreadsheets.
Hotels run 24/7. Front desk needs coverage at 3am. Room service peaks at breakfast. Events need extra hands on weekends. Coordinating hundreds of casual workers across multiple properties, each with different roles, rates, and availability - this is a logistics nightmare that most hotels solve with spreadsheets and phone calls.
PaydFlex fixes this. Workers can browse available shifts, apply, clock in/out through the app, and get paid instantly. Hotels get a dashboard to manage their casual workforce, track attendance, and handle payroll. Simple.
The tagline is "Apply, Work, Earn" - or AWE. Some of us call it "AWEsome." I'm not apologizing for that pun.
EWA meets AWE. Payd's existing product is EWA (Earned Wage Access), and our new product's tagline is AWE. The acronyms practically wrote themselves.
The PaydFlex mobile app for casual workers - shifts, clock in, attendance, and earnings
A New Team, A New Product
I joined Payd with a specific mandate: build a brand new Product Engineering team from scratch.
Payd already had an EWA (earned wage access) product, but the team that built it had left the company. They wanted to expand into a new market - casual workers in hospitality - and needed someone to build a new team and a new product.
I hired two engineers and we got to work. Two months later, we had an MVP: mobile app for workers, HR Portal for hotels, backend systems, everything. End-to-end.
Our first client was a big hotel chain in Malaysia. They were managing casual workers the old way - spreadsheets, phone calls, WhatsApp groups. Within weeks of deploying PaydFlex, they had hundreds of casual workers using the app to pick up shifts, clock in/out, and get paid. The hotel's HR team could finally see their entire casual workforce in one dashboard instead of chasing down attendance records manually.
After that first deployment, we kept shipping. More features, more enhancements, more clients. But the foundation was laid in two months by three people.
There's no "backend team" or "frontend team" here. No DevOps person to throw infrastructure tickets at. No QA team to catch our bugs. We're product engineers. Everyone owns features end-to-end, from database schema to API to UI to deployment.
This sounds scary if you're used to specialized roles. But it's actually freeing. No handoffs. No "that's not my area." No waiting for another team to unblock you. Just: here's the feature, ship it.
The Numbers So Far
Since launching PaydFlex:
- 30,000+ shifts processed
- 2,600+ active casual workers
- 10+ companies (mostly hotels in Malaysia and Thailand)
- 2 million Malaysian Ringgit in payouts
Not bad for a team of three.
How We Ship
My approach is simple: ship constantly.
- Small features: at least one per week
- Medium to large features: 2-3 weeks of development
We don't do elaborate sprint planning or quarterly roadmaps. We prioritize based on user feedback, pick the next most valuable thing, and ship it. Then we repeat.
This cadence keeps momentum high. The team sees their work in production weekly, sometimes daily. Users see improvements constantly. There's no "big release" anxiety because every release is small and low-risk.
We're Lazy (And That's a Feature)
The data flow in PaydFlex is fast, big, and intertwined. Shifts, attendance, payouts, worker profiles, company settings - everything connects to everything. When something goes wrong or someone needs data, other teams would reach out to us: "Can you check this worker's clock-in records?" "Can you fix this shift?" "Can you pull a report for this hotel?"
We got tired of running the same queries. So we built Flex Admin Portal.
This is an internal tool that lets admins - our operations team, customer success, finance - click around and manage data themselves. No more pinging engineering for every little thing. They can look up workers, fix attendance records, adjust shifts, pull reports, all without writing a single SQL query.
The portal exists because we're lazy. We'd rather spend two weeks building a tool than answer the same question fifty times. It's self-service for everyone else, and peace of mind for us.
This is what I mean by internal tools being force multipliers. The ROI isn't always obvious upfront, but over time, these tools let a small team operate like a much larger one.
The HR Portal
The PaydFlex mobile app is for workers. But hotels need something different - they need to manage hundreds of casual workers, coordinate shifts across properties, approve timesheets, and process payroll.
We built the HR Portal for this. It's a separate web application that lets shift coordinators and finance managers see everything in one place: who's working today, who clocked in late, which shifts are understaffed, how much payroll to process this week.
The HR Portal - managing shifts and workers in one place
AI as Assistant, Not Replacement
We're a small team. We can't manually validate hundreds of KYC documents every day. But workers still need to get verified before they can start picking up shifts.
So we built our own version of KYC and document verification - with AI as the "auto verifier." Every document submitted goes through the AI first. It checks for completeness, flags suspicious entries, and gives a confidence score.
But here's the thing: we don't trust it completely. The AI is our assistant, our second opinion. A human still reviews the flagged cases. The AI handles the obvious passes, highlights the questionable ones, and lets us focus our limited time where it matters.
AI-powered KYC verification - our assistant, not our replacement
We also added AI for timesheet validation and anomaly detection in attendance patterns. Smart notifications when something looks off. The goal is simple: make the humans more efficient so they can focus on actual problems instead of data entry.
The Tech Stack
We keep things pragmatic:
- PaydFlex mobile app: React Native
- HR Portal: ReactJS
- Backend: Golang
- Cloud: AWS
- Database: PostgreSQL
Why React? Because I understand it. My team understands it. We can move fast with it.
I'm a pragmatic software developer. I pick frameworks based on familiarity and productivity, not hype. React Native lets us ship to both iOS and Android with one codebase. ReactJS is battle-tested and has an ecosystem we can rely on. Could we have used Flutter or Vue or something else? Sure. But we'd be learning on the job instead of shipping.
There's something to be said for boring technology that you know well.
What We Actually Ship
Beyond PaydFlex, our team maintains three mobile apps:
- Payd - The main EWA app for Malaysia (inherited)
- PaydFlex - The casual worker app (ours - the AWE one)
- Friyay! - Singapore version of Payd EWA (inherited)
All three run on iOS and Android, serving 6,000+ registered users with 5,000 monthly active users across Malaysia, Singapore, and Thailand.
What Small Teams Force You to Do
Here's what nobody tells you about leading a tiny engineering team: you can't hide.
In larger organizations, it's easy to get lost in process. Meetings about meetings. JIRA tickets that spawn more JIRA tickets. Architecture documents that nobody reads. You can spend weeks "working" without shipping anything.
With three people, there's nowhere to hide. We ship or we don't. The feedback loop is immediate.
I lead and mentor the two engineers, but I'm also in the code. We own everything end-to-end: architecture, development, deployment, monitoring. When something breaks at 2am, there's no "on-call rotation" to hide behind. It's us.
This sounds stressful, and sometimes it is. But it's also liberating. No approval chains. No "let's schedule a sync to discuss the RFC." Just: here's the problem, here's the solution, let's ship it.
What I've Learned
Building a team from scratch has taught me a few things:
Hire for ownership, not specialization. Product engineers who own features end-to-end are worth three engineers who only touch their layer.
You can't fake code quality. With three people, technical debt compounds fast. We spend real time on code reviews, testing, and refactoring. Not because it's "best practice" but because we'll be the ones dealing with the mess later.
Ship cadence matters more than sprint ceremonies. Weekly deploys keep the team motivated and users happy. We don't need two-week sprints or elaborate planning poker.
Partner with other teams. I spend as much time with Sales and Customer Success as I do with engineering. They're the ones talking to clients every day. They know what's broken. My job is to translate those problems into solutions.
Where We're Going
PaydFlex is still early. We're processing 30K shifts now, but the market for casual workers in Southeast Asia is massive. Hotels, restaurants, event venues - they all need flexible labor, and the current solutions are fragmented and manual.
The three of us will keep shipping. One feature at a time. One shift at a time.
If you're curious, you can check out PaydFlex on Google Play or the App Store.
Building products with a small team is different from managing large engineering organizations. I'm still figuring out which I prefer. Ask me again in a year.