DEV Community: Jay WedPlanner

The Filipino Wedding is Different: Building Software for Cultural Specifics

Jay WedPlanner — Tue, 01 Sep 2026 00:12:39 +0000

The Filipino Wedding is Different: Building Software for Cultural Specifics

Quick Answer: Filipino weddings involve pre-wedding rituals like pamamanhikan (formal engagement meeting), bayanihan (community cooperation), and guest lists of 300–500 people. Software built for Western weddings fails because it assumes small guest counts, single-phase planning, and individual decision-making. Building for Filipino weddings requires rethinking guest management, budgeting, and collaboration workflows entirely.

Introduction

When we started building wedding planning software, we assumed a wedding was a wedding. Venue, guest list, RSVPs, vendors — how different could it be across cultures?

Very different, it turns out.

Our first Filipino users broke every assumption we had. Their guest lists weren't 100–150 people — they were 300, 400, sometimes 500. Their planning didn't start six months out — it started with pamamanhikan, a formal engagement ritual that happens before anything else. And the decision-making wasn't between two people — it involved two extended families, barangay (community) leaders, and sometimes the entire village.

We had built software for individuals. They needed software for communities.

This is the story of how cultural specificity forced us to rebuild our product from the ground up — and why "global" software often fails the people who need it most.

What Makes Filipino Weddings Different?

Before diving into the software changes, let's understand what we were actually building for.

Pamamanhikan: The Engagement Meeting

Pamamanhikan is a formal pre-wedding meeting where the groom's family visits the bride's family to ask for her hand in marriage. It's not a casual dinner — it's a structured negotiation involving:

Dowry or wedding expense discussions
Religious ceremony details
Guest list contributions from both families
Venue and date decisions
Role assignments for family members Our original software had no concept of pre-engagement planning. Users were creating "wedding" events before they were technically engaged, which broke our timeline logic entirely.

Bayanihan: Community Cooperation

Bayanihan is the Filipino tradition of communal unity and cooperation. In wedding context, this means:

Relatives cook food instead of hiring caterers
Neighbors help decorate the venue
Family members serve as coordinators, not hired staff
Community contributions replace vendor contracts Our vendor management system assumed every service was paid and contracted. Filipino weddings often had "vendors" who were unpaid family members — and our software couldn't handle that relationship.

The Extended Family Problem

The average Filipino wedding has 300–500 guests. Why? Because "immediate family" includes:

Parents, siblings, grandparents
Aunts, uncles, first and second cousins
Godparents (ninongs and ninangs)
Close family friends treated as relatives
Barangay neighbors and community members Our guest list feature capped at 200 people. We thought that was generous.

Where Our Software Failed — And What We Changed

Failure 1: The "Couple-Centric" Model

What we assumed: Two people plan a wedding together.

Reality: Two families plan a wedding, with the couple as coordinators.

Our original interface had "Bride" and "Groom" accounts with shared access. Filipino users needed "Family A" and "Family B" workspaces, with role-based permissions for parents, siblings, and coordinators.

What we changed: We added "Family Groups" — multiple user accounts tied to a single wedding, with permission levels (Admin, Coordinator, Viewer). Parents could approve expenses. Siblings could manage guest lists. Everyone saw relevant updates.

Failure 2: Fixed Timeline Templates

What we assumed: Engaged → 6–12 months planning → Wedding day.

Reality: Pamamanhikan → Engagement → 12–18 months planning → Multiple ceremonies → Reception.

Filipino weddings often include a church ceremony, a civil ceremony, and sometimes a separate reception days later. Our single-date model collapsed.

What we changed: Flexible event phases. Users can now define custom phases: "Pamamanhikan," "Church Ceremony," "Civil Ceremony," "Reception," "Thank You Dinner." Each phase has its own tasks, budget, and guest list.

Failure 3: Binary RSVP

What we assumed: Yes/No/Maybe.

Reality: Filipino RSVPs are family-level decisions with complex attendance patterns.

Common responses we saw:

"Family of 6 attending, but only 4 can make the church ceremony"
"Tita will attend reception but not ceremony"
"15 people from our barangay, final count TBD"
"We'll come if we can get a ride" What we changed: Family-grouped RSVPs with per-event attendance, transportation needs, and "pending confirmation" status. We also added bulk SMS reminders — because not everyone has email in rural Philippines.

Failure 4: Vendor-Centric Budgeting

What we assumed: Every cost is a vendor invoice.

Reality: Many costs are community contributions tracked informally.

Aunts cook the food. Cousins handle photography. Neighbors lend chairs. These aren't vendors — they're relationships.

What we changed: We added "Community Contributions" as a budget category. Users can track who contributed what (cooking, decorations, transportation) alongside paid vendors. This also helps with pasasalamat (thank-you) planning after the wedding.

Cultural UX: What We Learned About Design

Language Isn't Just Translation

We translated our interface to Tagalog, but that wasn't enough. Filipino users code-switch constantly — they think in English but feel in Filipino.

Our solution: Mixed-language interfaces. Key emotional terms (love, family, blessing) appear in Filipino. Technical terms (budget, timeline, vendor) stay in English. It feels natural because it mirrors how Filipinos actually communicate.

Mobile-First Is Non-Negotiable

In the Philippines, 97% of internet users access via mobile. But "mobile-first" doesn't just mean responsive design — it means:

Offline functionality (rural venues have poor connectivity)
Low-bandwidth mode (compressed images, text-heavy updates)
SMS integration (not everyone uses email)
Mobile payment integration (GCash, Maya)

Trust Signals Look Different

Western users trust reviews and certifications. Filipino users trust:

Family recommendations
Barangay endorsements
Church affiliations
Face-to-face meetings We added "Community Verified" badges — when a vendor is recommended by multiple users from the same barangay or church. It's not a perfect system, but it maps to how trust actually works in Filipino culture.

The Technical Architecture Behind Cultural Adaptation

Building for cultural specificity isn't just UI changes — it's architectural. Here's what we had to rethink:

Flexible Data Models

Western weddings have predictable entities: couple, venue, vendors, guests. Filipino weddings have fluid structures:

"Family" can mean 5 people or 50
"Event" can be one day or spread across weeks
"Budget" includes both cash and in-kind contributions We moved from rigid relational models to entity-attribute-value (EAV) schemas for family structures and event phases. It sacrifices some query performance for flexibility that actually fits reality.

Multi-Currency and Multi-Payment

Filipino weddings often involve:

Cash payments in PHP
Remittances from OFW relatives in USD/AED/SGD
Mobile wallet payments (GCash, Maya)
In-kind contributions (no monetary value) Our payment system went from "credit card integration" to "multi-currency, multi-channel, zero-value transaction support."

Collaboration at Scale

With 300–500 guests and multiple family coordinators, our collaboration features had to scale:

Real-time updates via WebSockets (not just email notifications)
Conflict resolution when two family members edit simultaneously
Audit logs for financial transparency between families
Permission systems that respect family hierarchies

Key Takeaways

Cultural context breaks Western assumptions. What works in the US fails in the Philippines because family structure, decision-making, and event flow are fundamentally different.
"Global" software is usually Western software. True localization requires rethinking data models, workflows, and trust systems — not just translating strings.
Community features beat individual features. Filipino weddings are collaborative by nature. Software must support family-level coordination, not just couple-level planning.
Mobile-first means offline-first. In emerging markets, connectivity is unreliable. Your app must work without it.
Trust is culturally constructed. Reviews and star ratings don't replace family recommendations and community verification.
Flexible architectures accommodate cultural variation. Rigid schemas fail when reality doesn't fit your assumptions.

Frequently Asked Questions

What is pamamanhikan in Filipino weddings?

