Vi Nguyen

The stack

• Marketplace app on Bubble — listings, search, messaging, host dashboard, subscriptions.
• Marketing site and blog on Next.js / Vercel, with the app acting as the CMS behind the blog.
• Search infrastructure — a Postgres read-mirror of the listing data, so city and map search doesn't run against the app database.
• Billing — Stripe subscriptions across three portfolio-sized plan tiers, plus the sync layer that keeps the app and Stripe consistent.
• Analytics — Mixpanel behind a first-party proxy, reconciled daily against Stripe.

Recent platform work

• A framework upgrade across two major versions, including the middleware-to-proxy migration and the runtime change that came with it.
• SEO migration: canonical and OG-image fixes, a 301 map off the legacy URL scheme, and a sitemap rebuilt to 2,826 URLs including 602 city pages.
• A crawler gate that was returning 503s to link unfurlers — diagnosed, exempted, and covered with a unit test.

The problem

The account page had a cancel control and a Manage Billing button. Neither worked for most people, and the code looked correct when read in isolation.

What was happening

• The cancel control was gated on a status string with a capital letter, while the sync job writes the payment provider's own lowercase value. The condition was never true, so the button never rendered.
• The billing portal resolved the customer from a field that most accounts had never been given. Legacy accounts carried an older identifier format entirely, from a migration years earlier.
• Cancelling an annual plan that was already past due scheduled the cancellation for the end of the term, which gave that account another year.

What I built

• Rewrote the visibility conditions to normalise case, and widened them to cover past-due accounts rather than only active ones.
• Rewrote the portal endpoint to resolve the customer from the subscription record rather than a stored customer ID, so it works regardless of when an account was created.
• Added an immediate-cancellation path for past-due subscriptions.
• Wired the API connector and the app-side workflows, deployed, and tested against a live account.

Result. Subscribers can cancel and manage billing without contacting support, and the renewal path that was costing revenue is closed.

Looking back

The case-sensitivity typo was the easy part. The underlying issue was that three systems each had their own reasonable-looking definition of "this customer," and nothing forced them to agree. Picking one identifier that always exists, and resolving everything from it, is what actually closed it.

Why not 700 pages

700+ cities looks like a programmatic-SEO opportunity: generate a page each. I ran the numbers first. The median city on the platform has one listing, and only 29 have ten or more. Generating all of them would have produced around 670 thin pages, which is a site-quality problem rather than traffic.

Counting the listings correctly

Working out how many listings a city actually has turned into its own piece of work. Listings are filed under several different location strings for the same metro, so grouping on any one of them undercounts — in some cities by more than 30%. Separately, grouping by the record's creator attributes half a city to a data-migration account rather than to real hosts. Both errors put wrong numbers into a draft before I caught them, so the pipeline now merges on a key set and groups on the actual owner.

What each guide contains

• Price, supply and ownership-concentration figures computed from live data at publish time.
• The city's tax threshold, cited to statute. The question hosts have is how long a stay has to be before it stops being taxed as a hotel, and the answers vary a lot — one city exempts you based on how you're billed rather than how long you stay, and another taxes 31 nights but not 32.
• A neighbourhood angle from clustering listings by street address, which was the most reliable way to find something specific to say about a city.

The pipeline

• A query that pulls merged per-city stats from the app's data layer.
• A Node and Playwright generator that renders a branded header image per city from a JSON input.
• A slug-to-article map, so publishing a new city is a one-line change.

Result. 23 of 23 published and verified, each with original data and a header image, with all city-page link-backs live.

The constraint that shaped it

The obvious approach — automating a logged-in account — would have put the company's community account at risk, so it was out. That decided the architecture: everything reads the group's public surface, with no session and no account of ours involved. A few hours of latency is an acceptable trade for that.

How it works

