Why I Built My Own Speaker Feedback System (In 20 Hours)
When the cost of building drops to near-zero, the calculus of 'Build vs. Buy' shifts dramatically.
The Noticing
It started as a challenge, mostly to myself. Could I go from a blank screen to a fully deployed, production-ready speaker feedback system in less than a day?
Not 20 hours of grinding at a keyboard, but 20 hours of total elapsed time: from the initial spark of "I don't want to pay for this" on a Saturday night (when I should have been watching a movie) to a live URL I could share with an audience. (And yes, that includes a full night's sleep and Sunday pancakes with the kids.)
In the old world (the world of 2022) spinning up a custom app for a single user was madness. You bought the tool, you paid the subscription, and you lived with the features they gave you. But thanks to the leaps in AI and agentic IDEs, the cost of "reinventing the wheel" has collapsed. And when the cost of building drops to near-zero, the calculus of what we buy versus what we make begins to shift dramatically.
The Tension: The "Build vs. Buy" Inversion
We've been taught for decades: Don't build what you can buy. Focus on your core business. Don't waste time on plumbing.
I've taught it myself to teams. I don't have enough fingers to count the number of conversations I've had about this, dissuading people from "rolling their own." And I've seen the massive failures that occurred when confidence in building (and the allure of "free") led to poor, brittle software implementations.
But what happens when the playing field levels so drastically that a solo builder can out-execute a legacy platform?
I looked at the market leader, Talkadot. I've used Talkadot for almost 3 years. It's a fine tool. It collects feedback, it captures leads, it sends reports. But it costs $149 per year for the features I actually needed. That's not huge money, but for a tool where I still have to compromise on data ownership and feature limits? I couldn't rationalize it - especially knowing I had the skills to build exactly what I wanted.
(Plus, I wanted something that would feed data directly back into my own ecosystem at triforceagility.com, creating a perfect feedback loop that I control. My admin dashboard gives me a view into my data that no third-party tool ever could.)
I wanted something different. I wanted to test a theory: that AI-assisted development has made "hyper-specific software" not just possible, but preferable. I didn't want a "feedback tool." I wanted my feedback tool, tuned to the exact nuance of how I want to grow as a speaker.
The Wander: Designing for Nuance
When you build for yourself, you don't build "features." You build opinions.
I wanted my system to be ruthlessly mobile-friendly because my audience is sitting in the audience holding a phone with one hand and a coffee with the other. I didn't want a "responsive" desktop site; I wanted a native-feeling mobile flow. That's an opinion.
Beyond the Star Rating
Most tools give you a star rating. Five stars means good, one star means bad. But what does "good" mean?
I built my system to capture three specific dimensions, because "good" isn't actionable:
- Future Interest: "I would prioritize attending another session by Fred." (This helps me show organizers the value I bring to their events.)
- Relevance: "The concepts are directly relevant to my work."
- Advocacy: "I would recommend this session to a colleague."
A talk can be highly entertaining (Advocacy) but useless (Relevance). Or highly relevant but boring (Future Interest). A single "5-star" metric hides these truths. Nuance requires ownership.
Privacy as a Feature, Not a Compliance Checkbox
I wanted GDPR compliance to be intrinsic, not a banner. Especially because I often speak to European audiences, and having robust data privacy is just good policy regardless of jurisdiction.
If you leave anonymous feedback, I ask for nothing.
If you provide a name, the consent box appears.
If you want the newsletter, the email field unlocks.
This isn't "compliance." It's respect. And you can only bake respect into the foundation if you pour the concrete yourself.
The Context of the Event
I wanted to track more than just the talk. My system captures the conference name, the specific date, and the venue context. This metadata powers better analytics: "How did I perform at Regional Scrum Gathering Banff vs. DevOps Days Des Moines?" becomes a queryable question.
The Value Exchange (Slides)
Most feedback forms are a tax on the audience. I wanted mine to be a gift.
Attendees complete the survey → immediate access to presentation slides. No email required (unless they want it sent to their inbox). It's a fair trade, not a tax. (I know Talkadot handles slides too, but I wanted full control over the delivery experience without their branding wrapped around it.)
The Cost of Ownership
It wasn't magic. It wasn't instant.
GitHub Actions failed repeatedly. Vercel deployments crashed with cryptic errors.
And the UI? I spent hours staring at a surprisingly ugly administrative UI because my IDE didn't read my CSS styles from my main site that I built with Design OS. Once I fixed the context and it read them, it applied them instantly; we went from ugly to an amazing, coherent, and complementary style in seconds.
Supabase Row Level Security locked me out of my own admin panel. Handling "partial saves" when a user closes their browser mid-survey is surprisingly hard - especially because we had to do it in a secure way to prevent data leaks between sessions.
The cost wasn't money (the stack of Next.js, Supabase, Vercel is free). The cost was friction. But that friction is where the learning happens. I wasn't just building a form; I was learning how modern data privacy actually works at a database level.
The Speculation: The Era of Artisan Software?
We are entering a strange new phase. If a solo developer (or a non-developer with an AI agent) can build a specialized, secure, production-grade replacement for a SaaS subscription in a weekend, what happens to SaaS?
Maybe we aren't moving towards "one app to rule them all," but one app per person.
Disposable Pixels vs. Heirloom Logic
There's a distinction emerging between "disposable apps" and "heirloom apps."
Disposable apps are "vibe-coded"; thrown together for a single use. The pixels are disposable. The UI layer is less important than the logic and data, because every person can have their own UI. The interface exists to serve my specific workflow at this specific moment.
But the foundation needs to be durable. I designed this system using the BMAD Method (Build, Measure, Analyze, Design).
The BMAD Approach
I didn't just prompt my way to a solution. I used a structured team of AI agents in "Party Mode," where multiple agents reviewed ideas efficiently. It does amazing things that Scrum Masters and Project Managers will find very familiar, including using epics, stories, and sprints:
- Analyst: Defined the requirements and data structures (finding gaps I missed).
- Architect: Planned the security model (Row Level Security is non-negotiable) and database schema.
- Product Manager: Prioritized features (MVP vs Nice-to-Have).
I remained the Approver, retaining full agency over the final decisions. There were deep dives into specific problems, but the structure kept us from spinning.
This architectural rigor means the app is secure by default (platform security was a P0 requirement), not insecure by accident. The "vibe" might be disposable, but the data integrity is built to last.
Imagine a world where you don't sign up for Salesforce; you generate your own CRM that tracks exactly the data you care about, interacting with your customers exactly how you prefer.
Imagine not buying a project management tool, but spinning one up that perfectly matches your team's weird, specific workflow.
My feedback system isn't a product. I will never sell it. It has one user: me. And it fits me perfectly.
The Landing
I stared at the dashboard of my new system. The testimonials were auto-curated by AI. The data lived in my database.
The testimonials are to be a key part of my marketing engine, surfacing the "voice of the customer" without me having to dig for it.
The real test comes this Thursday, when I'll use it live for the first time. I'll see the data flow in, and I'll know exactly where it's going.
It cost zero dollars. It took 20 hours.
You can try it out and give me feedback at feedback.triforceagility.com. (And if you ask to sign up for the newsletter there, I'll add you to my Substack. Because I own the data, I can make that connection seamless.)
The question isn't whether you can build your own tools anymore. The question is: once you realize you can have a bespoke suit for the price of a t-shirt, will you ever want to go back to the rack?
P.S. Only build it if you'll use it. It's not worth the 20 hours unless you get something specific out of it that the market can't provide.
P.P.S. Maybe I'll build my own personal audience polling software next.
Want to build your own tools?
I teach non-technical builders how to create software just like this. Check out my course: