DEV Community: Jay Artiaga

Building a Wedding Planning Tool for the Philippine Market: What I Learned About Localizing SaaS

Jay Artiaga — Tue, 11 Aug 2026 21:10:33 +0000

Why I Decided to Build for the Philippine Wedding Market

Six months ago, I sat in a coffee shop in Makati watching my cousin scroll through three different spreadsheets, two Facebook groups, and a GCash transaction history — all just to figure out how much of her wedding budget was left. She had 450 guests on her list (Filipino weddings are not small affairs), 12 principal sponsors to coordinate, and a venue in Tagaytay that only accepted bank transfers. The existing wedding planning tools? They assumed dollars, credit cards, and 150-guest maximums.

That was the moment I decided to build WedPlanner — the first online wedding planning tool built specifically for Filipino weddings. I'm a full-stack developer who's built SaaS products before, but nothing prepared me for what localization actually means when you're building for a market that the global SaaS playbook simply doesn't cover.

This is what I learned.

Lesson 1: Currency Isn't Just a Display Format

My first instinct was naive. "I'll just add PHP as a currency option," I thought. Change the dollar sign to a peso sign, add a dropdown, done. That took about 20 minutes to implement and about two days to realize was completely wrong.

The Philippine peso doesn't behave like the dollar. A typical Filipino wedding budget ranges from ₱50,000 to ₱500,000 — that's five to six digits, not four. When you're displaying ₱350,000 in a budget tracker, the UI needs to handle large numbers gracefully. Decimal places matter differently: nobody budgets in centavos for a wedding, so showing ₱150,000.00 is just visual noise.

But the real challenge was the mental math. Filipino couples don't think in "per-head" costs the way Western couples do. They think in packages: "The caterer charges ₱450 per head for 300 guests, but Tita Linda is bringing lechon, so subtract 50 heads from the catering count." The budget tool needed to support per-head calculations, package deals, and the Filipino tradition of relatives contributing food, decorations, or services — what we call "pakiusap" arrangements.

I ended up building a flexible line-item system where each budget entry could be tagged as per-head, fixed-cost, or contributed. The contributed items still show in the total budget (so couples know the real cost) but get marked as covered. This single feature took three iterations to get right, and it's now the most-used part of the app.

Lesson 2: Payment Integration Means GCash, Not Stripe

Here's a stat that shocked me when I started researching: as of 2025, GCash had over 90 million registered users in the Philippines. For context, that's roughly 80% of the entire population. Maya (formerly PayMaya) adds another 60+ million. Meanwhile, credit card penetration in the Philippines hovers around 5-8%.

If you're building a SaaS for the Philippine market and your payment strategy is "integrate Stripe," you've already lost 90% of your potential users before you've written a line of code.

Integrating GCash wasn't straightforward. The GCash API documentation is... let's call it "evolving." There's a sandbox environment, but it behaves differently from production in ways that aren't documented. Webhook reliability varies. The QR code payment flow works differently on Android vs iOS. And the refund process? Let's just say I have a dedicated error-handling module just for GCash edge cases.

I also learned that Filipino users have a specific payment behavior: they want to see the total in pesos before they commit to anything, and they want a QR code they can scan with their phone — not a form where they type in their GCash number. The UX flow that works in the US (enter card → confirm → done) doesn't map to how Filipinos actually pay. I had to redesign the entire checkout to be QR-first, with manual entry as a fallback.

For the wedding registry feature, I integrated both GCash and Maya so guests can contribute cash gifts directly. This is culturally important — Filipino weddings commonly include a "money dance" where guests pin cash on the couple, and digital cash gifts are the modern equivalent. Building that feature taught me that payment integration isn't just technical plumbing; it's cultural infrastructure.

Lesson 3: Filipino Wedding Customs Are Data Models

I underestimated this one badly. A Western wedding planning tool needs to track: bride, groom, venue, date, guest list. A Filipino wedding planning tool needs to track all of that plus:

Principal sponsors (Ninong and Ninang): These aren't just guests. They're part of the ceremony, they sign the marriage contract, and couples typically have 4-8 pairs. Each pair needs to be tracked with their role, contact info, and whether they've confirmed.
Secondary sponsors: Candle, cord, and veil sponsors — three separate pairs who participate in specific Catholic ceremony rituals. Yes, this is a separate data entity from principal sponsors.
The entourage: Not just bridesmaids and groomsmen. Filipino weddings have flower girls, ring bearers, coin bearers, Bible bearers — each with specific roles in the ceremony procession.
Pamamanhikan: The formal meeting where both families discuss the wedding. This happens months before the wedding and involves its own set of logistics, attendees, and sometimes even a separate budget.

I had to model all of this in the database. The guest list alone has a role_type enum with 12 different values. The seating chart feature needed to handle the head table differently — in Filipino weddings, the principal sponsors often sit at the head table alongside the couple, not the bridal party. Western seating chart algorithms assume a sweetheart table or a bridal-party head table. Neither assumption holds.

The lesson here: localization isn't translation. It's rebuilding your data model to match how people actually live. If your database schema assumes a nuclear-family wedding with 100 guests, you haven't built a Filipino wedding tool — you've built a tool that Filipino couples will fight against.

Lesson 4: The Metro Manila vs. Province Divide Is Real

One of the most humbling discoveries was how different wedding planning looks depending on whether you're in Metro Manila or the provinces.

In Metro Manila, couples are dealing with traffic logistics, venue parking, and whether their Tagaytay venue has backup generators for the summer brownouts. In the provinces, couples are dealing with whether the local church has enough parking for 300 guests, whether the caterer can travel 2 hours from the city, and whether there's reliable internet for the supplier's online payment terminal.

This split showed up in my analytics in a way I didn't expect. Metro Manila users spent most of their time on the budget tracker and vendor comparison features. Province users spent most of their time on the checklist and timeline features — they needed help with the process of planning, not just the numbers.

I had to build the onboarding flow to ask "Where is your wedding?" early, and then customize the feature prominence based on the answer. A couple planning in Baguio sees the vendor directory and weather planning tools first. A couple planning in Makati sees the budget tracker and venue comparison first. This kind of regional customization is something I never would have thought to build if I'd followed a generic SaaS playbook.

Lesson 5: Building in Public Works Differently in the Philippines

I'm a believer in building in public. I tweet about my progress, share revenue numbers, and post technical deep-dives. But I learned quickly that the "build in public" playbook — the one popularized by Western indie hackers on Twitter — doesn't translate one-to-one in the Philippine context.

First, the platforms are different. Filipino wedding planning happens on Facebook groups, not Twitter or Reddit. There are Facebook groups with 50,000+ members dedicated to wedding planning in the Philippines. If you want feedback from actual users, that's where you go — not Product Hunt, not Hacker News.

Second, the trust dynamic is different. Filipino couples planning a wedding are making the biggest financial decision of their lives (the average Filipino wedding costs ₱200,000-₱500,000, which is often 1-2 years of household income). They don't want to see "MVP" or "beta" anywhere near a tool they're trusting with their wedding. I had to be more polished before sharing publicly than the typical indie hacker advice suggests.

Third, word of mouth works differently. In the Philippines, a recommendation from a "Tita" (aunt) in a Facebook group carries more weight than any SEO strategy or ad campaign. I learned to build features that are inherently shareable — the wedding website with RSVP became my primary growth engine because couples would share their wedding website link, and their guests would see "Powered by WedPlanner" at the bottom. Every wedding became a demo for 300+ potential users.

What I'd Do Differently

If I were starting over tomorrow, here's what I'd change:

