Why We Decided to Build Products
ME-Tech has always been a services business — clients bring problems, we build solutions. For most of our history, we've been proud of that model. But around 2018, we noticed a pattern: the most interesting engineering problems we were solving were variations of the same core challenges around real-time booking, marketplace dynamics, and mobile-first UX. We were solving them for clients. We decided to solve them for ourselves too.
SenangApps is the umbrella brand for ME-Tech's consumer product portfolio. The name is intentional — "senang" means easy in Malay, and ease-of-use is the product thesis across all six apps. We're building products in categories where existing options are technically adequate but operationally frustrating.
The Six Apps and What They Proved
The portfolio currently spans transport, home services, food, and property rentals. Each app has been different in market dynamics, but similar in technical architecture — React Native front-ends backed by Node.js microservices, with shared infrastructure for authentication, payments, and notifications.
What we've learned from shipping consumer apps differs significantly from enterprise work. In enterprise, requirements come from a named stakeholder. In consumer, requirements come from user behaviour — and users don't tell you why they're churning, they just stop opening the app. Building robust product analytics from day one is not optional; it's the product manager's primary instrument.
The App Store Is a Different Kind of Client
Our first iOS submission took four rounds of review over three weeks. The rejections were about metadata, not functionality — screenshot dimensions, app preview content, keyword stuffing in the title. None of this was in our standard delivery checklist because none of our enterprise clients use the App Store.
We now run every new app through an internal App Store readiness checklist before submission: guideline 2.1 (functionality), 4.0 (design), 5.1 (privacy), and the Malaysian-specific data residency considerations for apps handling personal data. The checklist has halved our review cycle time across subsequent releases.
Real-Time Demand Matching Is Hard
ServisJer (home services) and SewaJer (vehicle rentals) both involve real-time demand matching — a customer requests a service, the platform finds and dispatches a provider. The core challenge is: how do you handle a customer-facing request when provider availability is uncertain?
We experimented with three approaches before settling on a hybrid model: optimistic assignment with a timeout fallback. The customer sees an estimated provider immediately (optimistic), while the platform negotiates with available providers in the background. If a provider confirms within the timeout window, the estimate becomes a confirmed booking. If not, the customer is shown a revised estimate or offered to wait. This model produces better UX than pessimistic matching (which makes the customer wait before showing anything) while being honest about uncertainty.
What Running Products Has Made Us Better At
The most direct benefit to our clients has been our operational maturity. When you run consumer products at scale, you develop instincts about: mobile network reliability, payment gateway failure modes, push notification deliverability, App Store review dynamics, and the cost of poor error handling in production. These instincts are difficult to develop through client work alone.
SenangApps is also where we pilot new technologies before recommending them to clients. Expo SDK migrations, React Native New Architecture adoption, new payment gateway integrations — we test them in our own products first. The feedback loop is honest: if something breaks in production, it's our reputation on the line, not a client's.