I co-founded myDaylivery with three partners and shaped the service across web, iOS and Android. The core challenge was coordinating sender, carrier and recipient trust through booking, live status, exceptions and delivery.
Service systemConceptual visualization, not production UI
RoleCo-Founder + Product
ActorsSender, carrier, recipient
SurfacesWeb, iOS, Android
MilestoneB2B beta
01 / Founder context
The product and the business had to grow together
The system connected more than two sides. Senders created demand, commercial couriers or verified private drivers carried out the delivery and recipients needed reliable status and control. Each role saw different information and carried different risk. As a co-founder, I worked across product, service and market boundaries rather than receiving a fixed product brief.
Sender
Create and coordinate
Define the delivery need, provide pickup and destination context and understand who would carry it out.
Courier or driver
Accept and deliver
Evaluate the job, confirm responsibility and act through the mobile workflow.
Recipient
See and respond
Follow progress and stay informed when timing, destination or pickup context changed.
Service
Make trust visible
Identity, insurance, GPS status and ratings had to support confidence across participants who did not know each other.
Shape the service model and product vision with the founding team as the startup moved from concept into the market.
Experience
Connect sender, courier or private driver and recipient needs instead of optimizing one participant in isolation.
Interaction
Develop booking, matching, tracking and coordination flows through low and high-fidelity concepts, wireframes and prototypes.
Trust
Represent identity verification, GPS visibility, insurance, ratings and status changes as understandable product states.
System
Keep the interaction language and service promise coherent across portal, website, iOS, Android and physical touchpoints.
Growth
Own brand and acquisition touchpoints alongside product delivery so market communication matched the actual experience.
Founder product decision
Design the service as one system across both sides and every touchpoint.
The role combined product, service, visual and delivery responsibility. That breadth is the central evidence of ownership, not a single isolated feature.
03 / Product system
A shared model across web, mobile and brand
01Create the request
02Match a verified carrier
03Accept and collect
04Track and coordinate
05Deliver, confirm and rate
Trust layer
Identity
Verification made responsibility legible before a delivery changed hands.
Trust layer
GPS and status
Progress visibility reduced information asymmetry across sender and recipient.
Trust layer
Insurance and ratings
Protection and reputation supported confidence in an unfamiliar service model.
Exception layer
Change requests
Pickup or destination changes were workflow states to manage, not edge cases to ignore.
The diagram is a high-level reconstruction of the documented service ecosystem. It does not reproduce confidential operating processes or production screens.
04 / Outcome
What the evidence supports
From founder concept through system and mobile-app testing to a B2B beta.
These are founding-team milestones, not individual KPI claims. The available evidence supports my responsibility for product and service concepts, web and mobile applications, touchpoint optimization, brand and delivery. No invented revenue, order-volume or user metric is attached.
0-to-1
First concept
Worked with the founding team to shape the business, service and product rather than executing a fixed brief.
Breadth
Multi-actor experience
Connected sender, carrier and recipient needs across the service instead of treating them as unrelated screens.
Surfaces
Web and mobile
Designed across the online portal, website, iOS and Android experiences.
Coherence
Product and brand
Kept the service promise consistent across product, acquisition and physical touchpoints.