Pamamanhikan is a formal pre-wedding tradition where the groom's family visits the bride's parents to formally ask for her hand in marriage. It involves discussions about wedding arrangements, dowry, and family expectations, making it an essential planning phase that Western wedding software typically ignores.

How large is a typical Filipino wedding?

Filipino weddings typically have 300–500 guests, significantly larger than Western weddings. This includes extended family, godparents (ninongs and ninangs), close friends treated as family, and sometimes entire barangay communities.

What is bayanihan and how does it affect wedding planning?

Bayanihan is the Filipino tradition of communal cooperation. In weddings, it means relatives and neighbors contribute services like cooking, decorating, and coordinating instead of hiring paid vendors. This requires software to track both paid and unpaid contributions.

Why does Western wedding software fail in the Philippines?

Western software assumes small guest lists, couple-centric decision-making, binary RSVPs, and vendor-based budgeting. Filipino weddings involve large families, multi-phase events, family-level RSVPs, and community contributions — breaking every Western assumption.

How important is mobile access for Filipino wedding planning?

Critical. 97% of Filipino internet users access via mobile, and many rural areas have poor connectivity. Wedding software must work offline, compress data, and integrate with SMS and mobile wallets like GCash.

What role do godparents play in Filipino weddings?

Godparents (ninongs and ninangs) are considered extended family and are integral to wedding planning. They often contribute financially, help coordinate guests, and play ceremonial roles — unlike Western godparents who may have limited involvement.

How do Filipino families make wedding decisions?

Decisions involve both extended families, not just the couple. Parents, siblings, and sometimes grandparents participate in discussions about budget, venue, guest list, and ceremony details. Software must support multi-family collaboration with role-based permissions.

What payment methods are common for Filipino weddings?

Besides cash in Philippine pesos, weddings often receive remittances from overseas Filipino workers (OFWs) in USD, AED, or SGD. Mobile wallets like GCash and Maya are increasingly popular. In-kind contributions from family members are also common.

How do you build trust in wedding software for Filipino users?

Trust comes from community verification, not Western-style reviews. Users trust recommendations from their barangay, church affiliations, and family networks. Software should highlight community endorsements and family recommendations over generic star ratings.

What is pasasalamat in Filipino wedding culture?

Pasasalamat means "thanksgiving" or gratitude. After the wedding, couples express thanks to family and community members who contributed. Wedding software that tracks contributions helps couples organize post-wedding thank-you notes and gestures.

Conclusion

Building software for Filipino weddings taught us that "localization" is a weak word for what we actually needed. We didn't just translate strings or change currency symbols — we rebuilt our product to accommodate different family structures, decision-making processes, and community relationships.

The lesson extends far beyond weddings. Any software claiming to be "global" should ask: Whose assumptions are we building on? Whose family structures? Whose communication patterns? Whose definition of trust?

Because the Filipino wedding isn't just different — it's a reminder that the world is bigger than our defaults.

Want to see how we handle other cultural challenges? Check out our homepage or explore our features and pricing guides.

How I Built a Wedding Planning Suite with Supabase in 3 Months

Jay WedPlanner — Fri, 28 Aug 2026 00:31:58 +0000

How I Built a Wedding Planning Suite with Supabase in 3 Months

Quick Answer: I built a full wedding planning platform in 90 days using Supabase as the backend (PostgreSQL database, real-time subscriptions, Row Level Security, and OAuth auth), Next.js 14 for the frontend, and a few carefully chosen npm packages for specific features like QR code scanning. The key was leveraging Supabase's managed services to avoid building auth, websockets, and file storage from scratch.

Introduction

Three months ago, I had an idea: what if couples could plan their entire wedding through one cohesive platform? Not a static checklist app, but a living, breathing system where vendors, guests, budgets, and timelines all talked to each other in real time.

I'm a solo developer with a day job. I didn't have a team of backend engineers to build authentication, real-time sync, or file storage infrastructure. I needed a stack that would let me ship fast without shipping broken.

Enter Supabase. I'd heard the "Firebase alternative" pitch before, but what I discovered was something far more powerful for developers who actually want to own their data and their SQL.

This is the story of how I built WedPlanner—a full wedding planning suite—with Supabase, Next.js, and a few other tools. No VC funding. No offshore team. Just me, a tight deadline, and a PostgreSQL database that never let me down.

Why Supabase? The Architecture Decision That Made Everything Possible

When you're building alone, every architectural decision compounds. Pick the wrong database, and you'll spend weeks fighting migrations. Pick the wrong auth solution, and you'll ship with security holes you don't even know about.

I evaluated Firebase, PlanetScale, Clerk, and rolling my own PostgreSQL on RDS. Here's why Supabase won:

PostgreSQL, not a proprietary document store. Wedding data is relational. A guest belongs to a wedding. A vendor has multiple bookings. A budget category has many line items. Trying to model this in Firestore's document model felt like forcing a square peg into a round hole. Supabase gave me the database I actually wanted—PostgreSQL 15—with a managed layer on top.

Built-in auth that doesn't fight you. Supabase Auth supports OAuth (Google, Apple, etc.), email/password with confirmation flows, and Row Level Security (RLS) policies that live in your database. This meant I could enforce "users can only see their own wedding data" at the database level, not just hoping my frontend checks were comprehensive enough.

Real-time subscriptions without WebSocket headaches. One of WedPlanner's killer features is the shared planning dashboard. When the bride updates the seating chart, the groom sees it instantly. Supabase's real-time feature is built on PostgreSQL's LISTEN/NOTIFY mechanism, which means I didn't have to maintain a separate WebSocket server or worry about reconnection logic.

Storage that makes sense. Wedding photos, vendor contracts, scanned receipts—I needed file storage with proper access controls. Supabase Storage integrates with RLS, so I could write policies like "only the wedding owner can view contract PDFs."

The total cost during development? Zero. Supabase's free tier handled everything until I had real users.

The Tech Stack Deep-Dive

Database Design: Weddings Are More Relational Than You Think

My initial schema seemed simple: users, weddings, guests, vendors. Then reality hit. A guest can have dietary restrictions. A vendor might serve multiple weddings. A budget line item might link to a specific vendor. A task in the timeline might depend on another task being completed first.

Here's the core schema I landed on:

I used Supabase's table editor for rapid prototyping, then migrated to managing schema through SQL migrations with the Supabase CLI. This gave me version control for my database structure—critical when you're iterating quickly and need to roll back.

One pattern that saved me: I created a weddings table as the central entity, then used foreign keys to link everything else. RLS policies then enforced that SELECT, INSERT, and UPDATE operations on any table required the user's ID to match the wedding's owner or collaborator list.

Authentication and Authorization: Trust the Database

I've seen too many apps where authorization is a frontend concern. Someone forgets a check, and suddenly users can see each other's data. With Supabase, I flipped this: the database is the source of truth for who can access what.

Here's an RLS policy example from my guests table:

This means even if a malicious actor crafted a raw HTTP request to my Supabase endpoint, they'd only ever see guests linked to weddings they own or collaborate on. The frontend is just a view layer; security lives in PostgreSQL.

For OAuth, I enabled Google and Apple sign-in through Supabase's dashboard. The redirect handling and token refresh were managed automatically. Total setup time: about 20 minutes.

Real-Time Features: When Everyone Needs to See the Same Thing

Wedding planning is collaborative. The couple, their parents, the wedding planner—everyone needs to stay in sync. I implemented real-time updates for:

Guest list changes (RSVP status updates)
Budget modifications
Timeline task completions
Vendor communication notes Supabase's real-time subscriptions use PostgreSQL's logical replication under the hood. On the frontend, it looks like this with the JavaScript client:

The subscription automatically handles reconnections, which was critical for mobile users who might switch between WiFi and cellular. I didn't write a single line of WebSocket management code.

Next.js 14: The Frontend That Keeps Up

I chose Next.js 14 with the App Router for several reasons:

