Let's Chat

Hitchbird

A destination-wedding marketplace connecting couples to venues and vendors across Asia—the original platform I built during Hitchbird's founding year, before the company went on to become Asia's largest in the category.

Role Founding Engineer / Initial Lead Developer
Domain Wedding Marketplace / Travel / Asia
Focus Platform architecture, AWS infrastructure, vendor marketplace, search and filtering
Hitchbird homepage hero with destination wedding banner, twelve wedding theme inspiration icons, and the start of the country grid
The homepage I built: destination wedding hero, 12 wedding-theme inspiration icons, and the start of the country grid

The Problem

A Fragmented Market

Planning a wedding is hard. Planning a wedding overseas is harder—twice the romance, twice the difficulty, as the founding story put it. In 2015 there was no central destination-wedding marketplace for Asia: venues and vendors were scattered across blogs, magazines, agencies, and word of mouth. Couples planning in Bali, Phuket, Kyoto, or the Maldives were stitching together research from dozens of sources across languages and currencies.

The Founder's Own Story

Hitchbird's founder, Tammy To, had lived this exact problem. When her own destination wedding clashed with a national day of mourning and a political rally, the airports shut down and she had to re-plan the entire wedding in a different city. Hitchbird was born from that experience—the mission was to make sure other couples didn't repeat those mistakes.

No Existing Platform

The "TripAdvisor for weddings" idea was clear, but the product did not exist. The brief was to build the first version of a marketplace where couples could discover destinations, browse themed inspiration, search vendors by city and category, sign up vendors, and write reviews—across 19 countries at launch.

Constraints & Considerations

  • Founding Stage — There was no existing team, no codebase, and no conventions. I joined alongside the founders at the very beginning, with weekly catch-ups and a shared vision driving most decisions. Coding standards had to be defined as I built.
  • Solo Engineering, Tight Timeline — I was effectively the only engineer. Architecture choices had to balance speed of shipping against the need for the platform to scale as the team grew after I moved on.
  • Geographic Spread — Vendors, venues, and couples were spread across 19 countries at launch, with multiple languages, currencies, and wedding conventions. The data model had to be country-aware from day one.
  • Content-Heavy, Image-Heavy — Wedding content is overwhelmingly visual. The system had to handle large image volumes per vendor, multiple image sizes (grid, list, sidebar), and pre-resized assets for performance.
  • Hybrid Stack — The marketing blog and content pages ran on WordPress; the marketplace itself needed a more structured, transactional framework. The two systems had to live alongside each other cleanly.

Role & Leadership

I joined Hitchbird at the very beginning as the founding engineer, building the platform from an empty repository through the MVP launch and into Phase 2. This included the technical foundation, AWS infrastructure, the public-facing site, the vendor-facing flows, and the data import pipeline that bootstrapped hundreds of pre-launch vendors from spreadsheets.

Architecture & Stack Decisions

Chose CodeIgniter 2.2.2 on PHP with MySQL as the core—familiar, fast to ship, and easy to hand off. Layered Apache Solr for search, LESS for CSS preprocessing, and PHPUnit (wired up, with tests pending) for unit testing. Source control lived in a private Bitbucket repository.

AWS Infrastructure

Set up the full AWS stack from scratch: EC2 for compute, RDS for MySQL, S3 for vendor image storage, CloudFront in front of S3 for delivery, SES for transactional email, and Elastic Beanstalk for staging and production deployments. Staging and production ran as parallel EB environments with their own RDS instances.

Theming & Layout Engine

Built a seven-file theming system under themes/hitchbird/—global, meta, header, guest header, sidebar, footer, breadcrumb—wired through a custom layout library loaded from each controller. Pages registered their CSS and JS through addCSS / addJS, so each screen only shipped what it needed.

Data Model & Migrations

Designed the schema for countries, cities, themes, categories, vendors, vendor images, users, and reviews. Every change went through the CodeIgniter migrations system—no direct DB edits—so the schema could be reproduced cleanly across dev, staging, and production. Models extended Jamie Rumbelow's codeigniter-base-model for consistent CRUD and auto-timestamping.

Vendor Onboarding

Built the multi-step vendor signup (themed selections, country/city, category, pricing range, profile, photos), the vendor dashboard, and the public vendor profile pages. Vendors could upload images in pre-defined sizes (grid, list, sidebar) so layouts stayed consistent across the marketplace.

Vendor Authentication

Wired up Ben Edmunds' Ion-Auth for the vendor-facing auth and role system, with XSS and CSRF filtering enabled globally via CodeIgniter's form helpers.

Approach & Execution

The build was structured as two phases: Phase 1 was the public marketplace couples would see; Phase 2 was the vendor-facing side and the data tools the team needed to grow the catalog. I worked across both, often in the same week, because everything fed the same data model.

Public Site — Homepage

The hero introduced "Destination Wedding" with a country-picker below. A row of 12 wedding-theme icons (Beach, Castle, City, Villa, Nature, Winter, Theme Park, Cultural, Casino, Luxury, Vineyard, Adventure) drove users into themed listings. Below that, a country grid (19 countries at launch: Hong Kong, Singapore, Indonesia, India, Thailand, Taiwan, Korea, New Zealand, Japan, Malaysia, and more) gave visual entry points into each market, with a blog feed and a six-tile "Everything you need to plan" navigation grid at the bottom.

