My Partner

The challenge

The project brought multiple operator services into one customer-facing application while addressing:

• A large and diverse subscriber base.
• Server optimization and load balancing.
• Integration with Partner’s backend infrastructure.
• An interface that keeps complex telecom tasks understandable.
• Fingerprint, face, and one-time-code login flows.

The solution

moblers combined backend engineering, mobile development, frontend/UI work, and UX design to deliver a centralized self-service application. The published delivery timeline is approximately four months.

Evidence boundary

The public project record confirms the feature set above, work by backend, frontend, UI, and app developers, alignment with Partner’s backend infrastructure, server optimization/load balancing as project concerns, and an approximately four-month delivery.

It does not name the mobile framework or languages, operating-system targets, backend runtime, API style, databases, cloud, operator systems, vendors, deployment tooling, or production KPIs. Those details are not inferred here.

The site separately documents a mobile cybersecurity SDK developed by moblers for Reblaze. The public My Partner project record does not identify Reblaze as a My Partner dependency, mobile SDK, API gateway, or WAF. It must not be presented as an integration in this project without written confirmation.

Technology stack and third-party services

Verified technology boundary

• A customer-facing mobile application.
• Backend engineering aligned with Partner’s existing infrastructure.
• Frontend/UI and app development.
• Fingerprint, facial-recognition, and one-time-code login options.
• Server optimization and load balancing requirements.

Not publicly disclosed

• Mobile approach and languages: native iOS/Android, Swift, Kotlin, React Native, Flutter, or another stack.
• Backend language/runtime and framework: Node.js/Express, Java/Spring, .NET, or another stack.
• API design and transport: REST, GraphQL, gRPC, or another interface.
• Primary database, cache, object storage, queues, and offline-sync design.
• Cloud/hosting provider and deployment model: VMs, containers, Kubernetes, serverless, or other.
• API gateway, CDN, load-balancer product, and autoscaling configuration.
• Analytics, APM, logging, crash reporting, monitoring, and alerting products.
• Push, SMS/OTP, payments, billing, CRM, OSS/BSS, provisioning, roaming, and other third-party providers.
• CI/CD, build, automated testing, release, and infrastructure-as-code tools.

No named framework or vendor should be added solely because it is plausible for a telecom application.

Architecture and integrations

 Partner subscriber
        │
        ▼
 ┌──────────── My Partner mobile app ─────────────┐
 │ account/services │ self-service │ authentication│
 └──────────────────────┬─────────────────────────┘
                        │ API/protocol not public
                        ▼
 ┌──────── integration / backend boundary ────────┐
 │ server optimization and load balancing noted   │
 │ exact topology and components not public       │
 └──────────────┬──────────────────────┬──────────┘
                │                      │
                ▼                      ▼
      Partner account/service     Operator workflows
      systems (names not public)  SIM / roaming / technician

This is a functional data-flow diagram, not the confidential production topology.

Confirmed implementation behavior

1. The mobile application presents account, plan, roaming, and self-service capabilities.
2. It works with Partner’s backend infrastructure.
3. Scalability, server optimization, and load balancing were project requirements.
4. Authentication includes fingerprint, facial recognition, and one-time codes.

Implementation details not public

• Monolith, microservices, serverless, or hybrid topology.
• REST/GraphQL/gRPC schemas, API authentication, OAuth2/JWT use, and session/token lifecycle.
• Direct API, middleware, message-bus, event, or batch-file integration patterns.
• Billing, CRM, provisioning, OSS/BSS, roaming-partner, payment, and technician-system names.
• Cache, CDN, queues, background jobs, load-balancer, autoscaling, and resilience/failover design.
• Logs, metrics, traces, SIEM, on-call, and incident-response process.

Authentication and security

Confirmed user-facing methods: fingerprint, facial recognition, and one-time codes.

The public record does not establish whether biometric matching used native device APIs, a third-party SDK, or server-side identity checks. It also does not name the OTP provider or delivery channel.

The following are not publicly disclosed:

