I built the product and the business around it

I founded LiveLink, led its research, design, and engineering, and secured venture backing from Ben Franklin Technology Partners. The product began as a way to discover events. Conversations with venues led me to rebuild it around the work of promoting them. LiveLink had 25 participating venues.

My work connected the interface to what happened behind it: recurring bookings, reusable performer assets, layouts that adapted to each venue’s lineup, and the system that rendered and published the artwork. I worked with a cross-functional team while owning the product direction and the funding process.

Start inside the music community

LiveLink grew out of the music and venue community I was part of. I built a discovery platform where people could find nearby events, get a feel for a performer, and save a show they wanted to see. Venues and performers had a place to be found.

The Cisco Brewers event below shows that first product: a performer profile, a music preview, and the details someone needed to make plans. I was also out promoting LiveLink itself, putting the product in front of the people it was meant for.

Change the product when the research changes the problem

I spoke with venue operators, performers, and attendees. The venue conversations exposed a recurring job: a team could have its shows booked and still need to turn that schedule into graphics, reminders, and posts. Keeping that promotion current was work they had to do every week.

I made the decision to pivot from discovery to a social scheduler built around events. The lineup would supply the facts, the venue’s brand would supply the visual rules, and LiveLink would turn those inputs into scheduled promotion. That meant changing both the interface and what the product produced.

Put the show and its promotion in the same view

I designed the calendar to answer two questions together: what is happening, and what is going out to promote it? Filled labels represented events; outlined labels represented posts. Filters let a venue focus on the lineup, the publishing plan, or both.

I connected recurring events to weekly, weekend, and day-of promotion. The trivia night below sits beside its lineup post and reminder, making the relationship visible without opening each item. Reusing event details and performer assets meant those posts could start from information the venue had already entered.

Turn brand rules into a layout that can adapt

A calendar entry is structured data. A finished promotional image has to make that information readable and feel like the venue. A quiet Tuesday and a packed weekend needed different amounts of space. Long performer names, different fonts, and a venue’s own photography all changed the layout.

I built those choices into React templates: adjust typography to the length and density of the content, calculate the available space, and split longer lineups into pages while keeping each day’s events together. Continuation pages dropped the header image to make room for more of the schedule.

The design work became a set of rules the software could apply to different lineups, fonts, and photographs. Feed and story formats used the same event and brand information, with different output dimensions.

Make the preview survive the export

The artwork a venue reviewed had to carry through to the file sent to a social platform. I reused the React templates in a headless browser that rendered them at the final image size. The capture process waited for the selected fonts, their exact weights, photography, and template readiness before exporting the file.

This introduced a different set of constraints from displaying a page: browser startup time, memory, slow assets, and rendering timeouts. Reusing a running browser reduced repeated startup work. The goal was straightforward: a venue should recognize the artwork it approved when that artwork left the product.

I also had to handle the platform’s publishing format. A multi-page story required separate requests for its pages; a feed post could carry several images together. I kept those deliverables grouped as one campaign in the calendar, with publishing state and platform references available for inspection.

A changed booking changes the campaign

A recurring night could change once, from a certain date forward, or across the whole series. Those choices affected the lineup and the promotion attached to it. Treating each post as an isolated image would leave the venue correcting the same information in several places.

I connected previews and publishing to a shared source of current event and brand data. The publishing path loaded that data again before rendering, so promotion could reflect the latest schedule. Keeping output fresh meant doing rendering work at send time, with the extra processing that involved.

Leave room for the venue’s own work

Some nights needed a generated lineup. Others already had a finished poster. I separated photos used inside a template from complete artwork that could bypass it. Saved performer assets, recurring events, and a reusable brand package supported both.

Venues could also schedule their own announcements and specials. The calendar gave them one place to manage promotion while keeping control over the work that needed their judgment.

Raise the funding while building the product

I went through the Ben Franklin Technology Partners funding process myself and secured venture backing for LiveLink. At the same time, I was building the product and working to bring in customers.

This is the cover of my presentation to Ben Franklin. Its focus on an event-driven social scheduler captures the direction I was building toward. I was responsible for explaining the business to investors and turning that proposition into a product venues could use.

What the work added up to

LiveLink had 25 participating venues and venture backing from Ben Franklin Technology Partners. The project ended in 2026. It took me through customer research, a product pivot, design and engineering, customer acquisition, and fundraising.

The lesson I carry forward is to follow the customer’s work all the way through. For a venue, entering a booking was only the beginning. I had to connect that booking to its assets, layout, exported files, and publishing schedule, and account for what happened when the booking changed.