Public Site — Country & City Pages

Country pages (e.g. Japan) opened with a hero and three quick tabs: Things to do, Map, Travel guide tips. City pages (e.g. Kyoto) added a left-rail filter (wedding theme, country, city, stars, capacity, type, venue settings, keyword search), a grid / list / compare toggle, and a right-rail of recommended vendors, daily blog teasers, and inspiration tiles. Listing order used a randomized "five-star" rotation for the first few cards until engagement data settled in.

Vendor Profiles & Compare

Each vendor had a public profile pulled from the same data model used in the dashboard. A "Compare" feature let couples pin vendors side-by-side. Vendors could be favorited (logged-in users) and listed in "You may also like" and "Recently viewed" carousels powered by the search history.

Search — Solr + AJAX

Vendor search ran through Apache Solr (separate test and production cores, refreshed from MySQL on a schedule). The search page itself used AJAX to load results, recommended items, "you may also like," and "recently viewed" without a full page reload, so users could keep browsing while filters changed.

Vendor Dashboard

The dashboard let vendors edit profile fields, manage images (with the same size presets used on the public site), respond to reviews, and see review activity. Authentication was separate from the public site through Ion-Auth, with CSRF protection on every form.

Data Import Pipeline

The catalog was bootstrapped from a set of vendor spreadsheets—country info, cake, dress & gown, flowers, hair, photography & videography, registry, transportation, wedding planner, wine, jewellery, tour & travel agency, venues. I built CLI commands (php index.php cli/import import_misc, import_country_info, import_all_vendors, import_images) that ran in sequence with log files so the founding team could reload the catalog cleanly after any schema change. Image imports were pre-sized and zipped before being uploaded to S3.

Email — SES, Templates, Notifications

Transactional email (vendor sign-ups, password resets, review notifications) ran through AWS SES via SMTP with TLS. Templates were HTML, designed to match the public site's visual language.

WordPress Integration

The blog and content pages ran on WordPress, deployed alongside the CodeIgniter app under the same domain. I integrated the two so the blog feed on the public homepage, city pages, and vendor dashboards pulled directly from the WordPress REST API.

Responsive Design

The brief was explicit about responsive design from day one. Filter sidebars collapsed on small screens, carousels reflowed, and city/country heroes resized. Image dimensions were standardized across breakpoints (grid 242×166, list 216×116, sidebar 127×100) so the layout stayed consistent regardless of where a vendor image originated.

Hitchbird homepage with the wedding-theme selector expanded, showing all 12 wedding theme icons
The 12 wedding-theme selector—each icon filtered the entire catalog into a themed view
Kyoto, Japan city page with sidebar filters, vendor listing, and recommended vendors rail
Kyoto city page: filter rail, grid/list/compare toggle, recommended vendors and inspiration sidebar

Outcome & Impact

Marketplace Scale (after my time)

By 2018, Hitchbird listed 5,000+ wedding vendors across 53 cities in Asia—then the largest wedding marketplace for premium brands in the region. Today it lists 5,000+ suppliers in 30 categories across 75 cities, alongside its full-service Hitchbird Bespoke and Fleur wedding-planning and styling arms.

Funding

In April 2018, Hitchbird raised a seed round led by Catcha Group (Patrick Grove) with participation from Ken Tsurumaru, a former Catcha director and co-founder. The capital funded hiring, product, and marketing for further regional expansion.

Platform Longevity

The original CodeIgniter / PHP 5 codebase I built ran in production for years after I left. The data model and migrations survived a full rewrite to Laravel + NuxtJS in 2019—the kind of handoff you can only get when abstractions are kept honest. hitchbird.com is still live and still operating.

Founding Engineer Outcome

I built the platform during the first nine months—March to November 2015—and handed it off before moving on to other ventures (notably Jou Sun in 2016). The work files, design source, AWS credentials, and development documentation are all preserved, which is itself a small artifact of how the project was run.

Japan country page with hero, things-to-do tiles, and vendor listing with sidebar filters
Japan country page—hero, things-to-do grid, and the same vendor listing engine the city pages used
Key Takeaway

Founding-stage platforms are won or lost on the data model. The theming engine, AWS infra, and AJAX search were all important, but the real reason Hitchbird's catalog scaled to thousands of vendors across dozens of countries was that every country, city, theme, category, vendor, and image went through the same migration system and the same import pipeline from day one. Keep the abstractions honest, and the company can outgrow your stack.

Skills & Tools

CSS Mobile Responsiveness Performance Optimization Code Review CodeIgniter / PHP Architecture MySQL Database Design AWS Infrastructure (EC2, RDS, S3, SES, Elastic Beanstalk) Apache Solr Search jQuery Frontend WordPress Integration LESS / CSS Preprocessing Responsive Design Database Migrations CLI Data Import Pipelines AJAX-driven Search Vendor Onboarding UX Multi-step Signup Flows Theming / Layout Engine PHPUnit Setup Git / Bitbucket Bootstrap a Startup Platform
← Previous: Klosit Back to Work Next: Jou Sun →