Flynn Townsend Case Study · Function.

Case study · Function.

Function. · Event Sales Pipeline CRM

A B2B sales pipeline app for hotel event enquiries, built end to end from a blank repo to a deployed cloud app.

Stylised poster of Function.: a kanban pipeline with New, Proposal and Booked columns above a revenue analytics strip
Stylised poster in the app's own design language (espresso and champagne gold). The live deployment sits behind sign-in, so no production data is shown here.
01 The problem

The problem

Hotel event enquiries live in inboxes and ad-hoc spreadsheets. Nothing tracks which enquiry is at which stage, what was last said to whom, or how fast the first reply went out. In event sales, response time is the metric that wins or loses the booking.

02 The solution

The solution

A pipeline CRM shaped around the enquiry-to-booking lifecycle: a Today screen with stat tiles and an action queue, a kanban board by stage with hover quick-advance, enquiry detail with a timestamped activity log and clickable stage stepper, CSV import/export, and an analytics dashboard covering win rate, booked revenue, lead sources and first-response-time distribution against a two-hour target.

It runs in production on Vercel with a Supabase backend, gated by email sign-in. Because the deployment holds real working data it is not open to the public. A walkthrough is available on request.

03 Technical breakdown

Technical breakdown

  • Modern full stack

    Next.js 16, TypeScript and Tailwind CSS v4, deployed on Vercel with a Supabase (Postgres) backend in Sydney. The whole enquiry lives in a jsonb column, so the app's data model can evolve without schema migrations.

  • Swappable data layer

    All persistence goes through one store adapter. With no backend configured the app runs fully local on localStorage; adding Supabase sync was literally one new file, and first cloud load auto-migrates existing local data up, once.

  • Security by design

    Row-level security scopes every row to its owner, the client ships only a publishable key, and a strict no-client-PII rule is built into how the tool is used. A deliberate piece of security-conscious design, not an afterthought.

  • Verified before use

    Every flow was verified before use: sign-up and email confirmation, localStorage auto-migration into Postgres, and stage advances round-tripping to the database with their activity entries. A timezone bug (UTC dates shifting Sydney dates back a day) was found in verification and fixed with local-time date helpers.

  • Configured for change

    Stages, lead sources, event types, lost reasons and the response-time target all live in one config file; the data model in one types file; design tokens in one CSS block. Built expecting the workflow to change.

04 Why it exists

Why it exists

Dispense proved I can build something a team trusts with real money. Function. is the next step: learning the sales process from the inside by building the tooling it runs on.

I am heading for the technical side of cyber security sales, as a Sales Engineer at a security vendor. Building a pipeline tool end to end, with the same stack modern SaaS demo environments use, is deliberate preparation for that: I want to understand stages, win rates and response-time pressure as an operator, not just a vendor.