The Spark: Why Build a Wedding Planning Tool for the Philippines?
It started at a family reunion. My cousin was getting married, and I watched her juggle three different notebooks, a Google Sheet that hadn't been updated in weeks, and a Facebook Messenger group with 47 unread messages from suppliers. She was stressed, overwhelmed, and spending more time coordinating logistics than actually enjoying her engagement.
I asked her: "Why not use one of those wedding planning apps?"
She laughed. "Which one? The one that thinks my budget is in dollars? The one that doesn't know what a ninong is? Or the one where I can't even pay because it only takes credit cards?"
That conversation planted the seed. I started asking around — talking to recently married friends, wedding coordinators, even random couples at bridal fairs. The pattern was the same everywhere: Filipino couples were underserved by existing wedding planning tools. The global platforms assumed American customs, USD pricing, and credit card payments. None of them understood what it meant to plan a Filipino wedding.
So I decided to build WedPlanner.ph — the first online wedding planning tool built specifically for the Philippine market.
Lesson 1: Currency Isn't Just a Dropdown — It's a Mental Model
The first localization challenge I hit was deceptively simple: currency.
Most SaaS platforms treat currency as a display setting — swap the $ for ₱ and call it done. But that completely misses how Filipinos think about money in the context of weddings.
In the Philippines, wedding budgets aren't discussed in round numbers like $20,000 or $30,000. They're discussed in hundreds of thousands of pesos. A "modest" wedding might be ₱300,000. A "grand" one could be ₱1,500,000 or more. When you're dealing with six and seven-figure numbers, the UI needs to handle them gracefully.
Here's what I learned:
Comma placement matters. ₱1,500,000 reads differently than ₱1500000. The formatting isn't cosmetic — it's a readability requirement when numbers get this large. I had to ensure every budget field, every chart, every summary card displayed properly formatted PHP amounts with the peso sign, commas, and two decimal places.
Budget categories are different. Filipino weddings have expense categories that don't exist in Western tools. The sagala (entourage) attire budget. The arras and cord ceremony items. The principal sponsors gifts. The pamamanhikan dinner. I couldn't just translate labels — I had to restructure the entire budget taxonomy.
Payment tracking is multi-stage. Filipino couples typically pay suppliers in installments: a down payment to book, a partial payment midway, and the balance on or before the wedding day. The budget tool needed to track not just "paid vs unpaid" but which installment was due when. I built a payment schedule system that shows upcoming due dates, amounts paid, and remaining balances per supplier — something no generic budgeting tool offered.
The technical takeaway: localization isn't translation. It's understanding the user's mental model and building your data structures around it.
Lesson 2: Filipino Wedding Customs Are Not "Edge Cases"
When I started building the checklist feature, I naively thought I could take a standard wedding checklist template and "localize" it. I was wrong.
A Filipino wedding isn't just a Western wedding with different labels. It's a fundamentally different event with its own structure, timeline, and cast of characters.
Here's what I had to build from scratch:
The entourage system. A Filipino wedding party isn't just bridesmaids and groomsmen. You have principal sponsors (ninongs and ninangs) — usually 2-4 pairs of older, respected couples who serve as witnesses and mentors. You have secondary sponsors for the cord, veil, and candle ceremonies. You have bearers for the arrhae (coins), Bible, and ring. The guest management system needed to track all these roles, their relationships to the couple, and their specific ceremony duties.
The legal document maze. Getting married in the Philippines involves a specific paper trail: PSA birth certificates, CENOMAR (Certificate of No Marriage), marriage license from the local civil registrar, pre-Cana seminar certificate, and parental consent or advice depending on age. The checklist needed to include all of these with accurate timelines — the marriage license has a 120-day validity window, and the CENOMAR takes 2-3 weeks to process.
The pre-wedding events. Filipino weddings don't start on the wedding day. There's the pamamanhikan (formal meeting of families), the despedida de soltera (send-off party), and often a separate civil wedding before the church ceremony. Each of these has its own planning requirements, guest lists, and budgets.
The reception program. Filipino wedding receptions follow a specific flow: the grand entrance, the money dance, the bouquet and garter toss, the pa-games (audience games), and the midnight snack. The timeline tool needed to accommodate this structure, not a generic "cocktail hour → dinner → dancing" template.
I ended up building a checklist with 149 tasks across 16 categories, all specific to Filipino weddings. It was more work than I expected, but it's also the feature couples tell me they value most. When a tool actually understands your wedding, you trust it more.
Lesson 3: GCash Integration — The Payment Layer Nobody Talks About
This was the hardest technical challenge, and the one that taught me the most about building for emerging markets.
In the Philippines, credit card penetration is around 3-5%. But smartphone penetration is over 70%, and GCash has over 90 million registered users. If you're building a SaaS product for the Philippine market and you only accept credit cards, you're excluding 95%+ of your potential users.
Integrating GCash into WedPlanner.ph wasn't just about adding a payment method. It was about rethinking the entire payment flow.
The technical reality. GCash doesn't have a Stripe-like API with clean documentation and SDKs in every language. The integration options are:
- GCash via PayMongo or Xendit (payment gateways that wrap GCash)
- GCash QR code generation
- Direct GCash API (requires business approval and volume commitments)
I went with PayMongo as the payment gateway, which provides a unified API for GCash, GrabPay, Maya, and card payments. This gave me a single integration point while supporting all the payment methods Filipino couples actually use.
The UX challenge. GCash payments work differently from credit cards. The user gets redirected to the GCash app (or a web flow), authenticates, and confirms the payment. This means your application needs to handle:
- Redirect flows with proper callback URLs
- Payment status polling (GCash payments aren't always instant)
- Timeout handling (users might close the app and forget to complete payment)
- Reconciliation when the payment succeeds but the callback fails
I built a payment status system that polls every 5 seconds for up to 2 minutes after a redirect, with exponential backoff. If the payment doesn't confirm within that window, the system marks it as "pending" and the user can check back later. Not elegant, but it works reliably.
The pricing model shift. This was the unexpected lesson. When I first launched, I offered monthly subscriptions — standard SaaS pricing. But Filipino couples don't think in monthly subscriptions for wedding planning. They think in one-time purchases: "How much does it cost to plan my wedding?"
I shifted to a one-time payment model: pay once, get lifetime access to plan your wedding. The conversion rate tripled. It turns out that matching the payment model to the local purchasing behavior matters as much as matching the payment method.
The numbers that surprised me. After launching GCash support, 78% of payments came through GCash or Maya. Only 12% used credit cards. The remaining 10% used bank transfers. If I had launched with credit cards only, I would have lost nearly 9 out of 10 customers.
Lesson 4: The Metro Manila vs. Province Divide
Here's something I didn't anticipate: the Philippines isn't one market. It's at least two.
Couples in Metro Manila have different needs from couples in the provinces. Manila couples tend to have higher budgets, more supplier options, and faster internet. Province couples often plan weddings in venues with limited connectivity, rely more on family recommendations than online directories, and have different vendor ecosystems.
This affected several design decisions:
Offline-first architecture. I built the checklist and budget tools to work offline with local storage, syncing when connectivity returns. This was critical for couples in areas with spotty internet — they can plan at home, sync when they get to a café or office with better connection.
Vendor directory by city, not just category. The vendor directory on WedPlanner.ph lets couples filter by both category and city. A photographer in Davao isn't useful to a couple in Ilocos. The directory now lists over 1,000 suppliers across the Philippines, organized geographically.
Language considerations. While the platform is in English, I learned that many couples and suppliers communicate in Taglish (Tagalog-English mix). The RSVP system and wedding website builder needed to support mixed-language content without breaking. I had to ensure UTF-8 handling was solid throughout the stack and that form validation didn't reject Tagalog names or addresses.
Lesson 5: Building in Public Works — But Only If You're Honest
I started sharing the build process on dev.to and Twitter about three months into development. The response surprised me.
The posts that got the most engagement weren't the polished "we launched!" announcements. They were the messy ones: the post about how I spent three days debugging a GCash webhook that turned out to be a missing trailing slash in the callback URL. The thread about realizing my budget categories were completely wrong after talking to five actual couples. The confession that I built an entire RSVP feature before learning that Filipino guests don't RSVP — you have to chase them individually.
Building in public forced me to stay close to real users. Every time I wrote about a feature, I'd get comments from Filipino developers and couples sharing their own experiences. Some of the best features — like the payment installment tracker and the ninong/ninang role system — came directly from those conversations.
If you're building a localized SaaS product, my advice is: don't build in isolation. Share early, share honestly, and let your target users correct your assumptions before you write too much code.
What I'd Do Differently
Looking back, there are a few things I'd change:
Start with payments, not features. I spent the first two months building features before integrating GCash. I should have done it the other way around — payment integration surfaced so many UX and architecture decisions that I had to refactor later.
Talk to 50 couples before writing a single line of code. I talked to about 10 people before starting. That wasn't enough. The real insights — the installment payment patterns, the province connectivity issues, the Taglish content needs — only emerged after deeper conversations.
Don't assume "SaaS best practices" apply everywhere. Monthly subscriptions, credit card payments, email-based onboarding — these are SaaS defaults that work in Silicon Valley but not necessarily in the Philippines. Question every assumption.
The Road Ahead
WedPlanner.ph is still early. We're adding features based on what couples actually ask for — better seating chart tools, a more comprehensive vendor directory, and deeper GCash/Maya integration for supplier payments. The planning tips blog is growing with content that actually helps Filipino couples navigate their wedding journey.
The biggest lesson from this whole experience? Localization isn't a feature you add at the end. It's the foundation you build on. If you're building for a specific market, don't start with a generic product and "adapt" it. Start with the market's specific needs and build outward from there.
Have you built a product for a specific local market? What localization challenges surprised you? I'd love to hear about it in the comments.
Top comments (0)