Start with the data model, not the UI. I spent weeks polishing the dashboard before realizing my guest model couldn't handle principal sponsors. Model the culture first, then build the interface.
Integrate GCash on day one. I waited until I had "enough users" to justify the integration work. In hindsight, GCash is the payment method for my market. Delaying it was delaying product-market fit.
Spend more time in Facebook groups before writing code. The most valuable product insights came from reading 50+ posts in wedding planning groups, not from competitor analysis or analytics dashboards.
Build for mobile-first from the start. Over 70% of my users access the platform on mobile. I built desktop-first and had to retrofit responsive design. Don't be me.

The Numbers (Because Building in Public Means Sharing)

I believe in transparency, so here's where WedPlanner stands as of August 2026:

Active users: 1,200+ couples planning their weddings
Weddings planned: 340+ completed weddings tracked through the platform
Average wedding budget managed: ₱285,000
Most-used feature: Budget tracker (used by 89% of active users)
Fastest-growing feature: Wedding planning guides and checklists
Tech stack: Next.js, PostgreSQL, Prisma, GCash API, Maya API, Vercel

I'm not at "ramen profitability" yet, but the trajectory is promising. The Philippine wedding industry is a ₱100+ billion market, and the digital tools serving it are still in their infancy. There's room to build something meaningful here.

What's Next

I'm currently working on:

Supplier marketplace: A vetted directory where couples can find and book photographers, coordinators, and caterers directly through the platform
AI-powered timeline generator: Input your wedding date and venue, get a personalized 12-month planning timeline with local vendor recommendations
Multi-language support: Filipino (Tagalog) and Cebuano interfaces, because not every couple plans their wedding in English

Building for the Philippine market has been the hardest and most rewarding technical challenge of my career. The problems are real, the users are passionate, and the gap between what exists and what's needed is enormous.

If you're building a SaaS for a market that the global playbook ignores, my advice is simple: go deep on the culture before you go wide on the features. The localization work that feels like "edge cases" to a Silicon Valley product manager is the entire product for your users.

Have you built a product for a market that required deep localization? I'd love to hear about your experience in the comments — especially the things you didn't expect to be hard that turned out to be the hardest part.

Building a Wedding Planning Tool for the Philippine Market: What I Learned About Localizing SaaS

Jay Artiaga — Tue, 11 Aug 2026 20:08:50 +0000

When I first sat down to build WedPlanner, I thought I was building a wedding planning tool. Checklist, budget tracker, guest list — standard stuff. How hard could it be?

Six months later, I was knee-deep in PHP currency formatting edge cases, trying to figure out why my GCash webhook was returning PAYMENT_EXPIRED for a transaction that literally just happened, and learning that "ninong" and "ninang" aren't just titles — they're a whole social contract that determines seating arrangements, budget contributions, and whether your wedding will have enough lechon.

Here's what I learned about localizing a SaaS product for the Philippine market — the stuff no one tells you when you read "just use i18n" on Stack Overflow.

The Currency Trap: It's Not Just About the Peso Sign

My first instinct was simple: swap the dollar sign for ₱ and call it a day. That lasted about 15 minutes.

Here's the thing about Philippine pesos: the numbers are big. A mid-range wedding in Manila runs around ₱500,000 to ₱1,200,000. That's six zeros. When you're displaying budget breakdowns, vendor costs, and running totals, you need to format these numbers in a way that's actually readable — and that doesn't break when someone's budget crosses the million-peso mark.

I started with Intl.NumberFormat — the obvious choice:

const formatter = new Intl.NumberFormat('en-PH', {
  style: 'currency',
  currency: 'PHP',
  minimumFractionDigits: 0,
  maximumFractionDigits: 0
});

console.log(formatter.format(850000)); // "₱850,000"

Great, right? Then I discovered that en-PH isn't universally supported across all browsers. Some older Android devices — still very common in the Philippines, where the average smartphone is 2-3 years old — would fall back to en-US and suddenly my peso amounts were showing dollar signs. Not ideal when someone's planning their wedding budget and suddenly thinks their venue costs $850,000.

I ended up writing a custom formatter that handles the PHP-specific quirks:

function formatPHP(amount) {
  const formatted = amount.toLocaleString('en-PH', {
    minimumFractionDigits: 0,
    maximumFractionDigits: 0
  });
  return `₱${formatted}`;
}

But the real localization challenge wasn't the formatting — it was the context. Filipino couples don't think about wedding costs the same way Western couples do. The budget isn't just "what we can afford." It's a negotiation between two families, often with parents and godparents contributing significant portions. The budget tracker needed to support multiple contributors, not just a single couple. I added a "contributions" tab where couples can track who's paying for what — the bride's family covering the reception, the groom's family handling the church, the ninong pitching in for the honeymoon.

I also learned that Filipino wedding budgets are almost always discussed in round numbers: "Our budget is 500k" or "We're spending 1 million." Nobody says "₱847,350." The UI needed to reflect that — showing estimates and ranges, not precise-to-the-peso calculations that would feel weirdly specific and, honestly, a little stressful to look at.

GCash Integration: The Payment Layer Nobody Talks About

If you're building anything consumer-facing in the Philippines, you need GCash. Period. Over 90 million Filipinos use it — that's nearly the entire adult population. Credit card penetration is around 3%. If you only accept cards, you're building for 3% of your market. That's not a niche — that's a rounding error.

Integrating GCash into WedPlanner was one of the most humbling technical experiences I've had. Here's what I wish someone had told me before I started:

1. The Webhook Reliability Problem

GCash Pay (via their API partners like PayMongo) uses webhooks to notify you of payment status. In theory, this is fine. In practice, webhooks can arrive late — sometimes 30-60 seconds after the user sees "Payment Successful" on their GCash app. If your UI doesn't handle this gracefully, you'll have confused users refreshing the page wondering why their payment "didn't go through."

I built a polling fallback: if the webhook doesn't arrive within 10 seconds, the frontend polls the payment status endpoint every 3 seconds for up to 2 minutes. It's not elegant, but it works. More importantly, it prevents the support tickets that start with "I paid but your app says I didn't."

2. The ₱1 Test Transaction Trap

GCash's sandbox environment lets you test with ₱1 transactions. Everything works perfectly. Then you go live and discover that real transactions behave differently — different timeout windows, different error codes, different everything. The sandbox is great for integration testing, but you need to test with real amounts (even if it's just ₱50) before you can trust your payment flow. I learned this the hard way at 11 PM on a Friday.

3. QR Ph vs. GCash App Deep Links

GCash supports both QR Ph (the national QR standard) and GCash-specific deep links. I initially went with QR Ph because it's "the standard" and theoretically works across multiple e-wallets. But GCash's QR Ph implementation has quirks — some users' apps wouldn't recognize the QR code format, especially on older app versions. Switching to GCash-specific deep links solved the problem but meant I was now locked into a single payment provider. Trade-offs everywhere.

For the GCash wedding registry feature, I built a flow where couples can create a cash gift registry and guests can contribute directly via GCash. The key insight: Filipino wedding guests want to give cash. It's culturally expected — the "money dance" where guests pin bills on the couple is a staple of Filipino receptions. The product just needed to make it frictionless. Scan a QR code, enter an amount, done. No account creation, no app download (they already have GCash), no friction.

Filipino Wedding Customs: The Feature List You Can't Skip

This is where localization stops being about code and starts being about culture. A generic wedding planning tool has "guest list" and "seating chart." A Filipino wedding planning tool needs a lot more than that.

