Lead Engineer, Flutter

About Saya

Saya is an online mental health platform in the Philippines, connecting people with licensed psychologists, counsellors, and psychiatrists for video sessions. We're growing quickly, and what the platform needs now is a proper owner on the engineering side.

About the role

This is a senior, hands-on role with real authority: you'll work directly with the founder, own the platform end to end, and make the big architecture, security, and scaling decisions yourself, so it fits someone who wants a whole system under their name and is comfortable carrying that responsibility.

What you'll own

• The system - architecture, data model, infrastructure, cost, and reliability for a live platform with real users and sensitive data
• Scale - the platform needs to be built for many multiples of today's load without a rewrite, and you'll be the one deciding what gets re-architected now and what can wait
• Security and privacy - we hold sensitive mental health data, so access control, audit logging, encryption, and incident response sit at the core of this role
• The mobile app - Flutter, iOS / Android, and you'll be shipping hands-on
• Design collaboration - we have a design system in Figma and a designer you'll work with directly, turning designs into production UI faithfully, and pushing back when a design will hurt performance or conversion
• Integrations - payments (webhooks, idempotency, reconciliation), product analytics, lifecycle messaging, video, and AI features already in production
• Reliability - monitoring, alerting, load, release process, and app store submissions
• Standards and documentation - code review, engineering practices, coordinating our existing developers, and keeping the system documented well enough that the next engineer can pick it up

What we're looking for

• 6+ years building software, with at least 3 shipping Flutter apps that real users depend on, and we'd love to see the apps themselves
• Deep, hands-on experience running a serverless backend on Google Cloud: NoSQL document data modelling, cloud functions, auth, security rules, and keeping the bill under control at scale
• You've designed systems that had to scale, and you can walk us through the tradeoffs you made on consistency, caching, queues, and load
• You've handled sensitive data before (health / financial preferred), and you treat data protection as part of the design from day one
• You've built payment integrations before and understand webhooks, idempotency, and reconciliation well
• You're fluent in Figma as an engineer: design tokens, component libraries, handoff, and implementing a design system accurately
• You take ownership, you're comfortable being the senior technical voice in the room and disagreeing with the founder when needed, and you stand behind your own decisions
• You're comfortable working under a least-privilege setup, where the founder retains ownership of all root accounts and you have full admin access to everything you need
• Clear communication in plain English, since you'll be explaining architecture to non-engineers weekly

Nice to have: Node / TypeScript, data warehousing, mobile CI/CD, integrating LLM APIs into production products, and prior experience in healthtech / fintech.

What we offer

• Full ownership of a live platform, with the authority to actually make it yours
• A direct working relationship with the founder, no layers in between
• Head of Engineering title and team as we grow, starting with you
• Compensation: [range], plus [equity / profit share]
• Remote and async-friendly, with overlap on Philippine hours

Our hiring process

• Short written answers to the two questions below
• A 45-minute call with the founder on architecture and how you think
• A paid half-day exercise on a real problem from our backlog (compensated, of course!)
• Offer within two weeks of step one

How to apply

Send links to apps you've shipped, your GitHub if it's meaningful, and short answers to the following:

• Describe a system you built that had to scale. What were the rough numbers (users, load, cost), what broke first, and what's the one design decision you'd reverse today?
• You're designing a NoSQL document backend where several user roles hold very different permissions over the same records. How do you make sure a client-side bug can never expose one user's records to another, and where do you draw the line between database security rules and server-side access?