Server Components by default. Most of WedPlanner's pages don't need client-side JavaScript to render. The guest list, budget dashboard, and vendor directory all render on the server, fetching data directly from Supabase using service role keys. This means faster initial page loads and better SEO for public-facing pages.

Client Components where needed. Interactive features—the real-time dashboard, drag-and-drop seating charts, image uploads—use client components with Supabase's browser client. The boundary is explicit and manageable.

API Routes for edge cases. While Supabase handles most CRUD operations directly from the frontend, I used Next.js API routes for complex operations like generating PDF exports of the seating chart or sending bulk SMS reminders to guests. These run server-side with access to server-only secrets.

QR Codes and Mobile-First Features

One feature I didn't expect to be so important: QR codes for check-ins. Each guest gets a unique QR code in their invitation email. On the wedding day, the venue staff scans codes with tablets to mark guests as arrived.

I used the qrcode package (82 million monthly downloads on npm) for generating codes server-side, and html5-qrcode (5 million monthly downloads) for the scanning interface. The integration was surprisingly smooth—the html5-qrcode library handles camera permissions, device selection, and error correction automatically.

Real-world lesson: always test QR scanning in low-light conditions. I had to bump error correction from 'M' to 'H' level because venue lighting was unpredictable.

What Went Right (and What Didn't)

The Wins

Rapid prototyping with the table editor. I built the first working version of the guest list in a weekend. Being able to create tables, add RLS policies, and test queries in the Supabase dashboard before writing a line of frontend code was a massive accelerator.

Type safety with generated types. Supabase's CLI can generate TypeScript types from your database schema. This meant my frontend code knew exactly what shape every query returned. No more any types or runtime surprises.

Edge functions for heavy lifting. When I needed to generate PDF seating charts or process image uploads (resize, compress, add watermarks), Supabase Edge Functions—Deno-based serverless functions—handled it without me provisioning a separate backend.

The Challenges

RLS debugging. When a query returns no rows, is it because there are no matching rows, or because RLS is filtering them out? Supabase's query logs help, but early on I spent hours chasing "bugs" that were actually policy misconfigurations. My fix: create a dedicated "admin" role for development that bypasses RLS, so I can quickly verify data exists.

Real-time subscription limits. Supabase's free tier has limits on concurrent real-time connections. For the wedding day itself—when potentially dozens of staff members might be scanning QR codes simultaneously—I had to implement connection pooling and ensure subscriptions were only active when the user was actually viewing a real-time dashboard.

File storage organization. Supabase Storage uses buckets, and I initially created too many granular buckets. Consolidating into a wedding-assets bucket with path-based organization ({wedding_id}/contracts/, {wedding_id}/photos/) simplified both code and RLS policies.

Performance and Scalability: Lessons from Real Usage

After launching with a beta group of 50 couples, I learned some hard truths about performance:

Database indexes matter. My initial guest list query was scanning thousands of rows because I hadn't indexed the wedding_id foreign key. Adding the right indexes dropped query time from 800ms to 12ms. Supabase's query performance advisor helped identify the culprits.

Connection pooling with Supavisor. Serverless functions (like Next.js API routes) can exhaust PostgreSQL connections quickly. Supabase's Supavisor connection pooler is essential for production. Without it, I'd hit connection limits during peak usage.

Selective real-time subscriptions. Early on, I subscribed to broad table changes. This meant every guest list update triggered a re-render for everyone viewing any wedding. Filtering subscriptions to specific wedding IDs cut network traffic by 90%.

Key Takeaways

Supabase's PostgreSQL foundation makes it ideal for relational data models like wedding planning, where entities have complex relationships
Row Level Security policies in the database are more reliable than frontend authorization checks
Real-time subscriptions work out of the box but need filtering to avoid broadcast storms
Next.js 14 Server Components reduce client-side JavaScript while maintaining interactivity where needed
Database indexes are not optional—measure query performance early and often
Supabase's free tier is genuinely sufficient for prototyping and small beta launches
Type generation from your actual database schema eliminates an entire class of frontend bugs
Connection pooling (Supavisor) is essential before going to production with serverless functions

Frequently Asked Questions

Is Supabase really free for small projects?

Yes. Supabase's free tier includes a full PostgreSQL database, authentication for unlimited users, 1GB of file storage, and real-time subscriptions. I never paid a cent during the entire 3-month development period.

How does Supabase compare to Firebase for relational data?

Firebase's Firestore is a document database, which makes complex relationships awkward. Supabase uses PostgreSQL, which handles foreign keys, joins, and complex queries naturally. If your data is relational, Supabase is the clearer choice.

Can Supabase handle real-time updates for multiple users?

Yes. Supabase uses PostgreSQL's logical replication to broadcast changes to subscribed clients. For WedPlanner, multiple users viewing the same wedding dashboard see updates within milliseconds of each other.

What is Row Level Security (RLS) in Supabase?

RLS is a PostgreSQL feature that Supabase exposes through its dashboard and API. It lets you define policies that control which rows a user can access based on their authentication state or user ID, enforced at the database level.

How did you handle file uploads for wedding photos?

I used Supabase Storage with RLS policies restricting access by wedding ID. Client-side uploads go directly to Supabase with a signed URL, and Edge Functions handle image resizing and compression.

Is Next.js 14 necessary, or would plain React work?

Plain React would work, but Next.js 14's Server Components let me fetch data on the server without exposing Supabase service keys to the browser. This improves both performance and security.

How many users can the free tier realistically support?

My beta had 50 couples (roughly 100 active users) with no issues. The free tier's main limits are on database size (500MB), file storage (1GB), and concurrent real-time connections. For a wedding app with seasonal usage patterns, this goes surprisingly far.

What was the biggest technical challenge?

Debugging RLS policies when queries returned empty results. The fix was creating an admin role for development and using Supabase's query logs to understand what was being filtered and why.

Did you use any paid services beyond Supabase?

Not during development. I used Vercel's free tier for Next.js hosting. The only potential paid service would be a transactional email provider for invitations, though Supabase's built-in auth emails handle the basics for free.

Would you choose this stack again?

Absolutely. The combination of PostgreSQL's power with Supabase's managed services and Next.js's rendering flexibility is hard to beat for solo developers shipping real products.

Conclusion

Three months ago, WedPlanner was a sketch in a notebook. Today, it's a production platform handling real weddings. The Supabase, Next.js, and PostgreSQL stack didn't just let me build fast—it let me build correctly.

If you're a solo developer or small team building something with complex data relationships, don't default to the document databases and third-party auth services that everyone tweets about. PostgreSQL has been production-ready for decades. Supabase just makes it accessible without a DevOps team.

The wedding industry doesn't need another "good enough" tool. It needs software built by people who understand that relationships—both database and human—deserve something robust.

Want to see WedPlanner in action? Visit our homepage to explore features, or check out our full feature guide and planning resources for couples getting started.

Have questions about the implementation? Drop a comment—I'm building in public, after all.

Integrating GCash & Maya: Philippine Payment Processing Guide

Jay WedPlanner — Tue, 25 Aug 2026 00:12:09 +0000

Integrating GCash and Maya: Payment Processing for the Philippine Market

Quick Answer: To integrate GCash and Maya, sign up for developer accounts with both providers, obtain API keys, build a unified payment abstraction layer in your backend, handle webhooks for real-time status updates, implement idempotency keys to prevent double-charging, and reconcile transactions daily against settlement reports. Both providers offer REST APIs with JSON responses, sandbox environments, and PHP-centric documentation, though the underlying protocols work with any modern stack.

Introduction

If you're building for the Philippine market, you already know the landscape: GCash dominates with over 80 million users, while Maya (formerly PayMaya) has carved out a strong position with roughly 30 million users and a growing suite of merchant tools. Together, they handle the lion's share of digital payments in the Philippines—far outpacing credit card adoption in a country where card penetration remains low.

But here's the thing most tutorials gloss over: integrating two different e-wallet providers isn't just about calling two APIs. It's about building a payment system that can handle inconsistent webhook timing, idempotent transaction states, reconciliation against daily settlement files, and the reality that many Filipinos switch between GCash and Maya depending on promotions or app availability.

This article walks through what we've learned building a unified payment layer for a Philippine marketplace. It's written in the spirit of building in public—sharing the patterns that worked, the traps that wasted weeks, and the production code we actually run.

Why GCash and Maya Together?

The Philippines is a mobile-first, cash-light economy where e-wallets function as de facto bank accounts for millions. GCash, backed by Alipay and local telco giant Globe, is the market leader with the widest agent network. Maya, backed by PLDT and now integrated with banking services, offers competitive merchant fees and a developer experience that some teams prefer.

Supporting both isn't a nice-to-have—it's table stakes. We've seen checkout conversion rates drop 15-20% when we only offered one provider, usually because the user's preferred wallet was either down for maintenance or they had funds in the other app. Offering both means covering nearly the entire addressable market of digitally paying consumers in the Philippines.

Getting Started: Developer Accounts and API Access

Before writing code, you need sandbox credentials from both providers. The process is similar but not identical.

GCash: Apply through the GCash Developer Portal. You'll need business registration documents (DTI or SEC), a live website or app, and a compliance review that typically takes 5-10 business days. Once approved, you get sandbox API keys for testing QR payments, direct debit, and the redirect-based checkout flow.

Maya: Maya's developer onboarding is faster—often 2-3 business days if your documents are complete. Their sandbox supports card payments, wallet payments, and QRPH (the interoperable QR standard). Maya also provides a handy webhook simulator that saved us hours of debugging.

One practical tip: create a shared .env structure early. We use separate prefixes to avoid key confusion in production:

GCASH_SANDBOX_BASE_URL=https://pgi.gcash.com/gcash/pg/v1
GCASH_PROD_BASE_URL=https://pgi.gcash.com/gcash/pg/v1
GCASH_MERCHANT_ID=your_merchant_id
GCASH_API_KEY=your_api_key
GCASH_WEBHOOK_SECRET=your_webhook_secret

MAYA_SANDBOX_BASE_URL=https://pg-sandbox.paymaya.com
MAYA_PROD_BASE_URL=https://pg.paymaya.com
MAYA_PUBLIC_API_KEY=pk-your_public_key
MAYA_SECRET_API_KEY=sk-your_secret_key
MAYA_WEBHOOK_SECRET=your_webhook_secret

Architecting a Unified Payment Layer

Rather than sprinkling GCash and Maya code throughout your application, build a single PaymentGateway abstraction. This is the pattern that saved our sanity when we added a third provider six months later.

Here's the interface we use:

interface PaymentGateway {
  createPaymentIntent(amount: number, currency: string, metadata: object): Promise<PaymentIntent>;
  verifyWebhookSignature(payload: string, signature: string): boolean;
  parseWebhookPayload(payload: string): WebhookEvent;
  getTransactionStatus(transactionId: string): Promise<TransactionStatus>;
}

Each provider implements this interface. The rest of your application—checkout flow, admin dashboard, refund logic—talks to the abstraction, not to GCash or Maya directly.

This matters because the two providers use different status codes. GCash returns SUCCESS, FAILURE, or PENDING. Maya returns PAYMENT_SUCCESS, PAYMENT_FAILED, PAYMENT_EXPIRED, or 3DS_REQUIRED. Your abstraction layer normalizes these into a unified enum before the rest of your system sees them.

Handling Webhooks: The Tricky Part

Webhooks are where most integrations stumble. Both GCash and Maya send asynchronous notifications to your endpoint when a payment succeeds, fails, or expires. But they differ in timing, retry logic, and payload structure.

GCash webhooks arrive within seconds of payment completion and retry up to 3 times with exponential backoff. Their payload includes a signature header signed with your webhook secret. Verify it.

Maya webhooks can occasionally arrive before the synchronous API response returns (race condition!). Maya retries for up to 24 hours and uses a different signature format—a base64-encoded HMAC-SHA256 of the raw payload.

Here's the defensive webhook handler we run in production:

app.post('/webhooks/gcash', express.raw({ type: 'application/json' }), async (req, res) => {
  const signature = req.headers['x-gcash-signature'];
  const payload = req.body;

  if (!gcashGateway.verifyWebhookSignature(payload, signature)) {
    return res.status(401).send('Invalid signature');
  }

  const event = gcashGateway.parseWebhookPayload(payload);

  // Idempotency: have we already processed this transaction?
  const existing = await db.transactions.findByProviderRef(event.providerRef);
  if (existing && existing.processedAt) {
    return res.status(200).send('Already processed');
  }

  await db.transactions.update(event.providerRef, {
    status: event.normalizedStatus,
    processedAt: new Date(),
    rawPayload: payload
  });

  res.status(200).send('OK');
});

The critical line: always return 200 OK quickly, even if you're going to process asynchronously. Both providers will mark undelivered webhooks as failed and retry, potentially creating duplicate work. We queue webhook events to a background job processor (BullMQ on Redis) and respond immediately.

Reconciliation: Don't Skip This

Webhooks are great, but they're not authoritative. Network partitions, provider outages, and race conditions mean your database can drift from reality. We reconcile against provider settlement reports every morning at 6 AM Manila time.

GCash provides a daily settlement file via SFTP. Maya offers a similar report through their merchant dashboard, downloadable as CSV. Our reconciliation job:

Downloads both reports
Compares every transaction ID against our database
Flags mismatches (e.g., webhook marked as SUCCESS but settlement shows FAILED)
Alerts the finance team via Slack for manual review In three months of operation, reconciliation has caught four legitimate discrepancies—small amounts, but amounts that would have become accounting nightmares if left unchecked. One was a GCash transaction where the webhook succeeded but the settlement file showed a partial refund due to a user dispute initiated minutes after payment.

Sandbox Testing: Simulate the Real World

Both providers offer sandbox environments, but testing payment flows thoroughly requires going beyond happy-path scenarios.

GCash Sandbox: Use the test credentials to simulate a wallet with insufficient funds, an expired OTP, or a user-cancelled transaction. The sandbox doesn't always mirror production latency—production webhooks can take 5-10 seconds during peak hours, while sandbox is near-instant.

Maya Sandbox: Maya's simulator is more configurable. You can trigger specific error codes (e.g., 2125 for insufficient balance) by passing test card numbers or wallet IDs. This is invaluable for automated integration tests.

We run nightly CI jobs against both sandboxes using Playwright to simulate full checkout flows. It's caught breaking changes twice—once when Maya updated their redirect URL format without notice, and once when GCash changed their signature algorithm from SHA-1 to SHA-256.

Common Mistakes and How to Avoid Them

We've made every mistake below. Learn from our pain:

Not validating webhook signatures: Early in our integration, we skipped signature verification for "speed." Within a week, a penetration test revealed that anyone could POST fake payment confirmations to our webhook endpoint. Always verify signatures.
Assuming synchronous responses are final: Both GCash and Maya return a status from their create-payment API, but the real source of truth is the webhook. Treat synchronous responses as "payment initiated," not "payment complete."
Hard-coding provider-specific logic in controllers: This creates technical debt fast. We refactored to the PaymentGateway abstraction after our first provider addition, and it paid for itself when we added a third.
Ignoring PHP documentation: Both providers ship PHP SDKs as their primary documentation. If you're on Node.js, Python, or Go, you'll need to translate examples. The underlying REST APIs are straightforward, but the PHP-centric docs can be frustrating.
Forgetting timezone handling: Settlement reports and webhook timestamps use Philippine Standard Time (UTC+8). Store everything in UTC internally, but convert for human-readable reports.

Security Considerations

Payment processing is a security-sensitive domain. Beyond webhook signature verification, implement these practices:

Store API keys in a secrets manager (we use AWS Secrets Manager), never in environment variables on developer machines
Rotate webhook secrets quarterly
Use TLS 1.3 for all API communications
Implement rate limiting on webhook endpoints to prevent abuse
Log all payment events with non-reversible identifiers (hashed transaction IDs) for audit trails without exposing PII

Costs and Pricing

Pricing varies by merchant volume and negotiation, but as of 2025, expect roughly:

GCash: 1.5-2.5% per transaction for QR payments; 2.5-3.5% for direct debit
Maya: 1.8-2.8% per transaction for wallet payments; 2.8-3.8% for card payments Both charge monthly platform fees for enterprise accounts. Volume discounts kick in around PHP 1M in monthly transaction value. For startups, Maya's lower barrier to entry (faster approval, lower initial fees) can be attractive, while GCash offers broader consumer reach.

Key Takeaways

Supporting both GCash and Maya is essential for Philippine market coverage—neither alone captures the full addressable market
Build a unified PaymentGateway abstraction early to avoid provider-specific technical debt
Treat webhooks as the source of truth, not synchronous API responses, and always verify signatures
Run daily reconciliation against settlement reports to catch discrepancies before they become accounting problems
Test beyond happy paths in sandbox environments, including insufficient funds, expired sessions, and network failures
Use idempotency keys to prevent double-charging when webhooks retry
Plan for provider API changes—automated nightly CI against sandboxes catches breaking changes early

Frequently Asked Questions

Can I use GCash and Maya without a registered business in the Philippines?

No. Both providers require DTI or SEC registration, a live website or mobile app, and a compliance review. This is a regulatory requirement for payment aggregators in the Philippines under BSP (Bangko Sentral ng Pilipinas) guidelines.

Which provider has lower transaction fees?

Maya typically offers slightly lower rates for smaller merchants, while GCash provides volume discounts that become competitive at scale. Rates range from 1.5-3.5% depending on payment method and monthly transaction volume.

How long does integration take?

With prepared documentation, a simple redirect-based integration takes 1-2 weeks. Building a fully featured system with webhooks, reconciliation, refunds, and idempotency typically takes 4-6 weeks for an experienced team.

Do I need a separate merchant account for each provider?

Yes. GCash and Maya operate independently. You'll go through separate onboarding processes, receive separate settlement reports, and manage separate API keys and webhook endpoints.

What happens if a webhook fails to deliver?

GCash retries up to 3 times with exponential backoff. Maya retries for up to 24 hours. Both expect a 200 OK response. If your endpoint returns errors or timeouts, the provider may eventually mark the transaction as failed even if the user actually paid.

Can I process refunds automatically?

Yes, both providers support API-initiated refunds, but the process differs. GCash refunds are typically processed within 24-48 hours. Maya refunds can be instant for wallet payments but may take 5-10 business days for card transactions.

Is QRPH (unified QR) supported?

Yes, both GCash and Maya support QRPH, the interoperable QR standard mandated by the BSP. This allows consumers to scan a single QR code regardless of which app they use. Implementation requires additional compliance steps.

What programming languages are supported?

Official SDKs exist for PHP, but the underlying REST APIs work with any language that can make HTTPS requests. We've successfully integrated using Node.js, Python, and Go. Community SDKs exist for most major languages.

How do I handle disputed transactions?

Disputes are handled through each provider's merchant dashboard. GCash and Maya both notify merchants via email and dashboard alerts. Keep detailed transaction logs, user communication records, and delivery confirmations to support your case.

Can I test in production?

Neither provider recommends production testing with real money. Use the sandbox environments for all testing. Some merchants create small-value test transactions in production, but this risks real fees and complicates accounting.

Conclusion

Integrating GCash and Maya isn't trivial, but it's very achievable with the right architecture. The key is treating payment processing as infrastructure, not an afterthought—build the abstraction, verify the webhooks, reconcile the books, and test the edge cases.

If you're building for the Philippine market and navigating these integrations, we'd love to hear about your experience. Drop a comment below with the patterns that worked (or didn't) for your team.

Looking for help with your payment infrastructure? [Internal link: homepage] Our team specializes in marketplace integrations across Southeast Asia, and we've built unified payment layers for platforms processing millions in monthly volume. [Internal link: services overview] We also publish regular deep dives on Philippine fintech, e-commerce, and developer tooling. [Internal link: latest articles]

Handling 500-Guest Filipino Weddings: How I Designed a Guest Management System

Jay WedPlanner — Fri, 21 Aug 2026 00:14:23 +0000

When my cousin announced her wedding in Pampanga with 500+ guests on the invite list, I did what any developer would do: I offered to build a system instead of helping with the seating chart. This is the story of how I designed a guest management platform that handled Filipino wedding logistics — and what I learned scaling it from a Google Sheet to a real app.

The Problem: Filipino Weddings Are a Different Beast

If you've ever been to a Filipino wedding, you know the scale. We're not talking about a cozy 80-person ceremony in a garden. We're talking about a parish church packed wall-to-wall, a reception in a covered basketball court or hotel ballroom, and a guest list that grows every time your Tita mentions the wedding to her mahjong group.

But the real challenge isn't the headcount — it's the ninong and ninang system. In Filipino wedding tradition, couples select principal sponsors (godparents) who play a ceremonial and financial role in the wedding. These aren't just VIP guests — they're part of the ceremony itself, they walk down the aisle, they sign the marriage contract, and they often contribute significantly to the wedding budget.

So my guest management system needed to handle:

Hierarchical guest roles — primary sponsors, secondary sponsors, bridesmaids/groomsmen, family, regular guests
Plus-one management — because Tito will absolutely bring his friend without telling you
Table assignments with sponsor priority seating near the head table
RSVP tracking with dietary preferences and entourage participation
Door check-in that could process 500 people without a 45-minute queue

Tech Stack: Keeping It Simple but Scalable

I went with a stack I knew well and could deploy fast — the wedding was three months away.

Frontend: Next.js 14 with App Router and Tailwind CSS
Backend: Next.js API routes + Prisma ORM
Database: PostgreSQL (hosted on Supabase — generous free tier)
QR Code generation: qrcode npm package (~82M monthly downloads, battle-tested)
QR scanning at the door: html5-qrcode library (~5M monthly downloads, supports both camera and file-based scanning)
Auth: Clerk — because I didn't want to build auth for a wedding app
SMS: Twilio for RSVP reminders (because Filipinos respond to texts, not emails)

The total cost? About $12/month for Supabase + $15 for the Twilio credits we used. The domain was free with a .pages.dev deployment.

Database Schema: The Sponsor Hierarchy

The core challenge was modeling the ninong/ninang system alongside regular guest management. Here's the schema I designed:

-- Simplified schema
model Guest {
  id           String   @id @default(cuid())
  weddingId    String
  firstName    String
  lastName     String
  role         GuestRole  // SPONSOR, ENTOURAGE, FAMILY, GUEST
  sponsorType  String?   // NINONG, NINANG, SECONDARY
  tableNumber  Int?
  plusOne      Boolean   @default(false)
  plusOneName  String?
  rsvpStatus   RsvpStatus @default(PENDING)
  mealPref     String?
  qrCode       String   @unique
  checkedIn    Boolean  @default(false)
  checkedInAt  DateTime?
}

enum GuestRole {
  SPONSOR      // Principal sponsors (ninong/ninang)
  ENTOURAGE    // Bridesmaids, groomsmen, bearers
  FAMILY       // Immediate family
  GUEST        // Regular attendee
}

enum RsvpStatus {
  PENDING
  CONFIRMED
  DECLINED
  MAYBE
}

The key insight: sponsorType is nullable because only SPONSOR-role guests have it. This let me run queries like "show me all ninongs who haven't RSVP'd yet" — which, spoiler, was all of them at first.

RSVP Workflow: SMS-First Design

Here's where I had to think about the user — and by "user" I mean 60-year-old Tito who has never scanned a QR code in his life.

The flow worked like this:

Invitation phase: Each guest got a physical invitation with a unique QR code printed on a card. The QR code encoded a URL like weddingapp.dev/rsvp/{token}
SMS nudge: Three weeks before the wedding, Twilio sent a text: "Tito Boy, please confirm your attendance for Anna & Mark's wedding on Oct 12. Tap here: [link]"
Mobile RSVP page: The link opened a mobile-optimized page showing the guest's name, role, and a simple Confirm/Decline/Maybe toggle plus meal preference dropdown
Auto-table assignment: Confirmed sponsors were auto-assigned to tables 1-5 (closest to head table). Other guests were auto-assigned by batch, with manual override available
Reminder cascade: Pending guests got a second SMS one week out, then a final one three days before

The SMS-first approach was critical. Initial email-only reminders had a 12% response rate. After adding SMS, RSVP confirmation jumped to 78%. Filipinos check text messages — they don't check email.

Door Check-In: Processing 500 Guests in 20 Minutes

The reception doors opened at 6 PM. By 5:45 PM there were already 80 people lined up. I needed a check-in system that was fast enough to prevent a bottleneck but smart enough to handle edge cases.

I built a simple admin dashboard with three check-in modes:

QR Scan mode: Using html5-qrcode on a tablet — scan the code on the invitation card, instant check-in, shows table number on screen
Name Search mode: For guests who forgot their card (this happened a lot) — type the first 3 letters of the last name, tap to check in
Bulk mode: For the entourage who all arrived together on a bus — select multiple guests and check them all in at once

The html5-qrcode library was a lifesaver here. It supports both getUserMedia camera access for live scanning and file-based QR decoding for uploaded images. I used the camera mode on an iPad at the door and it decoded invitations in under 300ms — fast enough that the queue moved smoothly.

One thing I didn't anticipate: the QR codes on invitations that got folded or crumpled wouldn't scan. The fallback name search saved us. Always build a manual fallback.

What I'd Do Differently

The wedding went smoothly — 487 of 512 invited guests showed up, check-in took 22 minutes, and the seating assignments worked. But if I were to build this again:

Offline mode: The venue Wi-Fi was spotty. I'd add a PWA service worker with local caching so check-in works without internet
Pre-seated table visualization: A drag-and-drop seating chart would've saved me two hours of manual table shuffling at 2 AM
Dietary restriction aggregation: I had it in the schema but didn't build a summary view. The caterer asked for a count of vegetarians and I had to run a raw SQL query on my phone
Multi-language support: Some older relatives would've benefited from a Tagalog RSVP page. i18n from the start next time

Conclusion: Build for the User, Not the Spec

The biggest lesson from this project wasn't technical — it was human. I started by designing a beautiful, feature-rich web app. But the feature that mattered most was a simple SMS with a tappable link. The technology that saved the day wasn't a fancy framework — it was a QR code scanner that worked in 300ms.

Filipino weddings are logistically complex, but they're also deeply communal. The ninong/ninang system isn't just a hierarchy — it's a support network. My system needed to respect that structure while making it manageable. And it needed to work for a Tita who's 67 and has an old Samsung phone.

If you're building event management software, spend less time on your tech stack and more time on your user's phone. The best system is the one people actually use.

Planning a wedding or large event? WedPlanner has tools for seating charts, RSVP tracking, and guest management built specifically for large celebrations. Check out our RSVP management guide and our seating arrangement tools for more.

From Tita's Wedding Checklist to a SaaS Product: Building WedPlanner.ph

Jay WedPlanner — Tue, 18 Aug 2026 08:07:55 +0000

It Started With a Tita's Notebook

Every Filipino family has that one Tita — the one who organizes everything. She's the one who knows whose turn it is to bring lechon to the reunion, who keeps the family birthday calendar, and who somehow remembers your anniversary before you do.

Our Tita was also a part-time wedding planner. Not the glamorous kind you see on Pinterest — the practical, pen-and-notebook kind who tracked budgets on graph paper and kept vendor contacts in a battered Nokia phone. When she passed the notebook to us and said, 'Can you put this online so I don't lose it again?', we laughed. Then we looked at the 200+ pages of meticulously organized wedding checklists, vendor lists, budget trackers, and seating arrangements — and stopped laughing.

That notebook became the blueprint for WedPlanner.ph.

The Problem Nobody Was Solving (Properly)

The Philippines has one of the most vibrant wedding industries in Southeast Asia. Over 400,000 marriages are registered annually, and the average Filipino wedding costs between ₱300,000 to ₱800,000 — a significant investment for families where weddings are community events, not just couple's events.

Yet most couples were still planning their weddings with:

Excel spreadsheets that broke when you sneezed at them
Facebook groups full of vendor recommendations with no way to verify them
Google Docs shared between 5 family members who kept editing the same cell
That one cousin who 'has a spreadsheet for everything' but never shares it on time The existing tools? Either they were built for Western weddings (no ninong and ninang tracking, no despedida de soltera timeline, no abay coordinator notes) or they were expensive SaaS products priced in USD — way out of reach for the average Filipino couple.

We saw the gap. Tita's notebook had the domain knowledge. We had the technical chops. The question was: could we turn a graph-paper system into a product?

Building the MVP — Tita's Checklist Goes Digital

We gave ourselves 8 weeks. Not because of some lean startup methodology — because wedding season was approaching and we wanted to test with real couples planning real weddings.

Week 1-2: Extracting the Domain Knowledge

The first two weeks weren't coding. They were reading. We sat with Tita and went through every page of that notebook. What emerged was a surprisingly sophisticated planning system:

Phase-based timeline: 12 months out, 6 months out, 3 months out, 1 month out, week-of, day-of
Role-based task assignment: tasks weren't just 'to-do' — they were assigned to specific people (the couple, the parents, the coordinator, the abay)
Budget envelope system: not just a total budget, but per-category envelopes with priority weighting
Vendor tracking with ratings: not just contacts, but notes on reliability, pricing tiers, and whether they showed up on time This was domain gold. No Western wedding app had this structure because Western weddings don't have ninongs and ninangs as sponsors, or despedida de soltera as a pre-wedding event, or the concept of abay (entourage) with specific duties.

Week 3-6: Building the Core

We chose a stack we knew cold: Next.js for the frontend, Supabase for the database and auth, and TailwindCSS for styling. We went with Supabase specifically because we needed real-time collaboration — when the bride's mother and the wedding coordinator are both editing the seating chart simultaneously, you need WebSocket sync, not polling.

The core features we shipped in the MVP:

Interactive wedding checklist — Tita's phase-based timeline, digitized and assignable to team members
Budget tracker with envelopes — per-category budgets with visual progress bars and overspend alerts
Guest list manager — with side-of-family tagging, sponsor tracking, and table assignment
Vendor directory — seeded with Tita's contacts, searchable by category, location, and budget tier
Entourage manager — because tracking 20+ abay members with their roles, attire, and contact info is its own logistics system One of the hardest technical challenges wasn't the features — it was the offline-first requirement. Filipino weddings happen in venues with spotty WiFi (beaches, provincial churches, garden receptions). The coordinator needs to check off tasks on the day-of without a connection. We implemented a local-first sync layer using IndexedDB and a queue-based conflict resolution system. Not glamorous, but it was the difference between a tool people use and a tool people abandon.

Week 7-8: Polish, Test, Panic

We ran the MVP through 3 test couples — Tita's actual clients who were in the 3-month-out phase of planning. The feedback was immediate and brutal:

'Why can't I add my ninong as a sponsor in the guest list?' — Fixed in 2 hours. We had hardcoded 'bride' and 'groom' sides only.
'The budget tracker doesn't let me mark something as padala (gifted by family)' — Added a 'sponsored' flag to budget items.
'Can the checklist send reminders to my coordinator?' — Not in the MVP, but it became our #1 feature request. Each piece of feedback confirmed what we suspected: the product was valuable because it understood Filipino wedding culture. The localization wasn't a feature — it was the foundation.

Getting First Users — The Philippine Way

Here's where most startup playbooks would say 'launch on Product Hunt' or 'post on Hacker News.' We did neither. Instead, we went where Filipino brides actually hang out:

Facebook Wedding Groups

The Philippines runs on Facebook. There are dozens of active wedding planning groups with tens of thousands of members each — Wedding Planning Philippines, Brides-to-be PH, Kasal Tipid Tips. We didn't spam. We participated. We answered questions about budget allocation. We shared Tita's checklist as a free PDF download (with a WedPlanner.ph watermark, naturally). When people asked 'is there an app for this?', someone else — not us — would recommend WedPlanner.ph.

That organic word-of-mouth brought us our first 200 users in 3 weeks. Zero ad spend.

Tita's Network

Tita had been planning weddings for 15 years. She had a WhatsApp group with 40+ past brides. We sent them a personal message (not a broadcast) asking them to try the platform and share it with any engaged friends. 12 of them became active users. 7 referred at least one new couple. The LTV of a referred user in our early data was 3.2x higher than a cold signup — Tita's network wasn't just user acquisition, it was quality user acquisition.

Wedding Expos (Pop-up Strategy)

We couldn't afford a booth at the big wedding expos (₱50,000+ for a 2x2 meter table). So we did pop-ups. We showed up at the free community wedding fairs organized by local government units and churches. We brought a tablet, a WiFi hotspot, and Tita. People could sign up on the spot, and Tita would personally walk them through the checklist. The conversion rate at these events was 40% — compared to 8% from online signups. The lesson: in the Philippines, trust is built face-to-face.

What We Learned Building a SaaS for the Philippine Market

1. Localization > Features

We spent zero time on fancy features in the MVP. We spent enormous time on getting the Filipino wedding context right. The despedida de soltera timeline. The ninong/ninang sponsor system. The abay hierarchy. These aren't 'features' — they're the reason the product exists. A Western wedding app with 100 features but no padala tracking is useless to a Filipino couple.

2. Mobile-First Isn't Optional

92% of our early users accessed WedPlanner.ph from their phones. Not surprising — the Philippines is a mobile-first country with one of the highest mobile internet penetration rates in Southeast Asia. But 'mobile-first' isn't just responsive design. It's:

Data-light pages (many users on prepaid data)
SMS reminders (not everyone has push notifications enabled)
Touch-optimized interactions (drag-and-drop seating charts don't work well on a 5-inch screen)
Offline sync for day-of coordination

3. Pricing for the Philippine Market

We launched with a freemium model: free for the core checklist and guest list, ₱299/month for the full suite (budget tracker, vendor directory, coordinator dashboard). That's about $5 USD — a fraction of what Western wedding planning apps charge, but aligned with what Filipino couples are willing to pay for a digital tool. The key insight: pricing isn't about what the product is worth in absolute terms, it's about what the market can absorb relative to the total wedding budget. ₱299/month against a ₱500,000 wedding budget feels negligible. ₱2,000/month feels like a line item.

4. Community Is the Best Marketing

Our CAC (customer acquisition cost) for the first 500 users was effectively ₱0 — just time and Tita's network. Every paid channel we tested (Facebook ads, Google Ads, influencer posts) had higher CAC and lower retention than organic community referrals. In a market where personal recommendations carry more weight than branded ads, investing in community presence pays compounding dividends.

What's Next

WedPlanner.ph is live, growing, and serving couples across the Philippines. We're now working on:

Vendor marketplace: letting couples book vendors directly through the platform
AI-powered budget optimization: suggesting reallocations based on the couple's priorities
Multi-language support: Tagalog and Cebuano interfaces, because not every Filipino couple plans their wedding in English The notebook is still on Tita's desk. But now, the knowledge inside it lives in a product that any Filipino couple can access — whether they're planning a grand cathedral wedding in Manila or a beach ceremony in Palawan.

If you're building a SaaS product for a local market, here's our advice: find your Tita. Find the person with the domain knowledge that no competitor has. Digitize what they know. Build for the culture, not against it. And when in doubt, ask: would this work at a wedding in probinsya with spotty WiFi and 300 guests? If the answer is yes, you're on the right track.

Check out WedPlanner.ph to see what we built, browse our wedding checklist templates, or explore budget planning tools designed for Filipino weddings.

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

Jay WedPlanner — Tue, 11 Aug 2026 22:09:13 +0000

Six months ago, I sat down with a cup of barako coffee and a spreadsheet full of wedding planning apps. The global market had The Knot, Zola, and WeddingWire — polished, feature-rich, and completely useless for a Filipino couple planning their kasal.

That was the moment I decided to build WedPlanner — the first online wedding planning tool built from the ground up for the Philippine market.

Here's what I learned about localizing a SaaS product for a market that global players consistently get wrong.

The Problem With "Just Translate It"

When most SaaS companies think about localization, they think about language. Swap English for Tagalog, change the currency symbol, ship it. That approach fails spectacularly in the Philippine wedding space, and here's why.

A Filipino wedding isn't just a ceremony and reception. It's a multi-month production involving pamamanhikan (the formal meeting of families), despedida de soltera (the send-off party), a sabitan (money dance), and a guest list that routinely hits 150-300 people because your mom's kumare from college absolutely must be invited.

No Western wedding app models any of this. Their guest list tools assume 80-120 guests. Their budget trackers don't have a line item for lechon (PHP 8,000-15,000 depending on size). Their timeline templates start at "6 months before" — which is laughable when Filipino engagements routinely run 12-18 months.

I learned this the hard way in week two, when I showed an early prototype to my cousin who was planning her Tagaytay wedding. She scrolled through the guest list feature and said, "Saan ko ilalagay yung ninong at ninang?" — Where do I put the godparents?

In a Filipino wedding, ninong and ninang (principal sponsors) aren't just guests. They're part of the ceremony, they sign the marriage contract, and they often contribute significantly to the wedding budget. My guest list had a single "Guest" type. I needed at least five: Principal Sponsor, Secondary Sponsor, Entourage, Family, and Guest. That one conversation saved me months of building the wrong thing.

Me realizing that "just add a Tagalog translation" was not going to cut it.

PHP Currency: More Than Just a Peso Sign

Switching the currency from USD to PHP sounds trivial. Change the symbol, adjust the exchange rate, done. Right?

Wrong. Here's what actually matters when you're building a budget tool for Filipino couples:

1. PHP amounts don't scale like USD. A "mid-range" wedding budget in the US might be $30,000. In the Philippines, a comfortable middle-class wedding runs PHP 300,000-500,000. That's a lot of zeros. Display formatting matters — PHP 350,000 reads differently than ₱350,000, and both read differently than 350k. We tested all three and found that "PHP 350,000" had the highest comprehension in user testing, especially for OFW couples who think in both pesos and their host country's currency.

2. Budget categories are completely different. A Western wedding budget allocates 40-50% to the venue and catering. In the Philippines, the church fee might be PHP 5,000-15,000, but the souvenirs (giveaways for 200 guests) can run PHP 20,000-40,000. The photographer is non-negotiable (Filipino weddings are heavily documented). The barong and gown budget is its own category. We had to rebuild the entire budget template from scratch.

3. Payment methods are market-specific. This brings me to the biggest localization challenge we faced.

The GCash Integration That Almost Broke Me

In the Philippines, credit card penetration is around 3-5%. But GCash? Over 90 million registered users. If you're building a SaaS product for the Philippine market and you don't support GCash, you're leaving 80%+ of your potential users behind.

I knew this intellectually. What I didn't know was how painful the integration would be.

GCash doesn't have a Stripe-like developer experience. Their API documentation in 2025 was sparse, their sandbox environment had inconsistent behavior, and the approval process for production access took six weeks and required a face-to-face meeting with their business development team in BGC.

Here's what the integration flow looks like:

QR Code Generation: Generate a dynamic QR code for each transaction. The user scans it with their GCash app to pay. This is the most common flow for web-based SaaS.
Webhook Callbacks: GCash sends payment confirmation via webhook — but the webhook format changed twice during our integration period without documentation updates. We built a webhook adapter layer that normalizes the payload regardless of which version GCash sends.
Timeout Handling: GCash payments can take 30-90 seconds to confirm. Users would close the tab thinking the payment failed. We added a persistent "Waiting for GCash confirmation..." screen with a countdown timer and SMS fallback notification.

The lesson: when localizing payments, budget 3x the integration time you think you'll need. The documentation gap between global payment processors (Stripe, PayPal) and regional ones (GCash, Maya, GrabPay) is enormous. What takes 2 days with Stripe can take 2 months with a regional provider.

Week 4 of the GCash integration, waiting for their sandbox to stop returning 500 errors.

Filipino Wedding Customs Are Not Edge Cases

One of the biggest mistakes I see in SaaS localization is treating cultural differences as "edge cases" — something you handle with a config flag or a custom field. Filipino wedding customs are not edge cases. They are the core product.

Here are three features we built that no Western wedding app has:

1. Ninong/Ninang Manager. Principal sponsors in a Filipino wedding aren't just names on a list. They have specific roles in the ceremony (cord, veil, arrhae/coins), they often contribute financially, and they need to be seated in a specific order. Our tool lets couples assign roles, track contributions, and generate a seating chart that respects the ninong/ninang hierarchy.

2. Pamamanhikan Planning Module. Before any wedding planning happens, there's pamamanhikan — the formal meeting where the groom's family visits the bride's family to ask for her hand. This involves food (lots of it), specific protocols, and sometimes a pamanhikan gift. We built a checklist and timeline specifically for this pre-wedding milestone because every Filipino couple we interviewed mentioned it as a stress point.

3. Digital Cash Gift Registry. At Filipino weddings, guests pin cash to the bride and groom during the money dance (sabitan). It's beautiful, cultural, and increasingly digital. We integrated GCash and Maya QR codes into the wedding website so guests who can't attend (or prefer digital) can still send their pakimkim (cash gift). This feature alone drove 40% of our early sign-ups.

If you want to dive deeper into how Filipino wedding traditions shape the planning process, we've written extensively about it in our guide to Filipino wedding traditions.

The Tech Stack: Pragmatic Choices for a Solo Developer

I built WedPlanner as a solo developer with a budget of roughly PHP 50,000 for infrastructure in the first six months. Here's what I chose and why:

Next.js + Supabase: Next.js for the frontend (SSR for SEO, which matters enormously for organic discovery in the Philippines where Google is the primary research tool). Supabase for the backend — their free tier got me through the first 3 months, and their PostgreSQL database handles the complex relational data (guests → tables → seating charts → sponsors) beautifully.
Vercel for hosting: Free tier covered the first 100GB of bandwidth. Edge functions in Singapore give sub-100ms latency for Philippine users.
GCash + PayMongo for payments: PayMongo acts as the payment orchestration layer, connecting to GCash, Maya, and card payments through a single API. This was the smartest architectural decision I made — when GCash changed their API, I only had to update the PayMongo integration, not my entire payment flow.
React Email + Resend for transactional emails: Wedding planning involves a lot of reminders. RSVP deadlines, payment confirmations, vendor booking confirmations. Resend's free tier (100 emails/day) was enough for the first 1,000 users.

Total monthly burn rate for the first 6 months: $0. Everything ran on free tiers. I only started paying when we crossed 1,000 active users.

What I'd Do Differently

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

1. Start with mobile-first, not responsive. 75% of our traffic comes from mobile devices. Filipino couples plan their weddings on their phones — during commutes, lunch breaks, while lying in bed at 11 PM. I built desktop-first and made it responsive. I should have designed for a 375px screen from day one.

2. Invest in Filipino-language content earlier. We launched with English-only content. Our first Taglish blog post (mixing English and Tagalog naturally, the way Filipinos actually speak) got 3x the engagement of our English-only posts. The WedPlanner blog now publishes daily content in a warm, conversational Filipino voice — and our organic traffic has grown 15% month-over-month since making that switch.

3. Build the vendor marketplace sooner. Filipino couples don't just want a planning tool — they want to find suppliers. Photographers, coordinators, caterers, HMUAs (hair and makeup artists). We launched without a vendor directory and spent months playing catch-up. If you're building a vertical SaaS tool, the marketplace is not a "nice to have" — it's the retention engine.

4. Don't underestimate the marites factor. Filipino wedding planning is deeply social. Brides share everything in Facebook groups, Viber chats, and family group chats. We should have built sharing features (share your checklist, share your budget breakdown, share your wedding website) from day one. Word-of-mouth in the Philippines is amplified by social media in ways I didn't fully appreciate until I saw our analytics.

Every mistake is just a lesson you haven't finished learning yet.

The Numbers (Because Building in Public Means Sharing the Real Data)

I believe in building in public, so here are the actual numbers as of August 2026:

Registered users: 2,400+ couples
Active wedding plans: ~850 currently being actively managed
Monthly active users: 1,100+
Paying customers: 180+ (on the Premium plan at PHP 499/month)
MRR: ~PHP 90,000 (~$1,600)
Customer acquisition cost: Effectively PHP 0 — all growth has been organic through SEO, Facebook wedding groups, and word of mouth
Churn rate: ~8% monthly (couples stop planning after their wedding — this is a lifecycle churn problem we're actively working on)

We're not profitable yet, but we're cash-flow positive on operating costs. The next milestone is 500 paying customers, which at current growth rates should happen by Q4 2026.

Key Takeaways for Anyone Localizing SaaS

If you're building a SaaS product for a specific regional market, here's what I want you to remember:

Language is the least important part of localization. Cultural workflows, payment methods, and social behaviors matter far more than translation. A perfectly translated product that doesn't understand pamamanhikan is still a bad product.
Regional payment integration will take 3-5x longer than you expect. Budget for it. GCash, Maya, GrabPay — these are essential in Southeast Asia, and their APIs are not Stripe. Build an abstraction layer from day one.
Talk to actual users before writing a single line of code. My cousin's "Saan ko ilalagay yung ninong at ninang?" question saved me months of building the wrong guest list feature. One conversation with a real user is worth more than a month of assumptions.
Free tiers are your best friend as a solo builder. Supabase, Vercel, Resend, GitHub — the free tiers of modern developer tools are genuinely generous. Use them until you have revenue, then upgrade.
Content in the local voice wins. Our Taglish blog posts outperform our English ones by 3x. Write the way your users actually speak.

Building WedPlanner has been the hardest and most rewarding thing I've ever done. The Philippine market is underserved by global SaaS products, and that's not a bug — it's an opportunity. If you're thinking about building for a market that the big players ignore, do it. Just make sure you actually understand the market before you start coding.

Have you built a localized SaaS product? I'd love to hear about your experience in the comments. And if you're planning a Filipino wedding, check out WedPlanner — we built it for you.

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

Jay WedPlanner — 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 WedPlanner — 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 WedPlanner — 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 WedPlanner — 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 WedPlanner — 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 WedPlanner — 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.