Principal Sponsors (Ninong and Ninang): These aren't just guests. They're godparents who often contribute financially and have ceremonial roles during the wedding. They need their own section in the guest management system, with tracking for whether they've confirmed, what their role is, and — critically — whether they're bringing their entire extended family (they usually are). I also added a field for "relationship to couple" because you can't just list "Ninong Boy" — you need to know he's the bride's uncle from her mother's side, and that affects where he sits.
Entourage Management: Filipino weddings have large entourages. Secondary sponsors for the cord, veil, and coins. Bridesmaids and groomsmen. Flower girls, ring bearers, Bible bearer, coin bearer. A typical Filipino wedding entourage can be 15-25 people. The tool needs to handle this without the UI becoming a scrolling nightmare. I built a collapsible entourage section with drag-and-drop ordering — because the order people walk down the aisle matters.
Pamamanhikan: The formal meeting where the groom's family visits the bride's family to ask for her hand. It's not technically part of the wedding, but every Filipino couple planning a wedding needs to account for it. I added it as a pre-wedding milestone in the timeline, complete with a checklist: prepare food, bring gifts, dress respectfully, bring your parents.
The Money Dance: Guests pin cash on the couple during the reception. It's a major part of Filipino weddings, and couples often want to plan for it — which song to play, who announces it, how long it should last. I added a "Money Dance" section to the reception timeline with customizable duration and music selection.
Church Requirements: Catholic church weddings in the Philippines require specific documents: baptismal certificates, confirmation certificates, marriage license, canonical interview, pre-cana seminar certificate. I built a document checklist specifically for church weddings because missing one document can delay the entire wedding.

The hardest part wasn't coding these features — it was understanding them well enough to build them correctly. I'm Filipino, but I still had to interview couples, wedding coordinators, and parents to understand the nuances. If you're building for a market you don't personally know, multiply your research time by 3x. Minimum.

The Metro Manila vs. Province Divide

Another localization lesson I didn't expect: the Philippines isn't one market. It's at least two — and probably more like five.

Couples in Metro Manila have different needs than couples in the provinces. Manila couples are more likely to use digital tools, expect mobile-first design, and want features like online RSVP with automated follow-ups. Province couples often have larger guest lists (200-500 guests is normal), more traditional ceremonies with extended family involvement, and may have limited or intermittent internet connectivity.

This created real product tension:

Offline support: I initially built everything as a real-time web app with server-side rendering. Then I heard from a coordinator in Iloilo: "What if the venue has no signal?" Many Filipino wedding venues — especially garden and beach venues — have spotty coverage. I added offline-capable PWA features with service workers and IndexedDB sync. Couples can now plan offline and sync when they're back on Wi-Fi.
Guest list size: My initial guest list UI was designed for 100-150 guests (Western norms). Filipino weddings routinely have 300+. I had to redesign the entire list view for performance at scale — virtual scrolling, paginated loading, batch operations for RSVP status updates. Loading 500 guests in a single render was crushing mobile browsers.
Language: The app is primarily in English (which most Filipino couples are comfortable with), but I added Tagalog support for key UI elements. "RSVP" becomes "Sasama ka ba?" — small change, big difference in feeling native. I'm also working on Cebuano and Ilocano support, because not everyone in the Philippines speaks Tagalog as their first language.
Data sensitivity: Mobile data in the Philippines isn't cheap for everyone. I optimized asset sizes, lazy-loaded images, and made sure the core planning features work on 3G connections. The initial bundle was 2.4MB — I got it down to 380KB gzipped.

What I'd Do Differently

If I were starting over, here's what I'd change:

Start with the payment layer. I built the planning features first and bolted on GCash later. Wrong order. Payment integration shapes your entire data model — user accounts, subscriptions, transaction history, refund logic. Build it first, even if it feels premature. You'll save yourself months of refactoring.
Interview 20 couples before writing a single line of code. I talked to 5. That wasn't enough. The edge cases in Filipino weddings are endless: What if the couple is Catholic but one family is Muslim? What if they're having a civil wedding but still want the traditional elements? What if the ninong lives abroad and can only attend via video call? What if the wedding is in Tagaytay but half the guests are from Davao? Every answer shapes a feature.
Don't assume "Filipino" means one thing. A wedding in Batanes looks nothing like a wedding in Davao. A Tagalog wedding has different customs than an Ilocano or Cebuano wedding. A Muslim wedding in Mindanao is completely different from a Catholic wedding in Manila. Building a "Filipino" wedding tool means building a flexible one that can adapt to regional and cultural variations.
Mobile-first isn't optional — it's the only option. The Philippines is a mobile-first country. Over 70% of our users access WedPlanner on their phones. Desktop is an afterthought. If your responsive design is "desktop-first with mobile breakpoints," you're doing it wrong for this market. I rebuilt the entire UI mobile-first after the first round of user testing showed that desktop-optimized layouts were unusable on 5.5-inch screens.
Build for group planning, not individual planning. Western wedding tools assume one person (usually the bride) is doing all the planning. Filipino weddings are planned by committee — the couple, both sets of parents, the ninong and ninang, sometimes the entire entourage. The collaboration features (shared checklists, comment threads, permission levels) aren't nice-to-haves. They're the core product.

The Bottom Line

Localizing SaaS isn't translating strings. It's understanding how people live, what they value, and how they make decisions. The peso sign is the easy part. The hard part is knowing that a Filipino wedding isn't just a ceremony — it's a family reunion, a financial negotiation, a religious sacrament, and a community celebration all rolled into one.