• Authentication/identity SDKs and biometric API implementation.
• OTP generation, delivery, expiry, retry, abuse prevention, and provider.
• TLS version, certificate pinning, encryption at rest, key storage, and secrets management.
• Code obfuscation, anti-tamper, jailbreak/root detection, and runtime protection.
• Reblaze integration or version in My Partner.
• WAF/API protection, bot-detection outcomes, fraud controls, and rate limiting.
• SAST, DAST, dependency scanning, penetration testing, compliance standards, and audit results.
• Privacy, data residency, retention, consent, deletion, and third-party sharing controls.

The phrase “secure login” describes the published authentication options; it is not a claim that any undisclosed control or certification was implemented.

Platforms, launch, and deployment

Confirmed: a mobile application was delivered in approximately four months.

Not publicly disclosed

• Whether the delivered release supported iOS, Android, or both.
• Native versus cross-platform implementation.
• App Store and Google Play URLs, bundle identifiers, version numbers, and rollout regions.
• Project start, beta, launch, and subsequent release dates.
• Progressive/phased versus full rollout.
• CI/CD tooling, signing process, deployment ownership, and release approvals.
• Post-launch maintenance, operations, and support responsibilities.

Store links should be added only after verifying that the listing is the same moblers-delivered product version and that Partner approves publication.

Delivery team and responsibilities

Published roles: moblers backend engineering, frontend development, UI development, app development, and UX/UI design, working with Partner’s specifications and backend infrastructure.

Not publicly disclosed: individual names; headcount by role; Product Owner, Project Manager/Scrum Master, mobile/backend leads, QA and automation staffing; start and milestone dates; responsibility for each integration; operations ownership; and post-launch support terms.

The public timeline is approximately four months. It should not be converted into exact dates without a client-approved project record.

Results and measurable outcomes

Confirmed functional outcome: one mobile self-service experience for data/TV/internet/home-phone plans, international roaming, SIM activation and transfer, account/password updates, technician scheduling, and multiple login options.

No quantitative measurement period or source is published for:

• Downloads, installs, onboarded accounts, MAU, DAU, or subscriber adoption.
• Session duration, task completion, activation time, retention, or engagement.
• API response time, p95 latency, peak concurrency, throughput, or capacity.
• Crash-free rate, error reduction, uptime, or availability SLA.
• Support-ticket or call-center reduction and self-service transaction growth.
• ARPU, churn, revenue, conversion, or cost savings.
• Security incidents, bot attacks blocked, or fraud prevented.
• Time-to-market improvement beyond the published four-month delivery.

The page therefore reports the delivered capabilities and timeline, but does not manufacture business impact. Approved metrics should include the value, cohort, source, and measurement window.

What “unique at the time” means

The earlier project description used “unique mobile app at the time.” The defensible public meaning is that the application combined account management, multiple Partner services, roaming, SIM/service workflows, technician scheduling, and several authentication options in one customer experience.

The record does not publish a competitor comparison, market study, named prior Partner offering, or date-specific feature benchmark. The phrase must not be interpreted as a verified market-first claim.

Publication checklist

To replace the disclosure notes with an engineering- and procurement-ready account, obtain written approval for:

1. Platform and release matrix: iOS/Android, native/cross-platform, store URLs, regions, versions, and launch dates.
2. Stack and topology: mobile/backend technologies, API style, data stores, cloud, scaling, queues, cache, and observability.
3. Integration register: Partner billing/CRM/OSS/BSS/provisioning/roaming systems and each vendor/API.
4. Security statement: authentication providers, biometric/OTP flow, encryption, app hardening, testing, compliance, and any Reblaze relationship.
5. Results report: adoption, performance, stability, availability, support, and business KPIs with sources and dates.
6. Delivery record: role counts, milestones, responsibility split, release model, and support/operations ownership.

Architecture caveats

• The diagram names only published functional boundaries; it does not disclose actual services or network zones.
• “Load balancing” is a published project concern, not confirmation of a specific appliance, cloud service, or algorithm.
• Fingerprint and facial login do not prove a specific biometric SDK or storage model.
• The separate Reblaze SDK project is not evidence that Reblaze was deployed in My Partner.