Maalexi
Designing Infrastructure for Cross-Border Agricultural Trade
When I joined Maalexi, the company was operating at the center of a fragile ecosystem. GCC countries import over 85% of their food supply, representing roughly $60B annually in cross-border trade. Every shipment involves multiple currencies, unverified counterparties, regulatory exposure, and perishable goods.
Year
2024
Project Role
Product Design
Industry
Agri-Tech
The Interface Was Mediating Risk
The real challenge wasn’t complexity, it was consequence. I'll explain further . A moisture miscalculation could reject an entire shipment. A missing document could halt customs clearance. The interface was mediating financial exposure.
When I joined, the product existed but adoption was slow. SME food importers were abandoning onboarding flows, confused by verification requirements, and struggling to navigate data-heavy dashboards. The business problem wasn't product-market fit. It was trust.
A buyer in Dubai committing $40,000 to a shipment of lentils from India, sight unseen, based on a platform they'd never used before — that's the emotional baseline. Every design decision became a negotiation between transparency and cognitive load, verification and friction, sophistication and access.
Design Decisions - PROGRESSIVE ONBOARDING
I redesigned onboarding as progressive disclosure: account creation (name, company, role) → platform exploration (browse commodities, see pricing) → verification (KYC documents, only when needed). Verification fields appeared contextually — trade license upload triggered only after a user expressed interest in a specific deal.
Why it worked : Users could see the platform's value before committing to verification. Browsing products first built confidence. By the time KYC fields appeared, they already wanted in.
Trade-off: Delayed verification created operational overhead for the compliance team. But the business chose growth over operational tidiness — 30% reduction in time-to-first-order validated the choice.
Role-based Dashboards
I introduced role-based default views. Buyers see shipment status and payment tracking. Sellers see inventory and payout timelines. Admins see platform throughput and risk flags. The transaction pipeline became a visual status flow: inquiry → negotiation → payment → shipment → delivery.
Why it worked: Users who found their main workflow in the first session had 18% higher 30-day retention. Role-based views removed the "where do I go?" problem.
Trade-off: Role-based views added engineering complexity — separate data queries, permissions logic, view configurations. But 12% churn reduction justified the technical debt.
Building Features Directly
In a startup moving at 60% monthly growth, the design-to-engineering handoff was a bottleneck. I started building features directly using Supabase, Claude Code, and Lovable — compressing the feedback loop from weeks to days.
Key features shipped:
• Procurement from Origin flow — structured demand capture (commodity type, grade, chemical/physical qualities) reducing post-contract disputes
• Inventory Audit Video App — mobile-first tool for warehouse operators to record inspection videos with automated metadata capture
• Listing page architecture — organized into Discount Offers, Direct from Maalexi, Direct from Seller to clarify trust layers
• Individual buyer/seller pages on maalexi.ai (Claude Code) — public credibility signals (verified licenses, transaction history, trust scores)
• 5 internal ops tools with Lovable: Cheque Management (OCR, 131+ entries, PDF receipts), Cash Receipt Generator, Field Report (Leaflet maps), BYOD form, Employee Entries
Trade-off: Code quality vs. speed. Some features needed refactoring later. But in early-stage startups, speed beats polish. Shipping in days meant tighter user feedback l
What I Gave Up to Get Results
Good design requires sacrifice. Every decision has costs.
Operational Overhead Progressive onboarding improved conversion but created compliance follow-up work. Growth over tidiness. | Engineering Complexity Role-based dashboards required separate queries and permissions. Retention gains justified the technical debt. | Code Quality Building features directly meant some code needed refactoring. Speed over polish in early-stage product. |
Multi-market regulatory complexity: Rather than creating separate flows for each region — which would have been costly and slow to maintain — I designed around the strictest shared requirements. Compliance was introduced progressively, appearing only when relevant to the user’s context. It wasn’t the most elegant solution, but it was practical, scalable, and realistic given the constraints.
Blockchain as infrastructure: Maalexi uses Hedera blockchain for transaction logging, but users don't care about blockchain — they care about reliability. I made it invisible. Transaction receipts show "verified" badges and audit trails. Trust is a feeling, not a feature list.
Reflection
Design is a negotiation between competing priorities.You show enough to guide, but not so much that it overwhelms. You verify identity without turning the process into a barrier. You support advanced users without alienating the majority. They are not problems to eliminate, they are forces to manage. The interface is shaped by how well those trade-offs are handled.
Know why something worked, not just that it worked: Progressive onboarding worked because users saw value before verification. Role-based dashboards worked because they removed navigation friction. Understanding the mechanism makes design repeatable.
Compounding output: Building features directly wasn't about replacing engineers. It was about removing handoff delay. Shipping in days instead of weeks meant tighter feedback loops and a product that stayed responsive to user needs.
What I’d do differently: Set up tracking earlier. If we had clearer data from the start, we would have seen where users were getting stuck and which form fields made them drop off.
That insight would have helped us fix problems faster and make better design decisions sooner.
Over 30%
Time-to-first-order reduction
12%
Churn rate reduction
$3M+
Pre-Series A (Global Ventures)
$14M+
Revenue generated
Maalexi
Designing Infrastructure for Cross-Border Agricultural Trade
When I joined Maalexi, the company was operating at the center of a fragile ecosystem. GCC countries import over 85% of their food supply, representing roughly $60B annually in cross-border trade. Every shipment involves multiple currencies, unverified counterparties, regulatory exposure, and perishable goods.
Year
2024
Project Role
Product Design
Industry
Agri-Tech
The Interface Was Mediating Risk
The real challenge wasn’t complexity, it was consequence. I'll explain further . A moisture miscalculation could reject an entire shipment. A missing document could halt customs clearance. The interface was mediating financial exposure.
When I joined, the product existed but adoption was slow. SME food importers were abandoning onboarding flows, confused by verification requirements, and struggling to navigate data-heavy dashboards. The business problem wasn't product-market fit. It was trust.
A buyer in Dubai committing $40,000 to a shipment of lentils from India, sight unseen, based on a platform they'd never used before — that's the emotional baseline. Every design decision became a negotiation between transparency and cognitive load, verification and friction, sophistication and access.
Design Decisions - PROGRESSIVE ONBOARDING
I redesigned onboarding as progressive disclosure: account creation (name, company, role) → platform exploration (browse commodities, see pricing) → verification (KYC documents, only when needed). Verification fields appeared contextually — trade license upload triggered only after a user expressed interest in a specific deal.
Why it worked : Users could see the platform's value before committing to verification. Browsing products first built confidence. By the time KYC fields appeared, they already wanted in.
Trade-off: Delayed verification created operational overhead for the compliance team. But the business chose growth over operational tidiness — 30% reduction in time-to-first-order validated the choice.
Role-based Dashboards
I introduced role-based default views. Buyers see shipment status and payment tracking. Sellers see inventory and payout timelines. Admins see platform throughput and risk flags. The transaction pipeline became a visual status flow: inquiry → negotiation → payment → shipment → delivery.
Why it worked: Users who found their main workflow in the first session had 18% higher 30-day retention. Role-based views removed the "where do I go?" problem.
Trade-off: Role-based views added engineering complexity — separate data queries, permissions logic, view configurations. But 12% churn reduction justified the technical debt.
Building Features Directly
In a startup moving at 60% monthly growth, the design-to-engineering handoff was a bottleneck. I started building features directly using Supabase, Claude Code, and Lovable — compressing the feedback loop from weeks to days.
Key features shipped:
• Procurement from Origin flow — structured demand capture (commodity type, grade, chemical/physical qualities) reducing post-contract disputes
• Inventory Audit Video App — mobile-first tool for warehouse operators to record inspection videos with automated metadata capture
• Listing page architecture — organized into Discount Offers, Direct from Maalexi, Direct from Seller to clarify trust layers
• Individual buyer/seller pages on maalexi.ai (Claude Code) — public credibility signals (verified licenses, transaction history, trust scores)
• 5 internal ops tools with Lovable: Cheque Management (OCR, 131+ entries, PDF receipts), Cash Receipt Generator, Field Report (Leaflet maps), BYOD form, Employee Entries
Trade-off: Code quality vs. speed. Some features needed refactoring later. But in early-stage startups, speed beats polish. Shipping in days meant tighter user feedback l
What I Gave Up to Get Results
Good design requires sacrifice. Every decision has costs.
Operational Overhead Progressive onboarding improved conversion but created compliance follow-up work. Growth over tidiness. | Engineering Complexity Role-based dashboards required separate queries and permissions. Retention gains justified the technical debt. | Code Quality Building features directly meant some code needed refactoring. Speed over polish in early-stage product. |
Multi-market regulatory complexity: Rather than creating separate flows for each region — which would have been costly and slow to maintain — I designed around the strictest shared requirements. Compliance was introduced progressively, appearing only when relevant to the user’s context. It wasn’t the most elegant solution, but it was practical, scalable, and realistic given the constraints.
Blockchain as infrastructure: Maalexi uses Hedera blockchain for transaction logging, but users don't care about blockchain — they care about reliability. I made it invisible. Transaction receipts show "verified" badges and audit trails. Trust is a feeling, not a feature list.
Reflection
Design is a negotiation between competing priorities.You show enough to guide, but not so much that it overwhelms. You verify identity without turning the process into a barrier. You support advanced users without alienating the majority. They are not problems to eliminate, they are forces to manage. The interface is shaped by how well those trade-offs are handled.
Know why something worked, not just that it worked: Progressive onboarding worked because users saw value before verification. Role-based dashboards worked because they removed navigation friction. Understanding the mechanism makes design repeatable.
Compounding output: Building features directly wasn't about replacing engineers. It was about removing handoff delay. Shipping in days instead of weeks meant tighter feedback loops and a product that stayed responsive to user needs.
What I’d do differently: Set up tracking earlier. If we had clearer data from the start, we would have seen where users were getting stuck and which form fields made them drop off.
That insight would have helped us fix problems faster and make better design decisions sooner.
Over 30%
Time-to-first-order reduction
12%
Churn rate reduction
$3M+
Pre-Series A (Global Ventures)
$14M+
Revenue generated
Maalexi
Designing Infrastructure for Cross-Border Agricultural Trade
When I joined Maalexi, the company was operating at the center of a fragile ecosystem. GCC countries import over 85% of their food supply, representing roughly $60B annually in cross-border trade. Every shipment involves multiple currencies, unverified counterparties, regulatory exposure, and perishable goods.
Year
2024
Project Role
Product Design
Industry
Agri-Tech
The Interface Was Mediating Risk
The real challenge wasn’t complexity, it was consequence. I'll explain further . A moisture miscalculation could reject an entire shipment. A missing document could halt customs clearance. The interface was mediating financial exposure.
When I joined, the product existed but adoption was slow. SME food importers were abandoning onboarding flows, confused by verification requirements, and struggling to navigate data-heavy dashboards. The business problem wasn't product-market fit. It was trust.
A buyer in Dubai committing $40,000 to a shipment of lentils from India, sight unseen, based on a platform they'd never used before — that's the emotional baseline. Every design decision became a negotiation between transparency and cognitive load, verification and friction, sophistication and access.
Design Decisions - PROGRESSIVE ONBOARDING
I redesigned onboarding as progressive disclosure: account creation (name, company, role) → platform exploration (browse commodities, see pricing) → verification (KYC documents, only when needed). Verification fields appeared contextually — trade license upload triggered only after a user expressed interest in a specific deal.
Why it worked : Users could see the platform's value before committing to verification. Browsing products first built confidence. By the time KYC fields appeared, they already wanted in.
Trade-off: Delayed verification created operational overhead for the compliance team. But the business chose growth over operational tidiness — 30% reduction in time-to-first-order validated the choice.
Role-based Dashboards
I introduced role-based default views. Buyers see shipment status and payment tracking. Sellers see inventory and payout timelines. Admins see platform throughput and risk flags. The transaction pipeline became a visual status flow: inquiry → negotiation → payment → shipment → delivery.
Why it worked: Users who found their main workflow in the first session had 18% higher 30-day retention. Role-based views removed the "where do I go?" problem.
Trade-off: Role-based views added engineering complexity — separate data queries, permissions logic, view configurations. But 12% churn reduction justified the technical debt.
Building Features Directly
In a startup moving at 60% monthly growth, the design-to-engineering handoff was a bottleneck. I started building features directly using Supabase, Claude Code, and Lovable — compressing the feedback loop from weeks to days.
Key features shipped:
• Procurement from Origin flow — structured demand capture (commodity type, grade, chemical/physical qualities) reducing post-contract disputes
• Inventory Audit Video App — mobile-first tool for warehouse operators to record inspection videos with automated metadata capture
• Listing page architecture — organized into Discount Offers, Direct from Maalexi, Direct from Seller to clarify trust layers
• Individual buyer/seller pages on maalexi.ai (Claude Code) — public credibility signals (verified licenses, transaction history, trust scores)
• 5 internal ops tools with Lovable: Cheque Management (OCR, 131+ entries, PDF receipts), Cash Receipt Generator, Field Report (Leaflet maps), BYOD form, Employee Entries
Trade-off: Code quality vs. speed. Some features needed refactoring later. But in early-stage startups, speed beats polish. Shipping in days meant tighter user feedback l
What I Gave Up to Get Results
Good design requires sacrifice. Every decision has costs.
Operational Overhead Progressive onboarding improved conversion but created compliance follow-up work. Growth over tidiness. | Engineering Complexity Role-based dashboards required separate queries and permissions. Retention gains justified the technical debt. | Code Quality Building features directly meant some code needed refactoring. Speed over polish in early-stage product. |
Multi-market regulatory complexity: Rather than creating separate flows for each region — which would have been costly and slow to maintain — I designed around the strictest shared requirements. Compliance was introduced progressively, appearing only when relevant to the user’s context. It wasn’t the most elegant solution, but it was practical, scalable, and realistic given the constraints.
Blockchain as infrastructure: Maalexi uses Hedera blockchain for transaction logging, but users don't care about blockchain — they care about reliability. I made it invisible. Transaction receipts show "verified" badges and audit trails. Trust is a feeling, not a feature list.
Reflection
Design is a negotiation between competing priorities.You show enough to guide, but not so much that it overwhelms. You verify identity without turning the process into a barrier. You support advanced users without alienating the majority. They are not problems to eliminate, they are forces to manage. The interface is shaped by how well those trade-offs are handled.
Know why something worked, not just that it worked: Progressive onboarding worked because users saw value before verification. Role-based dashboards worked because they removed navigation friction. Understanding the mechanism makes design repeatable.
Compounding output: Building features directly wasn't about replacing engineers. It was about removing handoff delay. Shipping in days instead of weeks meant tighter feedback loops and a product that stayed responsive to user needs.
What I’d do differently: Set up tracking earlier. If we had clearer data from the start, we would have seen where users were getting stuck and which form fields made them drop off.
That insight would have helped us fix problems faster and make better design decisions sooner.
Over 30%
Time-to-first-order reduction
12%
Churn rate reduction
$3M+
Pre-Series A (Global Ventures)
$14M+
Revenue generated