If you're building for a market you don't intimately know: spend time there. Talk to people. Watch how they use (or don't use) existing tools. The best localization features come from watching someone struggle with your product and thinking, "Oh. I built this wrong."

Building WedPlanner has been the most humbling and rewarding project of my career. Every time a couple tells me the tool saved them from a wedding planning meltdown — or that their ninong actually RSVP'd on time — I know the localization work was worth it.

What's the biggest localization challenge you've faced building for a specific market? I'd love to hear your war stories in the comments.

Building a Wedding Planning Tool for the Philippine Market: What I Learned About Localizing SaaS

Jay Artiaga — Tue, 11 Aug 2026 19:05:18 +0000

Six months ago, I started building a wedding planning tool for the Philippine market. I thought the hard part would be the features — guest lists, budget trackers, vendor directories. I was wrong. The hard part was localization. Not the "swap out the strings" kind of localization. The kind where you realize your entire data model was built around assumptions that don't hold in a different culture.

This is the story of what I learned building WedPlanner.ph — a SaaS wedding planning platform designed specifically for Filipino couples. If you're an indie hacker thinking about localizing your SaaS for Southeast Asia, or just curious about what happens when Western software assumptions meet Filipino wedding culture, this one's for you.

The Problem: Why Another Wedding Planner?

Here's the thing: there are already wedding planning tools. The Knot, WeddingWire, Zola — they're polished, feature-rich, and completely built for the American market. Filipino couples use them too, but they're constantly fighting the tool. The budget tracker assumes USD. The guest list doesn't understand the concept of ninong and ninang (principal sponsors — and yes, you need to seat them differently). The checklist assumes a 6-hour reception when Filipino weddings routinely run 8-10 hours.

I saw this gap and thought: how hard could it be to build a localized version? Famous last words.

The first thing I learned: localization isn't a skin you put on top of a product. It's a fundamental architectural decision. If you don't bake it into your data model from day one, you'll spend more time retrofitting than you would have spent building it right the first time.

Lesson 1: PHP Currency Is Not Just a Format String

When I started, I naively thought currency localization meant swapping $ for ₱ and calling it a day. Here's what I actually had to deal with:

Formatting quirks. The Philippine Peso symbol (₱) isn't in every font. On some Android devices, it renders as a box. I had to implement a fallback to "PHP" as a text prefix for devices that can't render the symbol — and detect that at runtime, not build time.

No decimal places. In the Philippines, wedding budgets are discussed in round numbers. Nobody says "our budget is ₱350,000.50." It's "350K" or "trescientos singkwenta." My budget tracker initially showed two decimal places everywhere, and early testers kept asking why their budget looked like a bank statement. I stripped decimals from the display layer but kept them in the database — because someday, someone will need them.

Range psychology. Filipino couples think in budget ranges differently. A "₱500K wedding" in the Philippines gets you a lot more than a "$10K wedding" in the US — the purchasing power is different, and so is the expectation. I had to build budget templates that reflected real Philippine vendor pricing, not just convert USD ranges to PHP. A mid-range Filipino wedding (100-150 guests) runs roughly ₱300,000 to ₱800,000 depending on the venue and caterer. My tool needed to reflect that reality, not some exchange-rate-converted fantasy.

Multiple payment realities. Filipino couples often pay vendors in installments — 30% down, 50% midway, 20% on the day. Some pay in cash. Some use bank transfers. And increasingly, they use GCash. My budget tracker needed to support partial payments, multiple payment methods per vendor, and due-date tracking that accounts for the Filipino "pakiusap" (negotiated) payment culture. This wasn't a "nice to have" — it was table stakes.

Lesson 2: GCash Integration Is a Product Feature, Not a Payment Add-On

If you're building anything for the Philippine market and you don't support GCash, you're leaving money on the table. GCash has over 90 million registered users in a country of 115 million people. It's not a niche payment method — it's the payment method.

For WedPlanner, GCash integration wasn't just about collecting subscription payments. It was about the entire wedding financial ecosystem:

The wedding registry problem. Filipino weddings have a unique tradition: guests give cash gifts ("pakimkim" or the money dance). Traditionally, this is physical cash pinned to the couple's clothing during the reception. But in 2026, more couples want a digital option — especially for guests who can't attend in person. I built a GCash wedding registry that lets couples receive monetary gifts directly through GCash QR codes embedded in their wedding website. No awkward "here's my bank account number" conversations.

Vendor payments. Most Filipino wedding vendors — photographers, coordinators, makeup artists — prefer GCash for deposits and progress payments. It's instant, the fees are low (or zero for person-to-person transfers), and everyone already has the app. My vendor management module needed to track GCash reference numbers alongside traditional bank transfer details.

The technical reality. Integrating GCash isn't like plugging in Stripe. GCash's merchant API requires business registration in the Philippines, a physical business address, and a Philippine bank account for settlement. If you're an indie hacker outside the Philippines (like I was initially), you need a local partner or entity. I ended up registering a Philippine business — which took 6-8 weeks and involved more paperwork than I'd like to remember. Factor this into your timeline if you're building for the PH market.

QR code UX. GCash payments in the Philippines are overwhelmingly QR-based. Users open GCash, scan a QR code, and pay. My wedding website builder needed to generate and display GCash QR codes dynamically — one per couple, with the correct amount pre-filled where possible. This sounds simple until you realize QR codes need to be regenerated when amounts change, and you need to handle the case where a guest scans the code but doesn't complete the payment.

Lesson 3: Filipino Wedding Customs Are Data Model Problems

This was the biggest surprise. I thought cultural localization was a content problem — write some blog posts about Filipino traditions, add a few Tagalog phrases, done. Nope. Filipino wedding customs are data model problems.

The entourage isn't a bridal party. In Western weddings, you have bridesmaids and groomsmen. In Filipino weddings, you have an entourage that includes principal sponsors (ninong and ninang), secondary sponsors (for the cord, veil, and coins), bridesmaids, groomsmen, flower girls, ring bearers, and sometimes a Bible bearer. That's 20-30+ people with different roles, responsibilities, and seating requirements. My guest list data model needed a role hierarchy that doesn't exist in any Western wedding planner.

The ninong/ninang system. Principal sponsors aren't just ceremonial — they're often the couple's godparents, mentors, or family friends who contribute significantly to the wedding budget. Some couples have 4-6 pairs of ninong and ninang. My budget tracker needed to account for sponsor contributions as a distinct income category, not just lumped into "family contributions." And the seating chart needed to place them prominently — not at a "head table" but at specific positions near the couple during the ceremony.

The ceremony has more parts. A traditional Filipino Catholic wedding includes the veil ceremony, the cord ceremony, the arrhae (coin) ceremony, and the candle ceremony — all before the vows. Each requires specific items, specific people (secondary sponsors), and specific timing. My wedding checklist needed to track all of these, not just "ceremony → vows → rings → kiss."

The reception runs longer. Filipino wedding receptions routinely go 6-8 hours, sometimes longer. There's the money dance, the bouquet toss, the garter toss, games, multiple outfit changes for the couple, and a full multi-course meal. My timeline builder needed to support this extended schedule — and the budget tracker needed to account for things like "overtime fees for the photographer" and "midnight snack for guests" (yes, that's a real line item).

I wrote more about these traditions in detail on the WedPlanner blog — the depth of Filipino wedding customs is genuinely fascinating, and understanding them was essential to building a tool that didn't feel foreign to its users.

Lesson 4: The Tech Stack Matters Less Than You Think

I spent way too long agonizing over the tech stack. React vs Vue. PostgreSQL vs MongoDB. Vercel vs AWS. Here's what actually mattered:

Mobile-first, always. Over 70% of WedPlanner's traffic comes from mobile devices. The Philippines is a mobile-first country — many users don't own a laptop. If your SaaS isn't genuinely mobile-first (not just responsive, but designed for thumb navigation, low-bandwidth connections, and intermittent connectivity), you're building for an audience that doesn't exist.

Offline support matters. Internet in the Philippines isn't always reliable, especially in provinces. I added service workers and local storage caching so couples could access their wedding checklist and budget tracker even when their Globe or Smart data was acting up. This wasn't a "nice to have" — it was the difference between a usable tool and a frustrating one.

Image optimization is non-negotiable. Filipino users share a lot of images — venue photos, peg boards, supplier portfolios. If your image handling isn't optimized for slow connections, your app feels broken. I implemented WebP conversion, lazy loading, and progressive image loading. Page load times dropped from 4.2s to 1.1s on 3G connections.

Taglish is a real language. The Philippines operates in Taglish — a fluid mix of Tagalog and English. My UI needed to support this, not just offer a "Filipino" translation that nobody actually speaks. I ended up building a content system that allows mixed-language strings and context-aware translations. "Save" in English becomes "I-save" in natural Taglish, not "Iligtas" (which means "rescue"). Getting this right required working with Filipino copywriters, not just running strings through Google Translate.

Lesson 5: Building in Public Works — But Only If You're Honest

I've been sharing the WedPlanner journey publicly — on dev.to, on Filipino wedding forums, on Twitter. The "building in public" approach has been the single best growth lever I've found, but it only works if you're genuinely transparent about the struggles.

When I wrote about my GCash integration nightmare (6 weeks of paperwork, 3 rejections, 1 resubmission), it got 10x the engagement of my "we launched!" post. When I shared the spreadsheet of Filipino wedding vendor pricing I'd compiled — showing the real ₱50,000-₱150,000 range for photographers, not the "$2,000-$5,000" you see on American sites — wedding coordinators started reaching out to be listed on the platform.

The lesson: your audience can smell marketing from a mile away. But they'll rally around an honest build story. Filipino couples planning weddings are stressed, budget-conscious, and drowning in Pinterest boards. They don't need another polished SaaS landing page. They need someone who gets it.

What I'd Do Differently

If I were starting over tomorrow, here's what I'd change:

Register the PH business entity first. I spent 2 months building before realizing I couldn't integrate GCash without a local entity. That's 2 months of features I had to rebuild around the payment reality.
Hire a Filipino cultural consultant from day one. I'm Filipino, but I've lived abroad. There were nuances I missed — like the fact that some provinces have different sponsor traditions, or that Muslim Filipino weddings follow completely different customs. A local consultant would have caught these before they became data model problems.
Start with the budget tracker, not the website builder. I assumed couples would want a wedding website first. They wanted budget help. The budget tracker is now the most-used feature, and I wish I'd led with it.
Don't underestimate the vendor directory. Filipino couples don't Google "wedding photographer" — they ask their coordinator, their married friends, and their local Facebook wedding group. Building a vendor directory with real reviews and verified listings has been more valuable for user acquisition than any SEO strategy.