• A scheduled collector reads the public group three times a day and posts to an ingest webhook.
• A small service classifies each post as buying intent, pain point, competitor mention, reputation risk or direct mention. Generic property-management requests are dropped rather than surfaced, since they weren't producing useful leads.
• Results route to Slack channels by urgency, each with a drafted reply in the appropriate register — customer-service tone for reputation risk and direct mentions, peer tone for buying intent and pain points.

Result. Runs for a few dollars a month inside free tiers. A vendor quoted around $1,000/month for comparable custom coverage.

What's still unproven

The strategy rests on an assumption I hadn't tested: that the valuable conversations happen in comment threads rather than top-level posts. Rather than buy the more expensive tier on a hunch, I set up a one-week keyword measurement to size the comment share, with the decision rule written down before the data came in.

Three separate problems

• Collection. Analytics calls to a third-party domain were being blocked by ad-blockers. Moved behind a first-party proxy so events arrive.
• Identity. The marketing site and the app were creating separate identities for the same person, so no funnel crossing the two could be read correctly.
• Coverage. Purchase tracking wasn't firing on every path, so the revenue picture was incomplete rather than just noisy.

What I built

A daily reconciliation job comparing tracked purchases against the payment provider's record and surfacing any divergence, so a tracking regression shows up the next morning rather than a quarter later, when the historical data can't be recovered.

Result. One rule now covers it: the payment system is the source of truth for money, analytics for behaviour, and a daily job checks they still agree.

A habit that came out of this

I now check the base rate before treating a number as a problem. A channel averaging a quarter of a signup a day will show a week of zeroes as ordinary variation. A few of my own confident diagnoses didn't survive that check, so it became a standing step rather than something I did when I remembered to.

What I worked on

• Third-party data integrations. I built the API integrations against an external automotive data and valuation provider, including the feed behind the platform's automatic OEM incentives.
• The second-generation rebuild. I rebuilt portions of the platform's next major version, working across the frontend and the backend.

The incentives integration

Rebates and manufacturer offers depend on the exact trim of a specific vehicle, and the figure goes onto a deal sheet the customer sees, so it needs to be exact rather than close.

Ours weren't. The provider's payload was a deeply nested structure carrying several hundred nested items, and the incentives the platform surfaced didn't reliably match the make and model they belonged to.

I mapped the whole payload — every level of nesting, rather than only the fields that looked relevant — and rebuilt the mapping from that. Once the shape of the data was fully understood, the cases that had been landing on the wrong vehicle were identifiable.

Result. Incentives display correctly for each make and model.

Why it's here

Integration work makes up a good part of what I do. Two systems that each make sense on their own have to be made to agree about what a record is — the same underlying problem as the billing work above, in a different industry.

Where I sit

Business analyst and builder both — I run the stakeholder discovery, write the process flows, then build. The discovery half is usually where the value is. Departments tend to ask for a solution they've already pictured, and the work is finding the problem underneath it. One project started as "standardise this recurring meeting agenda" and, after a stakeholder session, became "the data for that meeting lives in eleven places and nobody can see it by region, team or individual" — a different and more useful build.

What I do

• Discovery and process design — requirements from non-technical stakeholders, mapped as capability-level process flows in a shared diagramming convention.
• Automation — multi-connector flows across task systems, document stores, directory services and chat, with the operational parts handled properly: service-account ownership, shared connections so teammates don't each need their own, and run-only access so a team can self-serve.
• AI agents — agents that ingest a user's own data, validate it, generate a structured document from it, capture what happened afterwards, and produce the follow-up artifact.
• Reporting — multi-page reports over the team's delivery data, built to a designed spec, with the semantic model, theme, scheduled refresh and workspace governance set up behind them.

A few decisions from this work

• Replaced a report-triggered flow with a link into the system that already had a working control, because the platform's refresh ceiling meant the more complex version could never have stayed current.
• Moved a scheduled data refresh so it runs after the upstream job that feeds it, rather than alongside it.
• Held off migrating a flow's connections onto a service account until that account had the right licence, rather than doing a partial move that would leave it in two states.