iOS · Objective-C · PostgreSQL · Recommendation UX · Vendor Marketplace · Event Planning
An iPhone wedding-planning application developed in 2017 for Mashhad and surrounding areas, designed to help couples allocate a fixed ceremony budget across multiple service categories, compare vetted local vendors, generate ranked recommendations and packages, and initiate coordinated booking workflows through SMS, Telegram, and automated voice-call channels.
1. Project Overview
Vesalino was a wedding and ceremony planning concept developed for the Mashhad market in 2017.
The business had already collected substantial real-world vendor information through:
- face-to-face interviews,
- direct pricing collection,
- service comparisons,
- and pre-arranged cooperation with local providers.
The digital product was intended to transform that offline research into a guided planning experience.
The central user problem was:
How can a couple plan a ceremony around a fixed budget while balancing competing priorities such as venue, beauty services, clothing, photography, decoration, transportation, and other wedding services?
Rather than presenting only a directory of vendors, Vesalino was designed around a budget-aware recommendation model.
The user could express:
- total budget,
- event date,
- location,
- number of guests,
- service priorities,
- desired service quality,
- and category preferences.
The application would then use that information to generate:
- ranked vendor lists,
- recommended service combinations,
- budget-aware packages,
- and booking / contact workflows.
2. Professional Positioning
The strongest description of Vesalino is:
A budget-aware wedding planning and vendor recommendation application that combined real local vendor data, multi-category preference weighting, ranked recommendations, package generation, and coordinated booking workflows in a native iOS experience.
A weak description would be:
“An iPhone wedding app.”
That misses the core product idea.
The actual concept was closer to:
User Budget
+
Wedding Date
+
Guest Count
+
Location
+
Service Priorities
↓
Preference Weighting
↓
Budget Trade-Off Model
↓
Vendor Ranking
↓
Suggested Packages
↓
Booking / Outreach Workflow
3. Period
2017
4. Geographic Scope
The original business targeted:
Mashhad and surrounding areas
This is important because the recommendation model was based on local vendor data, not generic internet listings.
The platform was built around a regionally curated service ecosystem.
5. Business Model
Vesalino sat between three groups:
Couples / Customers
│
↓
Vesalino Planning Platform
│
↓
Local Wedding-Service Providers
Service providers could include:
- beauty salons,
- bridal dress providers,
- groom clothing providers,
- wedding halls,
- photography studios,
- decorators,
- florists,
- wedding-car services,
- music / entertainment providers,
- catering / pastry / cake providers,
- ceremony designers,
- invitation providers,
- and other event-related businesses.
The business team had direct relationships with many vendors before the mobile application was created.
6. Real Vendor Data
One of the strongest aspects of the concept was the data source.
The business had gathered vendor information through:
- in-person meetings,
- interviews,
- price collection,
- service reviews,
- and operational coordination.
This meant the recommendation layer was intended to operate over real structured marketplace data, not arbitrary public listings.
Conceptually:
Vendor Interviews
+
Real Price Lists
+
Service Metadata
+
Location / Availability
↓
PostgreSQL Database
↓
Recommendation Layer
7. User Inputs
The user planning flow included inputs such as:
- total budget,
- event date,
- Mashhad / surrounding location,
- number of guests,
- preferred service categories,
- importance of each category,
- desired quality level.
This information created the basis for recommendation and package generation.
8. Multi-Category Budget Model
The most distinctive UX idea was a multi-axis visual preference model.
The user could increase the importance of one category—for example:
- beauty salon,
- bridal clothing,
- venue,
- photography,
- decoration,
- or another service.
But the total budget remained fixed.
So increasing one dimension logically reduced the budget available for others.
The concept can be represented as:
Fixed Total Budget
↓
┌──────────────────────────────┐
│ Venue ↑ │
│ Beauty Salon ↑↑ │
│ Photography ↓ │
│ Dress → │
│ Decoration ↓ │
└──────────────────────────────┘
This made the planning interaction explicitly about trade-offs.
9. Polygon / Radar Preference Visualization
The interface used a polygon-like multi-axis visualization.
Each axis represented a wedding-service priority.
The user could conceptually push one axis outward:
Higher Priority
while the model reduced other categories to remain compatible with the available budget.
This is similar to a radar / spider-chart interaction:
Venue
▲
│
Beauty ◄────────┼────────► Photography
│
▼
Clothing
The exact visual implementation should be described from surviving screens if recovered, but the interaction concept is clear:
visualize the balance between multiple competing ceremony priorities under one budget constraint.
10. Why the Budget Interaction Was Important
Wedding planning is not simply:
Choose Best Vendor
It is:
Choose Best Combination
Subject to:
- Budget
- Date
- Location
- Guest Count
- Personal Priorities
That turns the problem into a constrained recommendation problem.
A user who prioritizes a premium salon may need:
- a lower-cost venue,
- simpler decoration,
- or a different photography package.
Vesalino attempted to make those trade-offs visible and interactive.
11. Recommendation Layer
The intended backend logic was described by the original team as an “AI” or analytical intelligence layer.
For accurate portfolio wording, it is better described as:
an analytical recommendation and optimization layer
because the historical evidence does not currently establish a specific machine-learning model.
Its purpose was to combine:
- user budget,
- user priorities,
- vendor pricing,
- vendor category,
- location,
- timing,
- and package compatibility.
The output was intended to include:
- ranked vendor recommendations,
- alternative combinations,
- and complete ceremony packages.
12. Evidence Boundary Around “AI”
Safe wording:
- analytical recommendation logic,
- intelligent matching concept,
- optimization / recommendation layer,
- budget-aware ranking.
Avoid claiming without source evidence:
- machine learning,
- neural networks,
- predictive AI,
- trained recommendation model,
- proprietary AI algorithm.
The project team itself referred to the backend problem as the “AI / analytical intelligence” component, but that layer did not reach reliable synchronization.
13. Vendor Ranking
The platform was intended to provide ranked results.
Ranking could conceptually depend on:
User Priority
+
Budget Fit
+
Vendor Price
+
Category
+
Location
+
Availability
↓
Ranked Results
The exact historical scoring formula is not preserved in the available material and should not be invented.
14. Package Generation
The system also supported the concept of packages.
Instead of choosing every vendor manually, the user could receive a bundled recommendation.
Example concept:
Package A
├── Venue
├── Salon
├── Dress
├── Photography
├── Decoration
└── Transportation
Each package needed to remain consistent with:
- total budget,
- chosen priorities,
- date,
- and location.
15. Compare Before Booking
The onboarding and product language emphasized:
- discovery,
- comparison,
- package selection,
- and discounts.
This positioned Vesalino as more than a directory.
The product was intended to help users move from:
“I need wedding services”
to:
“These are the best-fit combinations for my budget and priorities.”
16. Booking / Appointment Workflow
The business had already coordinated with participating vendors.
When a user wanted to proceed, the backend was intended to send booking/contact requests through multiple communication channels.
Known channels included:
- SMS
- Telegram
- automated voice calls / IVR
Conceptually:
User Selects Vendor / Package
↓
Backend Booking Workflow
↓
┌─────────┼──────────┐
↓ ↓ ↓
SMS Telegram IVR
↓ ↓ ↓
Vendor Contact / Appointment
This is a strong example of multi-channel operational integration.
17. Why Multi-Channel Booking Mattered
In 2017, not every local service provider had:
- a standardized booking API,
- an online calendar,
- or an integrated CRM.
Therefore a practical marketplace could not assume modern API-first vendors.
The design used channels vendors already understood:
- mobile phone,
- SMS,
- Telegram,
- voice calls.
This is a pragmatic bridge between digital consumer UX and semi-manual local business operations.
18. Native iOS Application
The Apple version was built as a native iPhone application.
Confirmed technology:
- Objective-C
- Xcode
- native iOS project structure
The archived project tree includes:
.xcodeproj- application source folders,
- test targets,
- UI test targets,
- image assets,
- logo assets.
19. My Role
My contribution covered everything related to the iPhone experience, plus the visual identity elements requested for the product.
Confirmed responsibilities included:
- vector logo design,
- splash-screen design,
- onboarding design,
- iPhone UI implementation,
- Objective-C application development,
- iOS navigation / screen flow,
- integration preparation for backend data,
- delivery of the iOS source to the customer/team.
The backend recommendation engine and PostgreSQL implementation were not mine.
20. Ownership Boundary
My Work
- Vesalino vector logo
- splash screen
- onboarding screens
- visual design for the iPhone app
- Objective-C iOS implementation
- iOS flow / UI
- application source delivery
Other Team / Business Work
- vendor acquisition,
- vendor interviews,
- price collection,
- PostgreSQL backend,
- recommendation / analytical backend,
- final database synchronization.
This distinction should remain explicit in the portfolio.
21. Brand Identity
The logo was designed as a vector mark.
The visual language used:
- a strong pink / magenta wedding-oriented palette,
- elegant script typography,
- a ring / diamond motif,
- floral decoration,
- a premium ceremony aesthetic.
The brand was intentionally distinct from generic marketplace applications.
22. Splash Screen
The splash design used the Vesalino logo prominently on a clean background.
This established:
- brand recognition,
- premium tone,
- and a polished first impression.
The surviving design source includes CorelDRAW assets and exported images.
23. Onboarding
The application included a multi-step onboarding experience.
Known onboarding messages included themes such as:
- introduction and comparison,
- search and package selection,
- ongoing discounts,
- access to ceremony-related services.
The design used:
- floral imagery,
- soft beige background,
- pink accent colors,
- icon-based feature explanations,
- progress indicators,
- and a clear “Next” action.
24. Onboarding Message — Compare
One onboarding concept was:
Introduce and Compare
The user could discover different ceremony services and compare options before selecting.
This supports the broader marketplace concept.
25. Onboarding Message — Search & Package
Another onboarding concept emphasized:
Search and Package Selection
The user could search for suitable providers and choose packages aligned with budget and preferences.
26. Onboarding Message — Discounts
A third onboarding concept emphasized:
Ongoing Discounts
The business model included negotiated vendor relationships and promotional pricing.
This is consistent with the team having direct contact with local providers.
27. Menu & Navigation
The surviving design shows a side navigation menu with areas such as:
- login,
- membership,
- category selection,
- chats,
- bookmarked items,
- recent views,
- discounts on map,
- notification settings,
- ratings / feedback,
- referrals,
- support,
- about Vesalino,
- collaboration request.
This shows that the intended product scope extended beyond simple browsing.
28. Service Categories
The platform concept covered broad wedding-service categories.
Examples include:
- beauty salons,
- bridal dresses,
- groom clothing,
- venues / halls,
- photography,
- decoration,
- flowers,
- wedding cars,
- music / entertainment,
- cake / pastry,
- invitations,
- ceremony design,
- and related services.
The exact final category taxonomy should be reconstructed from the surviving iOS source if needed.
29. Profile Experience
The surviving profile design includes:
- user identity,
- score / rating,
- followers,
- comments,
- follow action,
- messaging,
- category-related content,
- image galleries.
This suggests the design language included some social / reputation-oriented patterns.
30. Marketplace Discovery
The main-page design indicates category-driven discovery.
Potential user actions included:
- browse popular services,
- view latest discounts,
- open service providers,
- compare options,
- navigate category sections.
This supported both planned and exploratory shopping behavior.
31. PostgreSQL Backend
The backend data store was based on:
- PostgreSQL
The business had entered vendor information into the database.
That data was intended to support:
- pricing,
- categories,
- recommendation,
- package creation,
- booking workflows.
32. Backend Limitation
The project ultimately did not reach a stable production release because the backend recommendation / analytical layer did not synchronize reliably with the rest of the system.
The iPhone client was built, but:
the data and recommendation logic behind the UI were not production-ready.
This is an important distinction.
The iOS project existed.
The full end-to-end product did not successfully launch.
33. Why the Project Did Not Launch
The failure should be documented professionally.
The issue was not that the iOS interface could not be built.
The business team reported difficulty making the analytical recommendation component work reliably with the backend data and application flow.
Therefore:
iOS Client
✓
Brand / UX
✓
Backend Data
Partial
Recommendation Synchronization
✗
Production Launch
✗
34. Project Status
Recommended portfolio status:
Prototype / iOS Client Delivered — Full Platform Not Launched
This is accurate and defensible.
35. Why the Project Still Matters
A project does not need to become a successful business to contain useful engineering evidence.
Vesalino demonstrates:
- native iOS development,
- Objective-C,
- product UX,
- branding,
- multi-step onboarding,
- marketplace discovery,
- budget-aware recommendation design,
- local vendor-data integration,
- and multi-channel booking architecture.
It is especially valuable as evidence of product thinking.
36. Product Thinking
The most interesting part of Vesalino was not its color palette.
It was the attempt to transform a complex planning problem into a constrained recommendation experience.
The user was not just asking:
“Which salon is good?”
The system was trying to answer:
“Given my total budget, date, location, guest count, and priorities, what combination of services makes sense?”
That is a much richer product problem.
37. Information Model
A conceptual data model might have included:
User
├── Budget
├── Event Date
├── Guest Count
├── Location
└── Preferences[]
Vendor
├── Category
├── Price / Price Range
├── Location
├── Services
├── Availability
└── Contact Channels
Package
├── Vendors[]
├── Total Cost
└── Preference Fit
This is a conceptual reconstruction, not a claim about the exact historical schema.
38. Recommendation Problem
The recommendation problem can be described as:
Maximize:
User Preference Fit
Subject To:
Total Package Cost <= User Budget
Date Compatibility
Location Compatibility
Required Categories
This is why the multi-axis priority interaction made sense.
39. Constraint-Based Planning
At a conceptual level:
Budget = Fixed
If:
Salon Priority ↑
then the model may need:
Venue Budget ↓
Decoration Budget ↓
Photography Budget ↓
to maintain the total constraint.
This is one of the strongest portfolio narratives in the project.
40. User-Controlled Trade-Offs
The user could actively shape the recommendation instead of receiving a hidden black-box output.
That is good UX.
Instead of:
System chooses for you
the interaction becomes:
User expresses priorities
↓
System recalculates options
↓
User sees trade-offs
This is more transparent and controllable.
41. Ranking + Package Model
The product supported both:
- individual vendor ranking
- combined package generation
These are different recommendation modes.
Individual ranking answers:
“Which salon best fits me?”
Package generation answers:
“Which complete combination best fits my wedding?”
42. Reservation Orchestration
The project also demonstrates an important marketplace reality:
discovery and booking are not the same problem.
Finding a vendor is digital.
Actually obtaining an appointment may require:
- messaging,
- phone contact,
- vendor confirmation,
- or manual coordination.
The backend intended to orchestrate this through multiple channels.
43. Offline-to-Online Transformation
The business team had already done significant offline work:
Interview Vendors
Collect Prices
Build Relationships
Vesalino attempted to convert that into:
Structured Data
↓
Recommendation
↓
Digital Discovery
↓
Booking
That transformation is a strong product concept.
44. Technology Stack
Confirmed:
- Objective-C
- Xcode
- iOS
- PostgreSQL
- vector graphics / logo design
- image assets
- native iOS source project
Backend communication channels included:
- SMS
- Telegram
- automated voice / IVR
The precise backend programming language is not confirmed and should not be invented.
45. Source Evidence
Surviving artifacts include:
- Xcode project files,
.gitdirectory,- image assets,
- Vesalino logo assets,
- iOS test targets,
- UI test target,
- CorelDRAW logo source,
- PDF / PNG logo exports,
- onboarding screen designs,
- menu design,
- profile design,
- main-page design.
This provides strong visual and source-level evidence for the iOS client work.
46. Source Handoff
The iOS source was delivered to the project team after development.
This matters because the work was not only a design prototype.
It was an implemented client-side codebase that was handed over.
47. Portfolio Classification
Recommended categories:
- Mobile
- iOS
- Marketplace
- Recommendation UX
- Product Design
- Event Technology
Secondary:
- Branding
- Objective-C
- Local Services
- Booking
- Data-Driven Product
48. CV Relevance
Recommended:
Tier B — Strong Portfolio Evidence
Reason:
- native iOS application,
- real customer/team context,
- real vendor dataset,
- sophisticated product concept,
- recommendation / optimization UX,
- booking integration concept.
Not Tier A because:
- full platform did not launch,
- backend recommendation layer was incomplete,
- no production usage evidence.
49. Career Evidence
This project supports evidence of:
- Mobile Engineering
- iOS Development
- Objective-C
- Product Engineering
- UX Design
- Marketplace Design
- Recommendation-System UX
- Constraint-Based Planning
- Branding
- Client Delivery
- Cross-Team Integration
50. Website Hero
Vesalino — Budget-Aware Wedding Planning & Vendor Recommendation
iOS · Objective-C · Wedding Marketplace · Recommendation UX · Booking
Built the native iPhone client and visual identity for a wedding-planning platform that matched couples with vetted local vendors based on budget, date, guest count, location, and service priorities. The concept combined a multi-axis budget-allocation interface, ranked vendor recommendations, package generation, and multi-channel booking workflows.
51. Website Project Card
Vesalino
iOS · Objective-C · Recommendation UX · Wedding Services Marketplace
Developed the native iPhone experience for a budget-aware wedding planning platform that ranked local vendors and generated service packages based on user priorities and ceremony constraints.
52. Short Website Card
Vesalino
A native iOS wedding-planning application with budget-aware category weighting, vendor ranking, package recommendations, and coordinated booking workflows.
53. One-Line Description
Built the Objective-C iPhone client for a budget-aware wedding-services recommendation platform using real local vendor data and multi-category planning constraints.
54. CV Entry
Vesalino — iOS Wedding Planning & Recommendation Platform
Developed the native Objective-C iPhone client and visual identity for a wedding-planning marketplace serving Mashhad. Designed the logo, splash, onboarding, navigation, vendor-discovery UX, and budget-priority interaction for a system intended to rank vetted local providers and generate ceremony packages from real vendor pricing, user budgets, event dates, guest counts, and category priorities. The full platform did not launch because the backend analytical/recommendation layer was not completed reliably.
55. Short CV Entry
Built an Objective-C iOS client for a budget-aware wedding-services recommendation platform with vendor ranking, package generation, booking workflows, and custom visual identity.
56. Design-Focused CV Entry
Designed Vesalino’s vector brand identity and native iOS UX, including splash, onboarding, navigation, vendor discovery, profiles, category flows, and a multi-axis budget-priority interaction.
57. Interview Story — Situation
A wedding-services startup in Mashhad had collected detailed vendor information, pricing, and cooperation agreements through direct interviews.
They wanted to turn that offline dataset into a mobile planning product.
58. Interview Story — Task
My responsibility was everything related to the iPhone version, plus the logo and first-run visual experience.
The client needed to present a complex planning concept in a user-friendly way.
59. Interview Story — Action
I created the Vesalino vector logo, designed the splash and onboarding screens, and implemented the iPhone application in Objective-C.
The product concept allowed users to enter their budget, wedding date, guest count, location, and service priorities.
A multi-axis visual model represented those priorities. Increasing one category reduced room for others under the fixed budget.
The intended backend would rank vendors and generate packages, while booking requests could be routed to vendors through SMS, Telegram, and automated voice calls.
60. Interview Story — Result
The iOS client was implemented and source-delivered.
However, the overall product did not reach a stable market release because the backend analytical/recommendation component and database synchronization were not completed reliably.
61. Technical Interview Version
“The interesting part of Vesalino was the planning model. A user had one fixed ceremony budget but multiple competing priorities—venue, beauty salon, clothing, photography, decoration, and so on. We represented that as a multi-axis preference model. If the user pushed one category higher, other categories had to move down because the total budget remained fixed. The business had already collected real vendor pricing and interview data in Mashhad, and the backend was intended to rank vendors and generate packages. I built the native iPhone side in Objective-C, including the logo, splash, onboarding, and application UX. The product did not fully launch because the backend recommendation layer never synchronized reliably with the data and client.”
62. Product Interview Angle
A useful product lesson from the project is:
Users understand trade-offs better when they can manipulate them directly.
Rather than entering a long preference form, the polygon-style interaction made the budget trade-off visible.
63. Architecture Lesson
Another useful lesson:
A polished client cannot compensate for an unstable recommendation/data layer.
The iOS interface could be completed, but the overall product depended on:
- clean vendor data,
- synchronized pricing,
- reliable ranking,
- and consistent backend outputs.
When that foundation was not reliable, the application could not become a dependable production product.
64. V2 — Modern Rebuild Concept
A modern rebuild should separate four concerns:
Vendor Data
Recommendation Engine
Booking Orchestration
Client Applications
Recommended architecture:
iOS / Web Client
↓
API Gateway
↓
Recommendation Service
↓
PostgreSQL
↓
Booking Orchestrator
↓
SMS / Messaging / Voice
65. V2 — Structured Vendor Model
A modern vendor model might include:
Vendor
├── category
├── service_area
├── price_range
├── packages
├── capacity
├── availability
├── rating
├── location
└── booking_channels
66. V2 — Structured User Preference Model
WeddingPlan
├── total_budget
├── date
├── location
├── guest_count
└── priorities[]
Each priority could have a normalized weight:
Venue 0.30
Salon 0.25
Photography 0.20
Dress 0.15
Decoration 0.10
67. V2 — Recommendation Model
A modern explainable model could score vendors using:
Budget Fit
+
Priority Weight
+
Availability
+
Location Fit
+
Quality / Rating
+
Package Compatibility
The key design principle should be:
explainable recommendations rather than opaque scoring.
68. V2 — Package Optimizer
Package generation could be formulated as a constrained optimization problem:
Maximize:
Σ preference_weight × vendor_score
Subject to:
Σ selected_service_cost <= total_budget
date_available = true
service_area_match = true
required_categories_covered = true
This would formalize the original idea more reliably.
69. V2 — Booking Orchestration
A modern booking layer should abstract communication channels:
Booking Request
↓
Vendor Contact Adapter
├── API
├── SMS
├── WhatsApp / Telegram
├── Email
└── IVR
This avoids coupling business logic to one communication method.
70. V2 — Admin Back Office
The admin environment should manage:
- vendors,
- pricing,
- service areas,
- packages,
- availability,
- booking status,
- recommendation quality,
- customer feedback,
- discounts.
71. V2 — Data Quality
The original concept depended heavily on high-quality vendor data.
A modern system should track:
- last price verification date,
- source of price,
- vendor confirmation state,
- availability freshness,
- active/inactive status.
Without that, recommendation quality degrades quickly.
72. V2 — Auditability
Because budget recommendations affect user decisions, each recommendation should be reproducible.
Store:
Input Preferences
+
Vendor Snapshot
+
Scoring Version
+
Recommendation Result
This allows debugging and product improvement.
73. V2 — Analytics
Useful analytics could include:
- most prioritized categories,
- average ceremony budget,
- package conversion rate,
- vendor click-through,
- booking acceptance rate,
- price-change frequency,
- recommendation abandonment rate.
74. V2 — UX Modernization
The multi-axis concept should be preserved, but modernized.
Possible interaction:
- draggable radar chart,
- live budget allocation,
- category sliders,
- instant package recalculation,
- visual remaining budget,
- comparison cards.
The strongest part of the original concept is worth retaining.
75. Why This Project Is Distinctive
Vesalino is distinctive because it combined:
- local marketplace data,
- ceremony planning,
- budget allocation,
- preference visualization,
- recommendation,
- ranking,
- package generation,
- and multi-channel booking.
That is much more sophisticated than a directory of wedding vendors.
76. Suggested Portfolio Tags
iOS
Objective-C
Xcode
PostgreSQL
Wedding Planning
Marketplace
Recommendation System UX
Budget Optimization
Vendor Ranking
Package Generation
Booking Workflow
SMS
Telegram
IVR
Brand Identity
Vector Logo
Mobile UX
Product Design
77. Suggested Website Metadata
Page Title
Vesalino — Budget-Aware Wedding Planning & Vendor Recommendation
Meta Description
A native Objective-C iPhone application for wedding planning in Mashhad, combining real vendor data, budget-aware category weighting, ranked recommendations, package generation, and multi-channel booking workflows.
Suggested Slug
/vesalino
Alternative:
/projects/vesalino-wedding-planning
78. Evidence Boundaries
Safe to claim:
- 2017,
- Mashhad and surrounding areas,
- native iPhone application,
- Objective-C,
- Xcode,
- vector logo created by me,
- splash and onboarding created by me,
- iOS application implemented by me,
- PostgreSQL backend existed,
- vendor price/interview data existed,
- recommendation concept used user budget and priorities,
- polygon / multi-axis preference concept,
- ranked results,
- package generation concept,
- SMS / Telegram / IVR booking communication,
- source handed over,
- full platform did not launch.
Avoid claiming without evidence:
- production users,
- successful commercial launch,
- machine learning,
- trained AI model,
- exact recommendation algorithm,
- exact vendor count,
- exact booking volume,
- exact source-level backend architecture.
79. Recommended Status
iOS Client Delivered / Platform Prototype
Optional wording:
Native iOS client completed; full platform rollout blocked by incomplete backend recommendation synchronization.
80. Final Portfolio Statement
Vesalino was a 2017 iPhone wedding-planning application for Mashhad and surrounding areas, designed around a budget-aware recommendation model rather than a simple vendor directory. Users could define ceremony budget, date, guest count, location, and category priorities, then adjust those priorities through a multi-axis visual model in which increasing one service category reduced budget room for others. The business had already collected real vendor pricing and interview data in PostgreSQL and intended to generate ranked vendor recommendations and complete ceremony packages, with booking requests routed through SMS, Telegram, and automated voice channels. I designed the vector logo, splash and onboarding experience, and implemented the native iOS client in Objective-C. The client source was delivered, but the full platform did not launch because the backend analytical/recommendation layer never reached reliable synchronization with the data and application flow.
81. One-Line Summary
Built the Objective-C iPhone client for a budget-aware wedding planning platform that combined local vendor data, multi-axis preference weighting, ranked recommendations, package generation, and coordinated booking workflows.
82. Ultra-Short Portfolio Label
Vesalino — iOS Wedding Planning · Budget Optimization · Vendor Recommendation