The Numbers (Because Building in Public Means Sharing Numbers)

I believe in transparency, so here's where things stand after ~6 months of building:

Active users: ~850 registered couples (growing ~15% month-over-month)
Revenue: Pre-revenue (free tier only while validating; paid plans launching Q4 2026)
Most-used feature: Budget tracker (72% of active users)
Biggest surprise: The GCash wedding registry page gets more organic traffic than the homepage
Biggest challenge: Vendor onboarding — convincing Filipino wedding suppliers to maintain updated profiles on yet another platform
Monthly hosting cost: ~$85 (Supabase + Vercel + Cloudflare)

Is the Philippine Market Worth It?

Short answer: yes, but not for the reasons you think.

The Philippines has ~400,000 weddings per year. The average wedding budget is ₱300,000-₱500,000 (~$5,000-$9,000 USD). The total wedding industry is worth an estimated ₱200+ billion annually. Those are real numbers.

But the real opportunity isn't the market size — it's the gap. Filipino couples are underserved by global SaaS products. They're cobbling together Google Sheets, Facebook groups, and GCash screenshots to plan one of the most important days of their lives. Building something that actually works for them isn't just a business opportunity — it's genuinely useful.

And that's the thing about localizing SaaS: if you do it right, you're not just translating a product. You're building something that couldn't exist anywhere else.

Building something for the Philippine market? Dealing with GCash integration? Wrestling with cultural data models? I'd love to hear about it. Drop a comment below or check out what we're building at WedPlanner.ph.

Building a Wedding Planning Tool for the Philippine Market: What I Learned About Localizing SaaS

Jay Artiaga — Tue, 11 Aug 2026 18:04:15 +0000

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.

Building a Wedding Planning Tool for the Philippine Market: What I Learned About Localizing SaaS

Jay Artiaga — Tue, 11 Aug 2026 16:55:23 +0000

When I first sat down to build WedPlanner, I thought I was building a wedding planning tool. Checklist, budget tracker, guest list — standard stuff. How hard could it be?

Here's what I learned about localizing a SaaS product for the Philippine market — the stuff no one tells you when you read "just use i18n" on Stack Overflow.

The Currency Trap: It's Not Just About the Peso Sign

My first instinct was simple: swap the dollar sign for ₱ and call it a day. That lasted about 15 minutes.

I started with Intl.NumberFormat — the obvious choice:

const formatter = new Intl.NumberFormat('en-PH', {
  style: 'currency',
  currency: 'PHP',
  minimumFractionDigits: 0,
  maximumFractionDigits: 0
});

console.log(formatter.format(850000)); // "₱850,000"

I ended up writing a custom formatter that handles the PHP-specific quirks:

function formatPHP(amount) {
  const formatted = amount.toLocaleString('en-PH', {
    minimumFractionDigits: 0,
    maximumFractionDigits: 0
  });
  return `₱${formatted}`;
}

GCash Integration: The Payment Layer Nobody Talks About

Integrating GCash into WedPlanner was one of the most humbling technical experiences I've had. Here's what I wish someone had told me before I started:

1. The Webhook Reliability Problem

2. The ₱1 Test Transaction Trap

3. QR Ph vs. GCash App Deep Links

Filipino Wedding Customs: The Feature List You Can't Skip

Principal Sponsors (Ninong and Ninang): These aren't just guests. They're godparents who often contribute financially and have ceremonial roles during the wedding. They need their own section in the guest management system, with tracking for whether they've confirmed, what their role is, and — critically — whether they're bringing their entire extended family (they usually are). I also added a field for "relationship to couple" because you can't just list "Ninong Boy" — you need to know he's the bride's uncle from her mother's side, and that affects where he sits.
Entourage Management: Filipino weddings have large entourages. Secondary sponsors for the cord, veil, and coins. Bridesmaids and groomsmen. Flower girls, ring bearers, Bible bearer, coin bearer. A typical Filipino wedding entourage can be 15-25 people. The tool needs to handle this without the UI becoming a scrolling nightmare. I built a collapsible entourage section with drag-and-drop ordering — because the order people walk down the aisle matters.
Pamamanhikan: The formal meeting where the groom's family visits the bride's family to ask for her hand. It's not technically part of the wedding, but every Filipino couple planning a wedding needs to account for it. I added it as a pre-wedding milestone in the timeline, complete with a checklist: prepare food, bring gifts, dress respectfully, bring your parents.
The Money Dance: Guests pin cash on the couple during the reception. It's a major part of Filipino weddings, and couples often want to plan for it — which song to play, who announces it, how long it should last. I added a "Money Dance" section to the reception timeline with customizable duration and music selection.
Church Requirements: Catholic church weddings in the Philippines require specific documents: baptismal certificates, confirmation certificates, marriage license, canonical interview, pre-cana seminar certificate. I built a document checklist specifically for church weddings because missing one document can delay the entire wedding.

The Metro Manila vs. Province Divide

Another localization lesson I didn't expect: the Philippines isn't one market. It's at least two — and probably more like five.

This created real product tension:

Offline support: I initially built everything as a real-time web app with server-side rendering. Then I heard from a coordinator in Iloilo: "What if the venue has no signal?" Many Filipino wedding venues — especially garden and beach venues — have spotty coverage. I added offline-capable PWA features with service workers and IndexedDB sync. Couples can now plan offline and sync when they're back on Wi-Fi.
Guest list size: My initial guest list UI was designed for 100-150 guests (Western norms). Filipino weddings routinely have 300+. I had to redesign the entire list view for performance at scale — virtual scrolling, paginated loading, batch operations for RSVP status updates. Loading 500 guests in a single render was crushing mobile browsers.
Language: The app is primarily in English (which most Filipino couples are comfortable with), but I added Tagalog support for key UI elements. "RSVP" becomes "Sasama ka ba?" — small change, big difference in feeling native. I'm also working on Cebuano and Ilocano support, because not everyone in the Philippines speaks Tagalog as their first language.
Data sensitivity: Mobile data in the Philippines isn't cheap for everyone. I optimized asset sizes, lazy-loaded images, and made sure the core planning features work on 3G connections. The initial bundle was 2.4MB — I got it down to 380KB gzipped.

What I'd Do Differently

If I were starting over, here's what I'd change:

Start with the payment layer. I built the planning features first and bolted on GCash later. Wrong order. Payment integration shapes your entire data model — user accounts, subscriptions, transaction history, refund logic. Build it first, even if it feels premature. You'll save yourself months of refactoring.
Interview 20 couples before writing a single line of code. I talked to 5. That wasn't enough. The edge cases in Filipino weddings are endless: What if the couple is Catholic but one family is Muslim? What if they're having a civil wedding but still want the traditional elements? What if the ninong lives abroad and can only attend via video call? What if the wedding is in Tagaytay but half the guests are from Davao? Every answer shapes a feature.
Don't assume "Filipino" means one thing. A wedding in Batanes looks nothing like a wedding in Davao. A Tagalog wedding has different customs than an Ilocano or Cebuano wedding. A Muslim wedding in Mindanao is completely different from a Catholic wedding in Manila. Building a "Filipino" wedding tool means building a flexible one that can adapt to regional and cultural variations.
Mobile-first isn't optional — it's the only option. The Philippines is a mobile-first country. Over 70% of our users access WedPlanner on their phones. Desktop is an afterthought. If your responsive design is "desktop-first with mobile breakpoints," you're doing it wrong for this market. I rebuilt the entire UI mobile-first after the first round of user testing showed that desktop-optimized layouts were unusable on 5.5-inch screens.
Build for group planning, not individual planning. Western wedding tools assume one person (usually the bride) is doing all the planning. Filipino weddings are planned by committee — the couple, both sets of parents, the ninong and ninang, sometimes the entire entourage. The collaboration features (shared checklists, comment threads, permission levels) aren't nice-to-haves. They're the core product.

