Most farm software doesn't have to worry about being "enterprise-grade." The bar in Malaysian agriculture is low enough that having any system already puts you ahead. WhatsApp group? That's your communication layer. Excel file on someone's laptop? That's your database.
So when we sat down with a large prospect recently and the conversation shifted from features to security and infrastructure, it was a useful moment. They liked what they saw - the harvest flow, the tree analytics, the map views. The product resonated. But when it came to authentication, access control, and what's running underneath, they wanted to see more.
Fair feedback. And it aligned with what we already had on our roadmap. It just made the priority sharper.
From Shared Access to Organizations
DurianPro used to work on a simple sharing model. One user shares access with another. It was fine for small setups - a farm owner and a handful of workers. But it doesn't scale, and it doesn't give you real control over who can do what.
We replaced it with Organizations. An Org is the central entity now. Under it, there are four roles:
- Owner: Full control. Manages admins and the organization itself.
- Admin: Read and write access across the organization.
- User: Read-only access. Can view data but can't modify it.
- Worker: Isolated read and write access, scoped to their assigned tasks.
This isn't just a label change. It means an admin can manage day-to-day operations without touching org-level settings. A worker can log harvests but can't see the sales figures. A user can pull reports without the risk of accidentally changing data. Each role sees exactly what they need - nothing more.
And because the system was designed for multi-tenancy from day one, adding more roles down the line doesn't require rearchitecting anything.
Workers: More Secure, Still Frictionless
Worker onboarding has always been a design priority for us. A farm manager sends a link, the worker opens it, they're in. No app store, no account creation, no passwords. That hasn't changed.
What changed is what happens behind the scenes.
When a worker opens their link from a new device, we now trigger SMS OTP verification. A 6-digit code gets sent to the phone number their admin registered for them. They enter it, the device gets verified, and they continue as normal. From the worker's side, it's one extra step on their first login. From the admin's side, it means full visibility into which devices have access.
If a worker loses their phone, the admin disables that device. If someone leaves the farm, the admin revokes their access entirely. If a worker tries to log in from an unregistered device, they're blocked until verified.
The whole point is that the people running the farm get control over who has access and from where - without making workers jump through hoops to do their job.
Admin Authentication on AWS Cognito
For admin and user accounts, we moved authentication to AWS Cognito. This replaced the auth system we built ourselves in the early days.
What it means in practice: multi-factor authentication is now supported. Password policies, token management, session handling - all handled by infrastructure that AWS maintains and patches. We don't roll our own crypto, and we don't store passwords.
For a small team, this is the right trade-off. We get security guarantees that would take months to build and maintain ourselves, and we can focus engineering time on the actual product.
Infrastructure
This part is harder to write about, for obvious reasons. We're not going to publish a network diagram. But the broad strokes matter, because they're what separates a prototype from a platform:
- Database: Managed relational database with automated backups. Your data isn't sitting on a single server hoping nothing goes wrong.
- Developer access: Production access no longer goes through SSH. We use session-managed access that's auditable and locked down.
- Traffic: A load balancer sits in front of the application server.
- Storage: All file storage is private, behind a CDN. Nothing is publicly accessible by default.
None of this shows up in the UI. That's the point. Infrastructure should be invisible until the moment it matters - and when it matters, you want to know it's there.
What's Next
The feedback we received didn't change our direction. It confirmed it. Every system we upgraded was already on our roadmap - the conversation just sharpened where to focus first.
Are we done? No. There will always be more to harden, more to audit, more to improve. But the distance between "tool we built for our own farm" and "platform you'd trust with your operation" has closed a lot.
If you're running a large estate and you've been waiting for farm management software that takes security and access control seriously, we'd like to show you where DurianPro is now. We're a small team and we move fast.
Frequently Asked Questions
Does this affect existing users? The migration to Organizations and Cognito has already been handled. Your data and access are intact.
Can I have multiple admins? Yes. An Owner can appoint multiple admins, each with full read and write access.
What if a worker doesn't have a phone number registered? The admin needs to add their phone number first. Without it, device verification can't proceed and the worker will see a prompt to contact their admin.
Is MFA required? It's available and recommended, not forced. We especially recommend it for Owner and Admin accounts.
CJ is a software engineer who co-manages a 350-tree durian estate in Malaysia. He built DurianPro because the tools he needed didn't exist - and now he's making sure they're built to last.