The Bottom Line

What's the biggest localization challenge you've faced building for a specific market? I'd love to hear your war stories in the comments.

Why I Built a Wedding Website Builder Instead of Using Existing Platforms

Jay Artiaga — Tue, 11 Aug 2026 15:42:15 +0000

The Moment I Realized We Needed Something Different (WedPlanner)

My cousin called me three weeks before her wedding. She was in tears — not the happy kind. Her wedding website on The Knot had been flagged for "suspicious activity" because she'd embedded a custom Google Maps widget showing the venue location with a hand-drawn route from the church. The support team told her it would take 5-7 business days to review. She had 200 guests checking that site daily for directions.

That was the moment I stopped treating wedding websites as a solved problem.

I'm a full-stack developer. I've built SaaS products, e-commerce platforms, and real-time dashboards. But when I looked at the wedding website space, I saw something that genuinely surprised me: a market dominated by platforms that treat couples as content consumers rather than site owners.

This is the story of why I built a wedding website builder from scratch — and why, after six months of development and dozens of real weddings later, I'd do it again.

The Wedding Website Landscape: A Developer's Audit

Before writing a single line of code, I spent two weeks auditing every major platform. I signed up for free trials, built test sites, read through terms of service, and documented what each platform actually delivered versus what it promised.

The Knot: The 800-Pound Gorilla

The Knot is the biggest name in wedding planning. Their website builder comes bundled with planning tools, registry, and vendor marketplace. On the surface, it looks like a complete solution — but under the hood, the cracks show quickly.

Template lock-in is real. Once you pick a template, you can't switch without rebuilding your entire site. My cousin learned this the hard way when she wanted to change her color scheme two months in.
Your site isn't really yours. The Knot owns the domain, hosting, and content. They sunset sites after a year unless you pay for premium.
Vendor ads are everywhere. Even premium plans push "recommended vendors" into your dashboard. Your wedding website becomes a lead generation funnel for their marketplace.
No custom code. You can't add a custom font, a JavaScript animation, or even a simple CSS override.

Zola: Beautiful, But It's a Registry First

Zola's websites are genuinely well-designed — modern templates, clean UI, smooth onboarding. But Zola is a registry company that happens to offer websites, not the other way around.

Registry-first architecture. Every design decision pushes guests toward the registry. The website feels like a wrapper around a shopping experience.
No developer access. No API, no custom code injection, no webhooks. If you want to integrate with anything outside Zola's ecosystem, you can't.
Limited analytics. Basic page view counts only — no traffic sources, no click tracking, no RSVP conversion data.

Squarespace and Wix: Generalists in a Specialist's World

Squarespace and Wix are powerful general-purpose builders with wedding templates, custom domains, and SEO tools. But they're not wedding platforms. Building a wedding website on Squarespace means you're on your own for RSVP management, guest list tracking, registry integration, meal preference collection, and plus-one logic. You end up stitching together five different tools and hoping guests can navigate the result — at $16-45/month.

WithJoy: The Best Free Option (With Tradeoffs)

WithJoy deserves credit — genuinely free, solid feature set, no ads. Their photo-sharing feature is clever. But the customization ceiling is low: no custom code, no API, limited design flexibility. If your vision fits their templates, great. If not, you're stuck.

WordPress: The Nuclear Option

WordPress with a wedding theme gives complete control — custom code, plugins, full SEO, you own everything. But it's overkill: you're managing hosting, SSL, plugin updates, and security patches for a site that lives 12-18 months. Wedding-specific plugins are often abandoned. Every plugin adds a compatibility risk you don't want to debug the week before a wedding.

The Gap Nobody Was Filling

After two weeks of research, the pattern was unmistakable:

PlatformCustomizationWedding FeaturesOwnershipDeveloper AccessCost

The KnotLowHighNoNoFree-$50/yr
ZolaLowMediumNoNoFree
SquarespaceHighNoneYesLimited$192-432/yr
WixHighNoneYesLimited$192-540/yr
WithJoyLowMediumNoNoFree
WordPressFullPlugin-dependentYesFull$60-360/yr

Wedding-specific platforms give you features but take away control. General-purpose platforms give you control but leave you to build wedding features from scratch. Nobody was offering both. That was the gap — and as a developer, I couldn't un-see it.
Check out our About.

The Build Decision: Why Not Just Use an Existing Tool?

This is the question every developer faces: Why not just use what's already out there? I made a list of every reason not to build:

Time. Building a full wedding website builder would take months. I had a day job.
Maintenance. Someone has to keep it running, fix bugs, and handle edge cases.
The market is crowded. The Knot, Zola, and WithJoy have millions of users and massive marketing budgets.
Wedding tech is seasonal. Most couples plan in a 6-12 month window. Churn is built into the model.

Valid concerns. But here's what tipped the scales:

1. The Ownership Problem Is Fundamental

When you build on The Knot or Zola, you don't own your site. You're renting space. If they change pricing, remove a feature, or shut down, your site goes with them. I wanted couples to own their wedding websites the way they own their wedding photos — theirs, forever, on their own domain. That's not a feature you can bolt onto an existing platform. It's a fundamental architectural decision.

2. The Customization Ceiling Is Real

Every template-based builder has a customization ceiling. You can change colors, fonts, and images — but not the underlying structure. If a couple wants a custom RSVP flow with conditional logic ("if guest is bringing a plus-one, show meal preference for the plus-one"), no existing platform supports that without custom code. I wanted to build something where the ceiling was "whatever you can code."

3. The Tech Stack Was Actually Fun

Let me be honest: part of the reason I built this was because the engineering challenges were genuinely interesting. A wedding website builder touches multi-tenant architecture, dynamic content rendering, email automation, access control, and mobile-first design — all in one project. This wasn't a simple CRUD app. It was a genuinely interesting engineering project, and that made the build decision easier.

What We Built: The Tech Stack and Key Features

After six months of nights and weekends, here's what shipped:

The Stack

Frontend: Next.js with Tailwind CSS — SSR for SEO, static generation for performance.
Backend: Node.js with PostgreSQL — relational data for guest lists and RSVPs; JSON columns for flexible site configuration.
Hosting: Vercel (frontend) + Railway (backend/DB) — zero DevOps overhead, automatic SSL, global CDN.
Email: Resend for transactional emails — RSVP confirmations, reminders, and couple notifications.
Storage: Cloudflare R2 for photo uploads — S3-compatible API without egress fees.

Key Features

Custom domain support out of the box. Couples bring their own domain; we handle DNS with a one-click setup guide.
Smart RSVP system. Guests enter their name, the system looks them up in the guest list, and shows exactly what they're invited to. Plus-one logic is built in: if marked "+1 allowed," they see a field for their guest's name and meal preference.
Meal preference collection. Couples define menu options; guests select during RSVP. The couple gets a real-time dashboard — no spreadsheet reconciliation needed.
Registry integration. Clean integrations with existing registries (Zola, Amazon, Crate & Barrel) displayed in a unified, well-designed page.
Photo gallery with guest uploads. Guests upload photos post-wedding; we compress and optimize automatically; couples moderate before anything goes live.
Full analytics. Page views, RSVP conversion rates, guest list completion, traffic sources — all in a clean dashboard.

You might also find our our Beauty Makeup guide useful.- Export everything. Guest list, RSVP data, meal preferences, photos — all exportable as CSV or JSON. The data belongs to the couple, not to us.

Lessons Learned: What I'd Do Differently

1. Non-Technical Users Will Find Every Edge Case

I thought I'd designed a foolproof RSVP flow. Then a couple invited 300 guests, and 50 of them shared the same first and last name (common in large Filipino families). The name-based lookup broke. I had to add a unique invitation code system — something I should have built from day one.

Lesson: Test with real data at real scale. Your test cases with 10 guests won't catch the problems that 300 guests will.

2. Wedding Timelines Are Unforgiving

When a couple's wedding is in two weeks and their RSVP system has a bug, you can't say "we'll fix it in the next sprint." Wedding deadlines are hard deadlines. I learned to build with extreme defensive coding — every feature needed a manual fallback path.

Lesson: Always build a manual override. Automation is great until it breaks the week before someone's wedding.

3. The "Simple" Features Took the Longest

Building the site editor took two weeks. Building the RSVP system took two months. The features that seem simplest — collecting names, tracking responses, handling edge cases — are often the most complex under the hood.

Lesson: Budget your time for the boring stuff. The flashy features are fun and straightforward. The unglamorous features (RSVP logic, email delivery, error handling) are where you'll spend most of your time.

4. Couples Care About Different Things Than Developers

I was excited about the tech stack and architecture. Couples cared about three things: "Does it look good?", "Will my guests figure out how to RSVP?", and "Can I change things without asking a developer for help?" I had to constantly remind myself to prioritize UX over engineering elegance.

Lesson: Ship the UX first. The architecture can be refactored later. A confusing RSVP flow loses users faster than a suboptimal database schema.

Was It Worth It?

Six months of nights and weekends. Dozens of late-night debugging sessions. At least three complete rewrites of the RSVP logic. Was it worth it?

For the couples using it: absolutely. They have websites that look exactly how they want, on their own domains, with RSVP flows that actually work for their specific guest lists. They own their data. They're not locked into a platform that might sunset their site or push vendor ads into their guests' experience.

For me as a developer: also yes. I shipped a real product that real people use. I learned more about multi-tenant architecture, email deliverability, and UX design than I would have from any tutorial or side project.

But here's the honest answer: building from scratch isn't the right call for everyone. If you're a couple planning your own wedding and just need a simple site with basic RSVP, use WithJoy. It's free, it works, and you'll save months of development time.

If you're a developer who sees the same gaps I saw — the ownership problem, the customization ceiling, the feature gaps — and you have the time and energy to build something better: go for it. The market is bigger than you think, and the existing solutions leave a lot of room for improvement.

Just budget twice as much time for the RSVP system as you think you'll need. Trust me on that one.

This article is part of my "Building in Public" series. I'm documenting the journey of building wedding tech tools from scratch — the decisions, the mistakes, and the lessons learned along the way. Follow along if you're into indie hacking, wedding tech, or just enjoy watching someone figure things out in public.

Building a Wedding Planning Tool for the Philippine Market: What I Learned About Localizing SaaS

Jay Artiaga — Tue, 11 Aug 2026 15:39:14 +0000

Why I Decided to Build a Wedding Planning Tool for the Philippines (WedPlanner)

It started with my cousin's wedding. Three hundred guests, four ninongs and ninangs, a coordinator who quit two weeks before the big day, and a spreadsheet that had been passed around so many times nobody knew which version was current. I watched my cousin — a software engineer, no less — spend her evenings manually texting suppliers to confirm payments, tracking RSVPs in a Facebook group, and cross-referencing three different lists of "entourage members" because Filipino wedding parties are famously enormous.

I thought: there has to be a tool for this.

There wasn't. Not one built for how Filipinos actually plan weddings.

So I built one. Here's what I learned about localizing SaaS for the Philippine market — the hard way.

The Landscape: Why Global Tools Don't Cut It

There are plenty of wedding planning tools out there. The Knot, Zola, WeddingWire — they dominate the US market. But try using any of them for a Filipino wedding and you'll hit walls immediately.

Filipino weddings aren't just "a ceremony and a reception." They involve:

Principal sponsors (ninongs and ninangs) — typically 4 to 8 pairs, not just a best man and maid of honor
Secondary sponsors for the candle, veil, cord, and coins — uniquely Filipino Catholic traditions
An entourage that can easily hit 20+ people — flower girls, ring bearers, bridesmaids, groomsmen, and more
Multiple pre-wedding events — pamamanhikan (formal meeting of families), despedida de soltera, and sometimes a separate civil ceremony
Family involvement at every decision point — from the guest list to the menu to the color motif

Global tools model a Western wedding. They don't have fields for "cord sponsor" or "veil sponsor." They don't understand why you need to track which tita is allergic to shrimp and which lolo needs a wheelchair-accessible seat. These aren't edge cases in the Philippines — they're the baseline.

Lesson 1: Payments Are Everything — and They're Nothing Like the West

If you're building SaaS for the Philippine market and you only support credit cards, you've already lost 95% of your potential users.

Credit card penetration in the Philippines hovers around 3-5% of the population. But smartphone penetration is over 70%, and mobile wallets dominate. GCash alone has over 80 million registered users. Maya (formerly PayMaya) has tens of millions more. When Filipinos pay for things online, they reach for their phones, not their wallets.

For the wedding planning tool, I had to integrate:

GCash — the undisputed king of Philippine digital payments
Maya — strong in the younger, more tech-savvy demographic
Bank transfers via InstaPay — still widely used for larger transactions like venue deposits
Over-the-counter payments — because some suppliers (and some couples' parents) still prefer paying at 7-Eleven or Bayad Center

The technical challenge wasn't just adding payment gateways. It was designing a payment flow that made sense for how Filipino weddings are actually paid for: in installments, often by multiple people (the couple, the parents, sometimes the godparents), with due dates that shift constantly because suppliers are flexible in ways that would make a Western accountant's head spin.

// Payment tracking needs to handle split payments
const payment = {
  supplier: "Catering by Josie",
  totalAmount: 150000, // PHP
  installments: [
    { dueDate: "2024-03-15", amount: 50000, paidBy: "bride_parents", status: "paid" },
    { dueDate: "2024-06-01", amount: 50000, paidBy: "couple", status: "pending" },
    { dueDate: "2024-08-15", amount: 50000, paidBy: "groom_parents", status: "pending" }
  ],
  paymentMethod: "gcash",
  referenceNumber: "GC-2024-03921"
};

I learned this the hard way when our first beta tester tried to log a payment from her mother-in-law via GCash and the system had no concept of "someone else paid this installment." Three days of refactoring later, split-payment tracking became a core feature.

Lesson 2: Mobile-First Isn't a Buzzword — It's Survival

The Philippines is a mobile-first country. Not mobile-friendly. Mobile-first. Over 70% of web traffic comes from mobile devices, and in many provinces, the smartphone is the only internet-connected device a person owns.

Internet speeds vary wildly. Metro Manila enjoys decent fiber connections, but drive two hours outside the capital and you're looking at 4G at best, 3G in some areas, and data caps that make heavy web apps unusable.

This meant hard decisions:

Bundle size matters. Our initial React bundle was 380KB gzipped. We got it down to 120KB. Every kilobyte counts when your user is on a prepaid data plan in Batangas.
Offline-first architecture. We built the app to work offline and sync when connectivity returns. Couples planning weddings in Tagaytay or Baguio (popular wedding destinations with spotty reception) can't afford to lose their checklist because the signal dropped.
Image optimization is non-negotiable. Wedding planning involves lots of photos — pegs, venue shots, gown designs. We implemented aggressive lazy loading, WebP with JPEG fallbacks, and thumbnail generation that reduced image payloads by 70%.
No assumptions about screen size. We tested on everything from a 5-year-old Cherry Mobile to the latest iPhone. The budget planner had to work on a 5-inch screen with a virtual keyboard covering half of it.

Check out our our Bridal Fashion guide.The biggest surprise? Our users didn't complain about the mobile experience. They just expected it to work. The bar isn't "good mobile UX" — it's "works exactly like the apps I already use every day." If GCash and Facebook can do it, so should you.

Lesson 3: Language Is Complicated — and That's the Point

I initially built the app in English. Clean, professional English. The kind you'd use in a Silicon Valley pitch deck.

Our first five beta testers all asked the same question: "Bakit English? Pwede bang Taglish?"

Filipinos don't speak pure English or pure Filipino. They speak Taglish — a fluid, natural code-switching between the two. It's not a bug; it's a feature of how people actually communicate. A wedding planning app that says "Please select your principal sponsors" feels cold and foreign. One that says "Piliin ang mga ninong at ninang mo" feels warm and familiar.

But here's the trap: you can't just translate. You have to localize the concepts.

Consider the guest list. In a Western app, you'd have "Guest Name" and "Plus One." In a Filipino wedding, you need:

Pax count — because "Mr. and Mrs. Santos + 3 kids + yaya" is one invitation but six plates
Dietary restrictions that are culturally specific — "bawal sa baboy" (no pork) isn't the same as "halal," and "no beef" might be a religious vow (panata), not a preference
Seating that respects family hierarchy — you don't seat the ninong next to the barkada. The head table isn't just the couple; it's the couple, both sets of parents, and the principal sponsors

We ended up building a localization layer that wasn't just string replacement. It was a context-aware system that understood Filipino wedding concepts and rendered the appropriate language mix based on user preference. Some users wanted full Tagalog. Some wanted English. Most wanted something in between. The system had to handle all three.

Lesson 4: Family Is the Real Decision-Maker

In Western wedding planning, the couple makes the decisions. In the Philippines, the couple negotiates decisions with their families.

This isn't a stereotype — it's structural. Filipino weddings are often funded by parents and extended family. When your tita is paying for the catering, she gets a say in the menu. When your ninong is covering the venue, he has opinions about the location. The app had to reflect this reality.

We built a "family collaboration" feature that let couples share planning access with parents and sponsors. But we quickly learned that a simple "share" button wasn't enough. We needed:

Permission levels — Mom can edit the guest list but not the honeymoon budget. Ninong can see the ceremony details but not the couple's private notes.
Activity feeds — so the couple can see that Tita Linda added 12 more guests to the reception (and react before the caterer gets the final headcount)
Comment threads on every decision — because Filipino families discuss everything. The color motif alone generated 47 comments in one test wedding.

The technical challenge was designing a permission system that was flexible enough for Filipino family dynamics but simple enough that a non-technical tita could use it. We landed on role-based access with three tiers: "Planner" (full access), "Contributor" (can suggest and comment), and "Viewer" (read-only). The couple stays in control, but the family stays in the loop.

Lesson 5: The Supplier Ecosystem Is Wildly Different

In the US, you book vendors through platforms with standardized contracts, deposit systems, and review mechanisms. In the Philippines, many of the best suppliers — the caterer who's been doing weddings in your province for 30 years, the florist your mom's friend recommended — don't have websites. They have Facebook pages. They communicate via Messenger. They send quotes as images in Viber.

Building a supplier management module meant accepting this reality rather than fighting it. We built:

Manual supplier entry — because you can't auto-import from a CRM that doesn't exist
Document upload for contracts and quotes — because that photo of a handwritten quotation is a legally binding document in this context
Payment tracking that handles partial payments, down payments, and "balance on the day" — because almost no Filipino wedding supplier demands 100% upfront
Reminder system integrated with the couple's calendar — because "I'll pay next week" needs a follow-up when next week arrives

The most requested feature? A way to track which suppliers had been "recommended by someone we know." In the Philippines, personal referrals carry more weight than any review platform. We added a "Recommended by" field to every supplier entry, and it became the most-used metadata field in the entire app.

Lesson 6: Pricing for the Philippine Market Is a Different Game

If you price your SaaS at $29/month, you've priced out 90% of your Philippine target market. The purchasing power gap is real, and it's not something you can ignore by saying "but our tool provides $500 in value."

We experimented with multiple pricing models:

Freemium with a generous free tier — because adoption requires trust, and trust requires trying the product without a credit card
One-time payment option — because Filipino couples plan weddings over 12-18 months, and a monthly subscription for that entire period adds up to more than many are willing to spend
GCash/Maya as first-class payment options for the subscription itself — because asking for a credit card to pay for a tool that helps you avoid needing a credit card is peak irony

We landed on a model that felt fair: a free tier that covers basic planning for up to 100 guests, a one-time "full wedding" payment of ₱1,499 (about $27), and a premium tier at ₱2,999 (about $54) that includes supplier coordination tools and family collaboration. The one-time payment option converted 3x better than the monthly subscription in our beta.
You might also find our our Saying Yes To The Silhouette A Guide To Wedding Gowns That Celebrate Your Shape guide useful.

What I'd Do Differently

Looking back, there are things I'd change:

Start with mobile, not responsive web. We built the web app first and made it responsive. If I were starting over, I'd build a mobile app from day one — probably React Native with offline-first as a core architectural decision, not an afterthought.
Hire a Filipino UX writer earlier. I thought I could handle the Taglish localization myself. I was wrong. The difference between "good enough" Taglish and "sounds like a real person" Taglish is the difference between an app people tolerate and an app people love. We brought in a Filipino copywriter three months in, and the user feedback transformed overnight.
Don't underestimate the power of Facebook groups. Filipino wedding planning happens in Facebook groups — "Weddings & Beyond," "Budgetarian Bride," and dozens of supplier-specific communities. We should have embedded ourselves in these communities from day one instead of trying to drive traffic through SEO and ads.
Build for the province, not just Metro Manila. Our early testers were all Manila-based. When we expanded to testers in Cebu, Davao, and Iloilo, we discovered entirely new use cases — like tracking which suppliers will travel to the province and which won't, or managing the logistics of a "destination wedding" where the destination is the couple's home province.

The Numbers That Mattered

After six months of development and three months of beta testing with 40 couples:

73% of users accessed the app primarily on mobile — confirming the mobile-first bet
82% of payments were made via GCash or Maya — credit cards accounted for less than 5%
Average wedding budget tracked: ₱350,000 — ranging from ₱80,000 (simple civil wedding) to ₱1.2M (full church wedding with 300 guests)
Most-used feature: Guest list manager — with an average of 180 guests per wedding
Most-requested feature: Supplier recommendation engine — "who did your friend use for their wedding in Tagaytay?"

The Bigger Picture

Building for the Philippine market taught me something that goes beyond wedding planning. Localization isn't translation. It's not adding a language toggle or supporting a local payment method. It's understanding how people actually live, make decisions, and solve problems in their specific context — and then building software that fits into that reality rather than asking people to adapt to yours.

The Philippines has over 110 million people, a young and digitally-native population, and a rapidly growing digital economy. It's one of the most exciting markets for SaaS in Southeast Asia. But you can't just drop a Western product into it and expect it to work. You have to build for it.

If you're thinking about localizing a SaaS product for the Philippines — or any market that's fundamentally different from the one you built for — start with the people, not the technology. Watch how they plan a wedding. Watch how they pay for things. Watch how their families make decisions together. The product will follow.

Have you built a product for a market that required deep localization? I'd love to hear about your experience in the comments. And if you're planning a Filipino wedding — kaya mo yan. You've got this.